Skip to main content

Deal overview

In short

A Deal is a silent automatic discount applied at the till. Configure who's eligible (audience), when it's active (timing + basket), and the discount shape — the platform applies it on every closing check that matches an identified member. Members never see Deals anywhere; the discount just shows up in the check total.

Unlike a Rule, which fires an action on an event, a Deal doesn't fire anything — it's a pricing rule evaluated at every check-close. There's no catalog in the Web App, no entry in the Wallet Pass, no "claim" step. Configure the offer and its eligibility, and from that moment on, every qualifying check that identifies a member gets the discount.

What makes something a Deal

Three properties separate a Deal from the other campaign kinds:

  • Silent and automatic. A Deal doesn't fire on an event, and the member doesn't pick anything. The POS closes a check; the platform evaluates every active Deal against that check; every Deal whose eligibility matches applies its discount. There is no member-side opt-in and no cashier-side awareness required.
  • Discount-shaped. The action of a Deal is always a price reduction on the check — percent off, flat off, a free item, or similar. Deals cannot send an SMS, add credits, or tag a member; those are Rule actions.
  • Member-identified. A Deal only applies if a member is attached to the check. If the cashier closes the check as an anonymous purchase, no Deals run. This is the one distinction between a Deal and a POS Deal — a POS Deal applies on every check regardless of member identification.

When to reach for a Deal

Reach for a Deal when the offer is:

  • A blanket discount for a defined audience during a defined window — Happy Hour, a weekend campaign, a loyalty-tier price cut.
  • Basket-shaped — evaluated against what's on the check at close (drinks, pastries, minimum spend), not against member history.
  • Meant to just happen — no claim step, no "redeem" surface, no communication required for the discount to work. (You can still announce the promotion to drive awareness — see the Announce Happy Hour playbook — but the discount applies whether you announce it or not.)

Some common shapes:

  • "20 % off drinks between 18:00 and 20:00 on weekdays." → Deal.
  • "Free pastry with any coffee for registered members this weekend." → Deal.
  • "VIP-tier members get 15 % off the new collection." → Deal with audience narrowed to a VIP tag.

If the incentive happens after the fact (credits back after purchase, thank-you SMS, birthday gift), that's a Rule. If the discount should apply on every check — not just member-identified ones — that's a POS Deal.

Anatomy of a Deal

Every Deal has the same two-part structure, established on step 2 and step 3 of the wizard:

  • Eligibility rules — which members count (audience), when the Deal is active (date range, days of week, time of day), and what shape the basket must have at check-close. There is no event trigger on a Deal; eligibility is the whole of step 2.
  • Discount action — what the Deal does to the check when it applies. Picked from a dedicated discount action set (see step 3 below).

The Deal wizard

Deals use the same four-step wizard as every other campaign kind:

Step 1 — Campaign details

Pick Deal as the kind. Name it so the offer is obvious in the list view, and use the description field to park the internal context a future reader will want — the campaign it belongs to, the budget it's drawing from, when it's meant to retire.

Step 2 — When (eligibility)

Step 2 on a Deal is purely eligibility and basket rules — there is no event trigger and no trigger-equivalent. The question step 2 answers is "which checks does this discount apply to?", not "what fires this Deal?". You'll configure:

  • Audience — which members the Deal applies to (all registered, members with a specific tag, members matching an attribute condition). A check identified to a member outside the audience doesn't match.
  • Timing — the window during which the Deal is active: date range, days of week, time of day. The check must close inside the window for the Deal to apply. A check opened at 19:58 and closed at 20:03 misses a 18:00–20:00 window.
  • Rate cap — how many times a single member can receive the discount ("infinite times per member", "once per member", "once per day per member", and so on).
  • Basket conditions — the shape the check must satisfy at close: minimum total, specific item categories, particular branches. This is usually where the "what the Deal is actually about" lives — a 20 %-off-drinks Deal is a Basket items contains at least 1 of Drinks condition plus a discount on the Drinks category.

Because a Deal's whole reason to exist is the discount it applies, basket conditions generally do more work here than conditions do on a Rule — they're what make the difference between "20 % off anything" and "20 % off drinks on weekday evenings".

Step 3 — Discount action

Pick the shape of the discount the Deal applies when it matches. Deals have their own action set, distinct from the 9-action set Rules use. Three families cover everything on the picker:

  • On entire purchase — the discount applies to the whole check. Amount off, percent off, or an External POS discount (an escape hatch that hands the actual price reduction off to a named discount configured on the POS side — useful when the POS already knows how to handle a particular promo code or campaign).
  • On specific items (or free) — the discount applies to selected items or categories. Amount off, percent off, a special price override, or "free item".
  • For each X buy / spend get Y — buy-or-spend-triggered reward. Amount off, percent off, special price, or free item, applied for every X in the basket.

You don't need to memorise every combination; the picker's headings make the shape obvious when you open it. The important thing upstream is that you pick the family that matches the offer — basket-wide, item-specific, or buy-X-get-Y — before worrying about whether it's a percent or an amount off.

The Select action modal inside a Deal, showing the three discount families: On entire purchase; On specific items (or free); For each X buy/spend get Y

A Deal can be split into several cases on step 3 the same way a Rule can — first matching case wins, remaining cases skipped. Reach for cases when the discount should vary by member segment or basket shape but you don't want to run multiple near-identical Deals to cover all the branches. See Split into cases for the full mechanics.

info

A Deal's action is always a price reduction — Send SMS, Add credits, Tag member, and the other non-discount actions aren't available inside a Deal. If you want a message to accompany the promotion ("Happy Hour starts tonight, 20 % off drinks"), announce it separately with a Future Campaign or a scheduled Rule. The Deal will apply to qualifying checks regardless of whether the announcement went out.

Step 4 — Preview

A read-only summary of the entire Deal — eligibility, timing, discount shape, rate cap. Use it as a last check before saving. Save commits the Deal; if the state on step 1 was Draft, it's saved as a draft and won't apply at checkout until you flip it to Active.

Lifecycle

Three states — Active, Draft, Paused — and when changes take effect

Deals use the same three-state lifecycle as Rules:

  • Active — every closing check that matches the Deal's eligibility gets the discount.
  • Draft — the Deal is saved but inert. No checks are affected.
  • Paused — temporarily inert. Use this for short-term withdrawals — a pricing issue, a supply problem, a pending revision.
warning

State is checked at check-close. the platform evaluates every active Deal at the moment the POS closes the check. If the Deal is Paused when the check closes, the discount does not apply — and if you flip the Deal back to Active a minute later, the next check will run under the Active state. Mid-service pauses are fine; just know that any check already in progress that closes during the pause will miss the discount.

Editing an Active Deal takes effect on the next check-close — prior checks aren't retroactively changed.

Testing a Deal before publishing

4-step pattern using a test-user tag

Same pattern as the Rule playbooks: narrow the Deal to members tagged test-user, then remove the tag when you're ready to go live.

  1. Tag yourself (or a teammate) with test-user from the member's profile page.
  2. Add an audience condition to the Deal restricting it to members with the test-user tag.
  3. Run a qualifying check at the POS with the tagged member identified. At check-close the discount should apply automatically.
  4. When the test passes, remove the test-user condition and save. The Deal now applies to the full audience you originally intended.

Gotchas

5 things that commonly trip people up
  • Deals don't send messages, and Deal application isn't a Rule trigger. The Deal action set is discount-shaped only, and there is no "Deal applied" event a Rule can listen to. If you need a thank-you SMS alongside a Deal's discount, the Rule has to listen to something else — typically Makes a purchase, which fires on the underlying check the Deal ran against.
  • Check must close inside the window. For time-of-day Deals, the Deal evaluates at check-close, not when the order was taken. Long-running checks can fall outside the window. If a member orders at 19:55 and the cashier doesn't close the check until 20:03, the Deal won't apply.
  • No prioritization — every matching Deal applies. If two active Deals both match the same check, both discounts apply. There is no "use the best one" logic. When you want a Deal to apply only to members who don't have a better offer, exclude that audience explicitly in step 2.
  • Member must be identified on the check. A Deal only applies if the cashier attaches the member to the check before closing it. An anonymous check gets no Deal — even if the basket, timing, and audience otherwise match a Deal targeting All registered members.
  • Nothing tells members the Deal exists. No wallet notification, no Web App entry, no card on their phone. If you need awareness — Happy Hour hours, a special-weekend promo — run a separate announcement campaign (see the Announce Happy Hour playbook). The Deal still applies whether the announcement went out or not; the announcement just gets people through the door.