Designing Promotion Rules: Triggers, Eligibility, Rewards, and Constraints

Hello again. In the previous lesson, you separated qualification, reward calculation, redemption, and fulfillment. That lifecycle tells us when a promotion decision becomes real. This lesson focuses on the design step that comes before implementation: turning a commercial intention into a precise, testable promotion specification.

A promotion brief such as “win back inactive customers with a dog-food offer” is not yet a rule. It becomes executable only when you state what initiates evaluation, who or what qualifies, which benefit is calculated, and which limits protect the business. By the end, you should be able to turn an ambiguous business request into a rule-ready design that a campaign manager, integration team, and commerce team can all interpret consistently.

---

From commercial objective to executable offer

A business objective explains why an offer exists. It is not itself a condition or an effect.

For example:

Increase repeat purchases from valuable customers who have not bought recently, while limiting promotional spend.

This objective implies a target segment, desired behavior, and financial guardrails. It does not yet specify:

• the customer action that should cause Talon.One to evaluate the offer;
• the data required to decide eligibility;
• the exact reward calculation;
• whether the benefit is limited by date, budget, redemption count, channel, product scope, or campaign interactions.

A useful architecture discipline is to express every promotion as four connected parts:

Part	Question it answers	Example
Trigger	What customer action or session state causes the offer to be evaluated?	A shopper updates a cart containing dog treats.
Eligibility criteria	Who, what, and when qualifies?	Customer lifetime value exceeds 600 and their last purchase was over 30 days ago.
Reward	What concrete benefit is calculated for a qualifying session?	25% off qualifying dog-treat items, capped at USD 15.
Constraints	What limits, exclusions, or operational boundaries apply?	Available for 14 days, once per profile, within a USD 20,000 budget, and not stackable with other retention discounts.

These components are related, but they should not be collapsed into a single sentence. If they are, implementation teams tend to make unspoken assumptions about such consequential details as whether a spend threshold includes shipping, whether a discount applies to every item, or whether a customer can use the offer repeatedly.

The diagram also reinforces a key point from the prior lesson: the promotion engine consumes facts and returns decisions. The sources must provide the information needed for eligibility, while the receiving touchpoints must present or fulfill the returned effect.

---

1. Define the trigger: when should the decision be reconsidered?

A trigger is the business event or state change that makes promotion evaluation relevant. It is not necessarily a grant of the reward. It merely says, “the facts may now be sufficient or different enough to evaluate this offer.”

Common trigger patterns include:

Business pattern	Trigger	Example data required
Coupon offer	Customer submits or removes a code	Coupon code in the customer session
Cart incentive	Cart content or quantity changes	Cart items, quantities, prices
Spend-threshold offer	Session total reaches a threshold	Cart subtotal and any included costs
First-purchase offer	Customer begins checkout	Profile identity and purchase history
Re-engagement offer	Known customer returns and forms a qualifying cart	Profile attributes and session/cart data
Referral offer	Referred customer presents a referral code	Referral code and profile/session identity
Loyalty redemption	Customer chooses to spend points	Loyalty balance and selected reward

In Talon.One, promotion rules are evaluated in the context of customer-session updates. A cart can be updated repeatedly while a shopper adds items, changes quantities, enters a code, selects delivery, or signs in. Therefore, the operational trigger is often an update sent through the integration; the business trigger is the meaningful change represented by that update.

For example, consider the requirement:

“Give 10% off when a shopper spends USD 100.”

The trigger should not be written as “the customer gets 10% off.” That confuses initiation with outcome. A better statement is:

• Trigger: Evaluate whenever the open cart changes.
• Eligibility: The qualifying subtotal is at least USD 100.
• Reward: Calculate a 10% session discount.
• Constraint: The discount cannot exceed USD 20.

This matters because the cart might move above and below the threshold several times. On a USD 110 cart, the offer qualifies. If the shopper removes an item and the qualifying subtotal becomes USD 95, the offer no longer qualifies. The integration must reconcile the latest decision rather than assume that a prior discount remains permanent.

Triggers should be observable, not inferred

A good trigger maps to a fact the integration can reliably send:

• “customer entered the WELCOME code” is observable;
• “customer appears interested in buying” is not;
• “cart contains at least two eligible products” is evaluable from cart data;
• “customer is high value” is evaluable only if a clear profile attribute, such as lifetimeValue, is maintained.

If the trigger depends on vague behavioral interpretation, first convert it into a measurable business event or maintained attribute. Do not hide a subjective segmentation decision inside an integration implementation.

---

2. Define eligibility: who or what is entitled to the offer?

Eligibility criteria are the facts that must be true for the promotion to qualify. They express the commercial boundary of the offer.

A robust eligibility definition normally considers four dimensions:

Dimension	Typical criteria
Customer	New customer, loyalty tier, audience membership, country, customer value, purchase history
Cart or product	Eligible SKU, category, quantity, qualifying subtotal, bundle composition
Time and channel	Campaign dates, store, country, app, website, point of sale
Promotion state	Valid coupon, referral status, available points, available inventory or campaign budget

Take this business request:

“Offer 20% off winter coats to Gold members during the first week of November.”

Its eligibility criteria are not simply “Gold member.” A complete interpretation might be:

• The customer profile has loyalty tier Gold.
• The current date falls within the first week of November in the Application’s configured time zone.
• The cart contains one or more items classified as winter coats.
• The promotion is evaluated in an approved channel or market.
• The campaign is active and has remaining capacity.

The reward is separate: 20% off qualifying winter-coat items.

Eligibility criteria must be testable predicates

A criterion is implementation-ready when two independent teams can evaluate it and reach the same answer. Compare the following.

Ambiguous requirement	Testable version
“Reward loyal customers.”	Customer has tier Gold or Platinum at evaluation time.
“Give an offer to inactive customers.”	Customer’s lastPurchaseDate is at least 30 completed days before the evaluation date.
“Discount selected products.”	Cart item attribute category equals dog-treats.
“Reward large orders.”	Eligible merchandise subtotal is at least USD 100, excluding shipping, tax, gift cards, and prior discounts.
“Offer a welcome discount.”	Profile has no previously closed purchase session and has not redeemed the welcome offer.

The right-hand column exposes the data contract. To evaluate inactivity, the profile must contain a maintained purchase date. To evaluate product scope, cart items need a reliable category or product attribute. To evaluate a threshold, the business must define which monetary fields count.

This is where architecture and promotion design meet: a condition is only as reliable as the source system and data definition behind it.

---

3. Define the reward: what exactly does the customer receive?

The reward is the benefit calculated after eligibility succeeds. In Talon.One terms, the rule produces one or more effects, which the integration interprets and, where necessary, fulfills.

Rewards are often described too loosely. “Give 20% off” leaves several unanswered questions:

• Is the discount order-level or item-level?
• Does it apply to all cart items or only eligible items?
• Is there a maximum monetary discount?
• Can it apply to sale items?
• Is it reflected before or after tax?
• Does it create a price adjustment, a free item, points, or an entitlement?

A reward specification should contain both a benefit type and a calculation basis.

Reward type	Precise example
Fixed session discount	Deduct USD 10 from the qualifying order total.
Percentage session discount	Deduct 15% from the eligible session subtotal, capped at USD 30.
Item-level discount	Deduct 20% from every qualifying dog-treat item.
Bundle benefit	Set the lowest-priced eligible item free when three qualifying items are present.
Loyalty award	Add 100 loyalty points when the qualifying session closes.
Loyalty redemption benefit	Deduct 500 points and apply a USD 5 session discount.
Non-financial outcome	Add a “member-only” product label or grant an external entitlement.

The word calculated is essential. A percentage discount is not a static promise; it depends on the current session. For a 25% item-level offer, adding another qualifying item changes the amount. Removing an item may remove or reduce the benefit. The promotion remains the same, but its current output changes.

A reward needs a fulfillment owner

From the prior lesson, remember that Talon.One returns effects; it does not automatically alter every downstream system. When you define a reward, also identify the system that makes it real.

Reward	Likely Talon.One decision	Typical fulfillment owner
Session discount	A discount effect with a name and calculated value	Commerce or pricing service
Item discount	A discount effect identifying an item position	Commerce service
Free physical item	A free-item decision	Cart, order, or fulfillment service
Loyalty-point addition	A loyalty effect settled at the appropriate session boundary	Talon.One loyalty program
Coupon creation	A coupon creation effect	CRM or messaging system for delivery
Customer message	A notification effect	Web, mobile, or marketing channel

A reward is incomplete if its owner has not been named. “Give a free bag of treats” requires a policy for stock availability, cart insertion, shipping, cancellation, and returns. Talon.One can decide that the customer earned it; the operational system must ensure that it is actually delivered or that the customer is informed when it cannot be.

---

4. Define constraints: what prevents an offer from becoming an uncontrolled liability?

A constraint narrows the offer or controls its exposure. Some constraints are business rules that resemble eligibility conditions; others are campaign-level controls that protect spend, inventory, or operational capacity.

The distinction is useful:

• Eligibility answers whether this session merits a reward.
• Constraints answer whether the offer is bounded, affordable, compatible with other offers, and safe to operate.

A well-designed promotion often needs several types of constraint.

Constraint category	Examples	Why it matters
Time	Valid only from November 1 through November 7	Prevents the campaign from remaining active indefinitely
Audience	Once per known profile	Controls repeated use
Reward cap	25% off, maximum USD 15	Limits exposure on high-value carts
Product scope	Dog treats only; exclude subscriptions and sale items	Preserves intended margin
Spend threshold	Minimum eligible subtotal of USD 40	Ensures desired customer behavior
Budget	Total discount spend cannot exceed USD 20,000	Caps total campaign cost
Stacking	Cannot combine with other retention offers	Prevents unintended compounded discounts
Channel or geography	Mobile app only; valid in the United Kingdom	Aligns offer with market strategy
Inventory or fulfillment	Free gift while stock lasts	Prevents promises that cannot be met

Not every constraint belongs in the rule itself. Campaign validity and campaign budget, for example, are campaign controls. A product inclusion rule may use cart-item filtering. A maximum discount is part of the reward formulation. A coupon’s redemption limit is tied to the coupon and campaign configuration.

At this stage, the architect’s responsibility is not to decide the exact configuration surface. It is to ensure that the intended constraint exists, is measurable, and has a clear owner.

---

Study the documentation’s basic translation pattern

Talon.One’s overview provides a compact example of converting a seasonal clearance objective into campaign type, validity, budget, coupon trigger, condition, and discount effect.

The documentation’s LATESUMMER example can be restated as a four-part specification:

Component	Interpretation
Business objective	Clear summer clothing inventory before the autumn collection
Trigger	Shopper supplies the LATESUMMER universal coupon in an eligible customer session
Eligibility	The coupon code is valid and the campaign is active
Reward	50% discount on the session value
Constraints	July 20 to September 1 validity period; USD 200,000 total discount budget; scoped to the USA Application

This is intentionally simple. In production, “session value” would require a shared definition: whether it means merchandise subtotal, discounted subtotal, taxable total, or another pricing value. The goal is not to overcomplicate a basic offer; it is to record decisions that otherwise become accidental implementation behavior.

---

Worked design: a retention offer for dog-treat customers

Now apply the four-part model to the type of decision illustrated by the Promotion Engine diagram.

Business objective

Reactivate high-value dog owners who have not purchased recently, while limiting the cost of the incentive.

A weak translation would be:

“Give dog owners 25% off dog treats.”

It omits the reactivation criterion, the definition of high value, and the financial guardrails. It would likely grant discounts to customers who would have bought anyway.

A more complete promotion specification follows.

Component	Design decision
Trigger	Re-evaluate when a known customer’s open cart is created or updated with dog-treat items.
Eligibility criteria	Profile indicates dog-owner status; customer lifetime value is greater than USD 600; last completed purchase was more than 30 days ago; cart contains at least one qualifying dog-treat item.
Reward	Apply 25% off qualifying dog-treat items, with a maximum discount of USD 15 for the session.
Constraints	Campaign runs for 14 days; customer can benefit once; total campaign discount budget is USD 20,000; cannot combine with other retention discounts; excludes subscriptions and clearance items.
Fulfillment owner	Commerce service applies the returned item-level discount to the cart and order.

This version is close to implementation-ready because each statement has a home:

• Profile facts such as dog-owner status, lifetime value, and last purchase date must be sourced and maintained.
• Cart-item facts such as category, subscription status, and clearance status must accompany the cart data.
• The reward must be mapped to the commerce platform’s item-price adjustment model.
• The campaign budget and usage policy must be configured and monitored as commercial controls.

Evaluate representative cases

A promotion design should be readable as a decision policy.

Customer session	Expected result
Known dog owner; lifetime value USD 900; last purchase 45 days ago; cart contains qualifying dog treats	Qualifies. Calculate 25% off qualifying dog-treat items, subject to the USD 15 cap.
Same customer; cart contains only toys	Does not qualify because product scope is not met.
Known dog owner; lifetime value USD 900; last purchase 12 days ago	Does not qualify because the reactivation condition is not met.
Anonymous shopper with qualifying dog treats	Does not qualify unless the business explicitly permits anonymous targeting with session-level data.
Eligible customer with a USD 100 qualifying dog-treat subtotal	Raw calculation is USD 25, but reward is capped at USD 15.
Eligible customer after campaign budget is exhausted	The intended reward must not be granted; budget exhaustion is an operational constraint, not an invitation for the commerce service to calculate the discount independently.

The fourth row exposes an important design decision: must the customer be known? If the business wants to target lifetime value and purchase recency, it needs a resolvable profile. An anonymous cart cannot reliably qualify against those profile criteria. The correct response is not to invent a default value; it is to decide whether the offer should wait for sign-in or use a different anonymous-customer promotion.

Resolve hidden ambiguities before implementation

Even a strong table can conceal questions. For this offer, explicitly resolve:

1. What is the qualifying price basis?
   Determine whether 25% applies to the original item price, the price after other permitted discounts, or another defined value.

2. How is “last purchase” maintained?
   Define whether it comes from Talon.One session history, a CRM profile attribute, or an enterprise purchase-history source. Define which order status counts as completed.

3. What does “once” mean?
   It could mean once per profile ever, once during the campaign, once per calendar month, or once per closed session. These are materially different policies.

4. Which offers are incompatible?
   “Not stackable” must name the promotion class or campaign behavior it excludes. Otherwise, pricing behavior will be decided incidentally by rule order or storefront logic.

5. What happens if stock is unavailable?
   This particular reward is a price reduction, so stock is chiefly a commerce concern. For a free item, fulfillment stock becomes part of the promotion’s customer promise.

A good specification records these decisions in business language before Talon.One configuration begins.

---

Map the specification to Talon.One’s rule model

Talon.One promotion rules use a WHEN–THEN pattern: conditions describe when the rule qualifies, and effects describe the result. Campaign-level setup provides the surrounding context, including such controls as campaign status, dates, coupon configuration, and budgets.

For the dog-treat retention offer, the conceptual mapping is:

Promotion specification	Talon.One-oriented representation
Trigger: cart updates for a known customer	Customer-session updates carry profile and cart data for evaluation
Dog-owner, high-value, and lapsed-customer requirements	Profile-based conditions using maintained customer attributes
Dog-treat item requirement	Cart-item filter or item condition based on product attributes
25% discount capped at USD 15	Discount effect with a defined calculation and maximum
Campaign dates and total spend	Campaign validity and budget configuration
Once per customer	Redemption or usage constraint appropriate to the selected offer mechanism
Customer-facing explanation	Rule display details and, where appropriate, notification or failure behavior

The key architectural point is that a rule is not the whole promotion. The rule expresses the decision logic. Campaign configuration, product data, profile data, integration behavior, and fulfillment ownership complete the design.

---

A compact promotion-design template

Before building a campaign, create a short design artifact for every material offer. It should be readable by marketing, product, commerce, and engineering.

Promotion name:
Business objective:
Success measure:

Trigger:
  Customer action or session change that prompts evaluation.

Eligibility:
  Customer criteria:
  Cart or product criteria:
  Time, market, and channel criteria:
  Required source data:

Reward:
  Benefit type:
  Calculation basis:
  Maximum value:
  Customer-facing label:

Constraints:
  Validity period:
  Per-customer or per-code limits:
  Campaign budget:
  Stacking policy:
  Exclusions:
  Fulfillment or inventory dependency:

Lifecycle:
  When is value committed?
  What is reversed for payment failure, cancellation, or return?

Ownership:
  Talon.One-managed state:
  Commerce-owned action:
  Other system dependencies:

For architect-level review, add acceptance examples rather than relying only on prose. Include at least:

• one session that clearly qualifies;
• one session that fails each important eligibility boundary;
• one cart that tests the reward cap;
• one session where an external constraint such as budget or inventory prevents the expected customer outcome;
• one cancellation or failure path if the offer consumes scarce value.

This does more than assist QA. It exposes missing definitions while the cost of changing the promotion is still low.

---

Key takeaways

A business objective becomes an executable promotion only after it is separated into clear components:

• A trigger identifies the customer action or session change that makes evaluation relevant.
• Eligibility criteria define the measurable customer, cart, time, channel, and promotion-state facts required to qualify.
• A reward specifies the actual benefit and its calculation basis, not merely a marketing slogan.
• Constraints bound commercial exposure through dates, budgets, caps, redemption limits, scope, and stacking policy.
• Talon.One rules express conditions and effects, but a complete promotion also depends on campaign configuration, reliable source data, and a named fulfillment owner.
• Ambiguities around price basis, identity, repeat use, stacking, and transaction reversal should be settled in the design, not discovered during checkout testing.

Next, you will use this specification discipline to choose an appropriate promotion mechanism for acquisition, retention, referral, and loyalty scenarios.