Qualify Customer for Loyalty Tier Based on Purchase or Point Activities
This use case describes the workflow of qualifying a customer for a new loyalty tier when they make a specified number of purchases. Once the purchases have been made, SessionM determines if the purchases have generated enough points to satisfy the purchase behavior ruleset that governs how point-based outcomes are awarded.
Part of configuring a SessionM implementation is the definition of a point economy, which provides the foundation for points-based loyalty programs. The key components of a point economy are point accounts, along with policies that define how points are redeemed and expired. With a point economy configured, a client can then define a tiered loyalty program, which can offer rewards based on purchases. The tiers within the loyalty program allow the client to offer different levels of rewards to its customers, each with benefits that recognize a customer's history of spending and brand engagement.
The provisioning of points to point accounts can happen several ways:
-
Awarded through a campaign.
-
Awarded as an outcome of a transaction or event.
-
Deposited by a customer service representative adding points manually.
This use case features a points-based outcome based on a customer making a specified number of purchase transactions.
Customer Journey
One helpful way of understanding this use case is to consider how it reflects the customer's experience, or journey, in the "real world."
Customer signs up for loyalty program, which generates customer profile in default tier, level 1
Customer learns number of transactions necessary to qualify for next tier, level 2
Customer makes 3 transactions, the number required to qualify for tier level 2
After each transaction, SessionM confirms that it meets economy ruleset; if so, it awards points customer point account
Once ruleset conditions are met, SessionM moves customer to next tier level
Customer logs in to get profile and verify promotion to next tier level
Platform Configuration
Before implementing this use case, ensure the following have been configured:
Points
Points account created in environment.
Loyalty Tier System
Point economy with at least two tiers set up, configured with the following behaviors for each tier:
- Entrance behavior - Set amount of points and limit to particular point account for entering tier.
- Purchase behavior - Award points per dollar to point account in order to allocate points per purchase.
- Maintenance behavior - Set to run at regular interval - usually once a day - to ensure tier members can remain in tier.
Note that customers can be part of only one tier level in a tier system.
Sequence Diagram
See the overall flow for this use case below.
Alternative Path
In the diagram above, step 15 adds points to the customer's account based on logic configured in the tier rule set that triggers an award of points when a purchase is made. But another option is to sidestep such logic, especially if a different system is calculating points, and simply deposit points into the account directly using this endpoint, detailed in the UserPoints API documentation: POST /api/1.0/user_points/deposit
.
Tasks
This use case diagram contains multiple tasks, each one depicted in its own color-coded section. For more information, see the overview below.
- Create Standard and Custom Profile (Use Case Events #1 - #4)
Discusses how to create customer profiles.
- Get Tier Level Progress and Advance to Next Tier Based on Purchases (Use Case Events #5 - #16)
Provides details that allow customer to learn about advancing to next tier and then making necessary purchases for that advancement.
- Get Customer Profile (Use Case Events #17 - #20)
Provides configurable way to get view of customer's profile data.
Take Note
Information about a customer's tier and progress can be obtained using the Standard Profile API (for basic tier in primary system) or the Custom Profile API (for tiers in all systems). These operations are detailed in the task, Get Customer Profile. Note that if you use the endpoint to retrieve the combined profile (standard/custom) in order to see data for all tiers and systems, you'll need to set the additional parameters detailed in the "API Endpoint Constraints" section of the Get Customer Profile task article.
Best Practices
Consider setting limits on earning frequencies. For example, customers being allowed to make up to 3 transactions a day or 45 transactions in a month to prevent fraud.
Consider using rolling point expiration policies to govern the point accounts.
With respect to tier maintenance:
-
Can take several days to run.
-
Drops customers from one tier to a lower tier. Tier level of a customer drops only when tier maintenance is run.
-
Other behaviors and associated outcomes may be scheduled to run at the same time maintenance processes are set up to run. This overlap of having two or more behaviors working on the same data at the same time may cause unexpected results. Best to avoid potential race conditions during maintenance.
When ranking outcomes designated for behaviors, bear in mind that the rank controls when the outcome starts. When rankings control a subsequent outcome, it runs after the previous, higher-ranked outcome begins, not after the previous outcome finishes.