Get Tier Level Progress and Advance to Next Tier Based on Purchases

Obtains the tier level progress for a customer so they can understand how close they are to advancing to the next tier. The task then indicates the purchases necessary to generate sufficient points to satisfy the loyalty ruleset and advance the customer to the next tier. With this knowledge in mind, the customer can make requisite purchases they need to reach the next tier.

The SessionM platform plays an important role in this workflow, as it must manage the transaction job, notifying the customer that the job ran successfully, checking each purchase against the loyalty ruleset that governs any related point awards, and, finally, moving the customer to the next tier level when they've met the conditions stipulated in the loyalty ruleset.

These rules can be defined in an economy rule hierarchy governing a tier system. They provide an excellent means for controlling the conditions that govern when transactions can reward customers with specific loyalty outcomes. For more information, you can read further on configuring rules for tier-related behaviors.

Sequence Diagram

See the overall flow for this task below.

CUSTOMER CUSTOMER CLIENT MIDDLEWARE CLIENT MIDDLEWARE SESSIONM SESSIONM GET TIER LEVEL PROGRESS AND ADVANCE TO NEXT TIER BASED ON PURCHASES 1 Learn what number of transactions qualify for move to next tier level 2Get tier level progress 3 Return tier level progress 4 Display that customer needs multiple transactions to move into next tier Purchase transaction steps: Repeat until ruleset satisfied for new tier level 5 Purchase item and finalize transaction 6Send purchase transaction 7 Enqueue transaction job 8 Return success message 9 Display success message 10 Check transaction against loyalty ruleset 11 Award customer points outcome 12 Move customer to next tier level when tier ruleset satisfied

API Endpoints & Constraints

POST /api/2.0/send_transaction

If passing an external user ID to SessionM and using the "ext → internal translation pattern," an additional call to get the internal SessionM user ID is required and made.

Bear in mind the following limits:

  • Maximum number of items is 1,000; maximum number of discounts is 100.
  • Maximum number of payments is 100.
  • Maximum number of custom object elements is 1000 (drops in orders of magnitude as the object complexity and size increases.
  • Limit number of calls to the send transaction operation and make them only at the end of the transaction. However, changes and voids may be applied as needed.
  • Similarly, offer locking and validation should be at the end of the transaction and not after each new item is added or removed.
  • Return periods greater than 12 months will not be able to restore points upon returns.
  • Avoid using the user ID translation pattern when possible. These APIs are agnostic of the user ID, which is the source of truth for the customer. It is just as viable to pass an external ID and NOT need to translate when using the SOR pattern, where the external user ID is treated as the SessionM ID for internal processing. Note: This only works when there is one source of external ID. Multiple sources of user ID would require translation (normalization) to SessionM user ID.