Understanding Rewards
What is a Reward?3
A Reward is an identified, named benefit provided by a retailer or 3rd party to customers in exchange for customer actions (like purchasing products, visiting web sites or stores, referring other customers, renting items, etc.). In ARTS a reward may originate as a promotional offering (typically a discount) independent of customer account. These rewards may take the form of instant point of sale discounts, coupons, rebates, free gifts, etc. In ARTS, a PromotionalOffer exists as a separate and distinct trigger for Reward that may stand on its own or may be linked to a customer account. Most manufacturer sponsored coupons, rebates and discounts are typically PromotionalOffers that extend to customers with or without a customer account.
Figure 27 - Rewards Core Entities
A Reward, as noted, may be associated with a CustomerMembershipAccount through the CustomerReward associative entity type. The CustomerReward entity enables retailers to offer rewards on a discretionary basis to customers based on their membership. For example, grocery chains often offer fuel discount rewards to loyalty program members. Only enrolled customer receive the fuel discount points. Also, in this scenario, an account structure is required because fuel points are earned over a number of retail transactions which necessitates an account or ledger to accumulate points over time.
Deferred and Instant Rewards
The ARTS ODM conceptually organizes rewards into two broad categories. The first category is deferred rewards. These are rewards that are earned in one or more customer interactions with the retailer (typically retail transactions) and redeemed in subsequent interactions. The second category is instant rewards which are earned and redeemed in the same interaction (typically a retail transaction).
Deferred rewards are earned over time, accumulated and redeemed in subsequent transactions. The grocery fuel discount program is a good example of a deferred reward program. Deferred rewards require some mechanism to memorialize customer interactions (typically purchases) and accumulate them over time. In ARTS that mechanism is represented by the CustomerMembershipAccount and its dependent CustomerAccountLedger. Deferred rewards always require some kind of customer account placeholder to accumulate earned rewards, redeemed rewards, reward adjustments and to present a current reward balance.
Instant rewards are earned and redeemed in the same interaction. For example a grocery retailer sells frozen pizza with a vendor sponsored discount of 10% off. That promotional discount is taken as a point of sale discount (in this case as a bill back) in the transaction. A retailer sponsored door buster discount of 5% off on purchase made between 10 AM to 12 PM on Mondays is an instant reward triggered by the timing of a customer purchase. In this case, the reward is earned and redeemed in the same retail transaction and results in a point of sale markdown.
Understanding How Rewards Work
The ARTS ODM treatment of Reward and related entity types is based on a conceptual reward process model. Rewards may be triggered automatically based on a prescribed set of eligibility rules that are executed by the order entry or point of sale or order processing application or they may be manually applied by a cashier or customer service representative.
In most retail scenarios, rewards are triggered when a customer makes a purchase (or adjusted when they make a return), refers a customer, places and order, visits a store or web site or some other action.
It is important when discussing reward trigger events to separate the reward from a promotional offer. Within ARTS, the reward process addresses the steps involved in earning and redeeming rewards. There are other kinds of events that may trigger offers for rewards (usually PromotionalOffers). In a scenario where a prospect enters a store and receives a 50% off discount offer on their cell phone, they are receiving a PromotionalOffer. When the prospect acts on that offer and makes a qualifying purchase they trigger a Reward. This is a somewhat subtle distinction, but an important one. Rewards are always tied to some kind of customer action. Promotional offers are invitations (or calls to action) for customers to take some action to earn rewards.
Rewards processing always include the following steps:
•Reward eligibility which determines if a customer, retail transaction, or retail transaction line item satisfies the conditions for applying a reward;
•Reward derivation which determines the value of a reward in reward currency units and whether that value is earned and accrued at a customer account level or redeemed at a transaction level or line item level;
•Reward transaction disposition which determines if the reward will be instantly redeemed in the current transaction or deferred (through accrual) to future transactions; and
•Reward accounting disposition which determines if and how a given reward is treated for financial reporting and accounting purposes.
The flowchart presented here illustrates the conceptual process model.
Figure 28 - ARTS Conceptual Reward Processing Model
The next entity diagram snippet shows the ARTS ODM entities that are based on the conceptual process.
Figure 29 - Reward Core Entities and ARTS Notational Process
Rewards may be triggered automatically based on a prescribed set of eligibility rules or they may be manually applied by a cashier or customer service representative. In most retail scenarios, rewards are triggered when a customer makes a purchase (or adjusted when they make a return), refers a customer, places and order, visits a store or web site or some other action. The ARTS ODM includes entity types used to manage when and how rewards are triggered.
The first entity is the RewardEligibilityRule. As discussed later (see Understanding Reward Eligibility), this one entity has a complex collection of subtype entities used to handle a wide range of rules and conditions for applying rewards. The RewardEligibilityRule (if looked at as a black box) looks at a customer action, applies a set of rules, emits a thumbs up or thumbs down decision about whether a Reward is provided to the customer. In the diagram here the eligibility rules stipulate that a customer make a certain number of referrals or place a certain number of orders to qualify to receive a reward.
After determining that a reward has been earned the next step is to figure what that reward should be. The rules for deriving a reward value are held in the RewardDerivationRule entity. Rewards are numeric values that may be counting money, points, VIPS (in the diagram above), miles or some other units that are specified in the CustomerAccountValuationUnitType entity. The CustomerAccountValuationUnitType is a reference entity that identifies, names and defines the units used to explain what an account accumulation or balance is measuring. By design, this entity stretches the idea that accounts deal only with monetary units. It is used to establish a controlled vocabulary for defining various kinds of customer reward earning and redemption activities which often require different measurement units (along with relevant conversions).
Once a reward value has been determined the next step is deciding how the reward should be disposed of. Deferred rewards are disposed of by adding them to a customer account balance (in the appropriate reward currency). Deferred rewards are accrued for future redemption by a customer. The grocery gas rewards program mentioned earlier is a good example of deferred rewards. The My Rewards Balance receipt picture in the Rewards Core Entities diagram above is a concrete illustration of deferred rewards. It shows the points earned today in the current transaction and the total points accrued in the customers account. These points are "banked" for future redemption.
When a deferred reward is redeemed, its reward currency units are converted into a monetary value which may then be taken as a discount, issued as a coupon, issued as a stored value card, etc. The key point is that a redemption always involves transforming accrued reward currency value into a monetary value and making that monetary value available for use by the customer. The rules for transforming reward currency value into monetary value are held in the RewardDerivationRule entity. Accordingly, RewardDerivationRule serves as the repository for rewards earned rules and rewards redeemed rules.
The data model representation of the linkage between earned and redeemed rewards is discussed inUnderstanding Reward Earn and Burn - Reward Disposition .
Transaction Processing Reward Attributes
The diagram shown here lists the attributes and related values that answer the following questions about how a reward is handled within a transaction:
•What level should the reward value be assigned to? (RetailAttributionLevelCode)
•How should the reward be disposed of? (RewardDispositionCode)
•How should the reward be applied to a given attribution level for a customer? (RewardTransactionLevelActionCode)
As a triple set, these attributes prescribe how a given reward instance is to be processed within a retail transaction. The table at the bottom of the diagram lists ARTS recommended combinations that prescribe a bounded reward handling process for retail transactions
Figure 30 - Transaction Processing Reward Attributes
Reward Limits and Conditions
In addition to the reward transaction processing parameters the Reward entity provides other important attributes that:
•Define reward limitations (retailer stop-loss conditions)
•Define exception flags that turn off rewards
•Establish a basis for prioritizing rewards where more than one could apply, but the limitation rule only allows for one
Figure 31 - Reward Limit and Condition Attributes
Reward Derivation Cardinality
A given transaction may trigger many different rewards at different levels. One of the most complicated aspects of reward processing is figuring out how to handle multiple, concurrent rewards. In the example just cited, there are two distinct rewards. The bonus point reward is attributed to a customer account. The 20% discount is attribute to a big screen TV line item. In this example BOTH rewards apply and both will be derived and disposed of. The point reward is disposed of through an accrual to a customer reward account. The 20% discount is derived as a monetary value and disposed of as an instant reward - discount. In its current form, ARTS provides basic structures to deal with the most common multiple reward scenarios . Some retailers use very complicated compound rewards that may not be fully addressed by the ARTS structures. In these situations they will need to extend the model.
Reward multiplicity applies within a transaction at the line item level. Each transaction line item may trigger one or more rewards based on their eligibility rules. Reward processing within a transaction scope has to incorporate conjunction-based features to enable and/or combinations of rewards. Also, reward rules have to provide limits and constraints to avoid unintended losses which can occur without properly bounded reward derivation rules. The diagram presented here illustrates the cardinality of Reward and RewardDerivation.
Figure 32 - Reward and Reward Derivation Cardinality
Reward Derivation
Reward derivation specifies the rules used to calculate the value of a reward in reward currency units. Reward derivation also determines the level the reward value gets assigned to. Within the ARTS ODM there are three levels that rewards may be attributed to. The first is the customer ACCOUNT level. This is where deferred rewards are assigned so they may be accumulated and accrued for future redemption. The second level is the transaction level (PRICE_MODIFICATION_LINE_ITEM) where a reward (typically a discount of some kind) is assigned to the whole transaction without an attempt to allocate it to individual line items. The third, and most granular level is the retail transaction line item level (RETAIL_PRICE_MODIFIER) which limits the effect of the reward to a single line item. Each of these three levels and the disposition (deferred versus instant) require different derivation methods. Reward derivation methods are specified in the Reward and RewardDerivationRule entity types. Typically, account and transaction level rules are reflected in the Reward entity type. Retail transaction line item level rewards are specified in the RewardDerivationRule entity type.
Figure 33 - Reward Derivation Rule
