Qualify Customer for Loyalty Tier Based on Action

This use case describes the workflow of qualifying a customer for a new loyalty tier when they take an action. Once the action is taken, SessionM determines if it generates enough points to satisfy the event 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 events triggered when customers perform certain actions, such as visiting a website. The tiers within the loyalty program allow a client to offer different levels of rewards to their customers, each with benefits that recognize a customer's event history and brand engagement.

The provisioning of points to point accounts can happen several ways:

  • Awarded through a campaign.

  • Awarded as an outcome of an event or transaction.

  • Deposited by a customer service representative adding points manually.

This use case features a points-based outcome based on an event - a customer signing in to a website.

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 in to website selling international coffee by the pound

Client middleware sends sign-in event to SessionM for evaluation against tier ruleset

10 points are added to the customer's point account if event meets ruleset criteria

Customer is then promoted to new tier if point account total qualifies for tier change

Current loyalty tier status displayed for customer

Platform Configuration

Before implementing this use case, ensure the following have been configured:

Points

Points account created in environment.

Economies

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
  • Event behavior - Award points per event to point account in order to allocate points per action.
  • Maintenance behavior - Set to run at regular interval to ensure tier members can remain in tier.

Sequence Diagram

See the overall flow for this use case below.

CUSTOMER CUSTOMER CLIENT MIDDLEWARE CLIENT MIDDLEWARE SESSIONM SESSIONM QUALIFY CUSTOMER FOR LOYALTY TIER BASED ON ACTION 1 Sign in to application or website Sign-in triggers web_login event, which triggers client middleware to send event to SessionM 2 Create or send  event using user_id or external_id 3 Process event payload 4 Add points to point account based on tier rule sets 5 Move customer to new tier if enough points earned 6 Return 200 level message for successful event 7 Request  current tier level status for customer 8 Return current tier level for customer 9 Display current tier level to customer

Alternative Path

In the diagram above, step 4 adds points to the customer's account based on logic configured in the tier ruleset that triggers an award of points when an action is taken. But another option is to sidestep such logic and simply deposit points into the account directly using this endpoint, detailed in the UserPoints API documentation: POST /api/1.0/user_points/deposit.

In addition, consider step 7, which makes a request for the customer's tier level status using the UserTiers API (Incentives domain package). This information, however, can also 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 should you use the endpoint to retrieve the combined profile (standard/custom). Doing so ensures all of the data can be seen for all tiers and systems. However, you may want to filter the data being returned by setting additional parameters detailed in the "API Endpoint Constraints" section of the Get Customer Profile task article.

Best Practices

Consider setting limits on earning frequencies.

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.