Skip to main content

Householding and Account-to-Account

Purpose of this document​

This document provides details at the business, technical, and implementation levels for specific features within the ES Loyalty feature set. This document addresses a subset of functionality centred on householding and account-to-account features.

Multi-active cards​

Ability for a single account to have multiple active cards (that is, one primary and multiple secondary cards).

Multi-active cards allow an account to have more than one active card, whether physical or digital. At the time of account enrollment, only one card—the primary card—needs to be assigned to the account.

  • This feature lets an ES Loyalty account have multiple active cards linked to it (for example, card IDs 1, 2, and 3 are all linked to account A).
  • The primary benefit of this feature is the ability to distinguish between behavior performed by different cardholders (for example, purchases and redemptions performed by card 1 versus card 2).
  • As a secondary step—which can occur immediately in the enrollment workflow or later—the member needs the ability to add additional secondary cards to the account (for example, request 10 additional cards).
  • These workflows are enabled on client applications, websites, and portals (that is, the Customer Experience APIs) as well as the ES Loyalty Console in the member administration section.

Account associations​

Ability for multiple accounts to maintain a relationship with one another and to have their relative roles defined (for example, parent/child, ship-to/bill-to).

Accounts can have relationships between them that must be recognised by the loyalty program system in order to properly allocate rewards and maintain an auditable trail. For example, there may be a number of ship-to accounts that represent entities that order goods and earn and redeem points, but these activities are rolled up for reporting and payment is made from a bill-to entity. Each ship-to account has a one-to-one relationship with the bill-to account, and the bill-to account has a one-to-many relationship with the ship-to accounts.

Account associations allow the relationship between accounts to be defined.

One example is MMS, which uses a single bill-to primary card on the account (used for invoicing and payment), and one or more ship-to secondary accounts to designate cards used to submit orders, receive shipments, and earn and burn rewards. Actions on the ship-to cards are rolled up to the bill-to account.

Another example is Kent, where the primary card may represent a contracting company and secondary cards may be used by individual employees of the company to purchase building supplies.

Household privileges​

Ability to configure at the program level whether primary and secondary members can redeem from the household balance, invite others to the household, or view household details.

The householding feature allows multiple loyalty participants—with personal, family, or business relations—to coordinate their loyalty experience. A key distinction between B2C and B2B householding is that in B2C, individuals typically own their own points and can independently choose to participate in or leave a household.

As part of the implementation, a household member can perform the following actions:

  1. Invite others to the household.
  2. Redeem from the household balance.
  3. Leave the household.
  4. View household details (status, balance, transaction history, household members, and so on).
  5. Disband the household (that is, leave the household as the primary member).

The Householding section lets an administrator control household features for members using universal settings. Depending on permissions, Householding may or may not appear in the Program menu, or it may be visible but not editable. Only administrators with full permissions can edit the settings on this page.

The following three settings are available only in the configuration file for the household template. Contact your Exchange Solutions TSA for more details if required:

  1. capacity: The maximum number of members that can be in a household, set at the system level. If the settings on the household page exceed this configured maximum, an error message is shown. For example, this value might be set to 25.
  2. dailyMemberInviteLimit: The maximum number of member invitations a specific member can send in a day. For example, this might be set to 100.
  3. expireInviteAfterInDays: The number of days before a household invitation expires. For example, this might be set to 20.

The following additional settings can be viewed and changed by an administrator on the Household page:

  1. Maximum number of members: The maximum number of members that can be part of a household. The value entered must be 1 or higher. Note that a configuration limit applies and cannot be exceeded.
  2. Privileges -- primary member: Privileges can be assigned to allow the primary member to view other member details (as relevant to the household), redeem points from the household point balance, and invite members to the household.
  3. Privileges -- secondary member: Secondary members are those invited by the primary member or by another secondary member. Privileges can be assigned to allow secondary members to view other member details (as relevant to the household), redeem points from the household point balance, and invite members to the household.

Household balance pooling (proportional redemptions)​

Ability for accounts in a household to redeem amounts that are distributed proportionally to each member's point balance.

For most clients, the redemption logic is view-only because there is only one option-- PROPORTIONAL--which is also the default. This means redemptions are distributed across all household members in proportion to their current redeemable balance. For example, if household member A has $300 redeemable, member B has $200, and member C has $100, a total redemption of $300 would deduct $150 from member A, $100 from member B, and $50 from member C.

Note that if any household member has a redeemable balance of zero, the redemption is taken proportionally from the members who do have a redeemable balance.

Note also that the redeemable balance for any member may not match their contributions if those contributions exceed the member's daily redemption cap.

Household balance pooling (defined redemptions)​

Ability for accounts in a household to redeem a defined amount from each member's balance.

For one particular Exchange Solutions client, the ad hoc redemption logic is set to REQUEST_DEFINED, which means the primary member can define how much is redeemed from each household member included in the request. Members not included in the redemption request contribute zero.

In this case, a secondary member can still redeem points if they have redemption privileges, but only their own points--not those of other members. The default redemption logic is still shown as PROPORTIONAL but is not applied in this scenario.

Points transfer​

Ability for an account to send points to another account.

The MVP user experience for points transfer is as follows:

  1. The sender calls Customer Care.
  2. The agent uses the existing member search functionality to look up the sender's account profile based on loyalty information the sender provides (card number, email address, or external identifier).
  3. The agent uses the existing member search functionality to look up the recipient's account profile based on loyalty information the sender provides (card number, email address, or external identifier).
  4. The agent performs manual verification in accordance with the client's business processes-- for example, asking the sender to confirm the recipient's name and postal code.
  5. Provided the agent has the required permission, they initiate the points transfer from the sender's member profile page, which calls the new API described below.
  6. After the points have been transferred and transactions recorded in both accounts, a transaction search for either member shows a transaction indicating points debited or credited, along with any relevant information.

The existing config for LAD has been updated to include this new transaction type. Both the sender's and recipient's LAD are updated by the points transfer. Some code changes may also be required to integrate with this LAD code for the points transfer flow.

The usual metrics are generated for both transactions, containing all relevant item details. Requirements around aggregation are not yet finalised.

For the sender, a triggered email is expected. A new class has been added in Event Processor to sync points transfer data with SFMC, similar to what is done for redemption emails.

Last updated on