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.
{"type":"image","url":"https://i0.wp.com/www.ragnarokmarketing.com/wp-content/uploads/2023/06/others_integration_diagram-1.png?ssl=1","caption":"The diagram depicts customer and commerce data from CRM/CDP, point of sale, ecommerce, and a data warehouse entering a Promotion Engine. The engine evaluates conditions, produces effects such as discounts, product labels, and loyalty points, and sends those decisions to touchpoints including a mobile app, marketing automation, push notifications, and checkout.","isV2":true,"blockId":"3aeaf6ef-7e74-4261-a094-9b83e12ab3f1","lessonId":"74b8c493-613b-40bc-a9f1-dd46fae4ca4a"}
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
WELCOMEcode” 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.
{
"type": "exercise",
"id": "004af394-a44d-4b96-b21f-5b28c529859a"
}
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.
{
"type": "exercise",
"id": "5c3206be-67e0-411f-9237-f5bf24a488db"
}
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.
{"type":"reading","par_intro":"Read the “Business example” in the Talon.One overview. It shows a single business objective becoming an Application-specific coupon campaign with a validity period, budget, universal code, condition, and discount effect.","par_directions":"In the “Business example,” begin at the paragraph starting <span data-type=\"resource_reading_textrange\" data-resource-subitem-id=\"ab0c53c7\" data-range-start=\"Let's focus on our USA business and its corresponding Application, here's our simplified promotion strategy:\" data-range-end=\"This is how a basic coupon setup looks like.\">the campaign strategy</span>. Read through the basic coupon setup. Identify which details are campaign constraints, which detail acts as the shopper-facing trigger, and which condition and effect express the rule itself. Notice that the code being valid is necessary for the illustrated rule, but the dates and USD 200,000 budget also bound the offer.","learning_duration":"10 minutes","url":"https://docs.talon.one/docs/product/overview","title":"Talon.One docs: Talon.One overview","isV2":true,"blockId":"424d9034-9b9a-4e30-aba6-72b06250bdb3","lessonId":"74b8c493-613b-40bc-a9f1-dd46fae4ca4a"}
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:
-
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. -
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. -
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. -
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. -
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.
{
"type": "exercise",
"id": "d4c51ac7-f4a5-446d-b2f7-b02df10fe42b"
}
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.
{"type":"reading","par_intro":"Read the “Create a promotion rule” section in the Talon.One documentation. It connects the promotion design vocabulary to the Rule Builder’s conditions, effects, and optional failure effects.","par_directions":"In “Create a promotion rule,” review steps 4 through 10, beginning with the instruction to add a condition. Follow <span data-type=\"resource_reading_textrange\" data-resource-subitem-id=\"d1825d1b\" data-range-start=\"Set the required values and the necessary attributes.\" data-range-end=\"Set the required values and attributes.\">the condition and effect workflow</span> through the addition of an effect. Pay particular attention to the option to run effects on every session update and to add a failure effect to a condition. For this lesson, treat “always trigger effects” as a deliberate design choice, not a substitute for stating eligibility.","learning_duration":"8 minutes","url":"https://docs.talon.one/docs/product/rules/create-and-manage-rules","title":"Create and manage rules | Talon.One docs","isV2":true,"blockId":"c06213d0-b673-4397-8d76-5602c816af5f","lessonId":"74b8c493-613b-40bc-a9f1-dd46fae4ca4a"}
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.
Can't find a good explanation? Sign up and we'll make it for you