Coupon codes

In short

A coupon code is a short string a member enters in the Web app or mobile app. Entering it fires the Enters a coupon code trigger on a Smart Campaign Rule, which then does something — typically Tag member (for staff-discount subgroups) or Add credits (for gift cards). The Coupon codes management surface generates the codes themselves and decides their parameters: how many codes exist, how long each one is, how many redemptions per code. The Rule that reacts to entry is configured separately under Smart Campaigns.

note

Screenshots on this page show one merchant's setup (Spanish labels). Your Hub displays the labels and content you configure for your own program.

Two patterns cover most uses: tagging subgroups (e.g. "all employees of Company X get 20 % off") and gift cards (e.g. "100 € of credit, sold as a physical or digital gift"). The mechanics are the same on both sides — entry fires a Rule — but the management story and the awarding action differ. This page covers both, plus the unique-vs-generic decision that runs across both.

How a coupon code works end to end

Three moving parts:

1. The codes themselves, generated and managed under Marketing → Coupon codes. You decide how many codes exist, their length, how many redemptions each code allows.
2. The Rule that reacts to entry, configured under Smart Campaigns with the Enters a coupon code trigger and a condition like Coupon code is one of [your-code]. Without this Rule the code does nothing — it's just a string.
3. The member-side entry surface in the Web app or mobile app where the member types the code (the "Código de activación" / "Activation code" page). When the member submits, the platform resolves the code to its configuration, fires the trigger, and runs whatever Rule(s) match.

The member-side page renders in the brand's colours and language. Members who hit the QR-scan icon to the right of the input can scan a code instead of typing — useful for printed cards or in-store signage that carries a QR-encoded code.

The two patterns

Pattern 1 — Subgroup tagging (e.g. Company X employee discount)

The pattern: the business wants a specific group of people (employees of Company X, members of a partner association, attendees of an event) to get a special offer at the till. You can't ask every cashier to memorise who works for which company, so the loyalty system has to know. Coupon codes are how you let the right people self-identify.

End-to-end flow:

1. Generate the codes under Marketing → Coupon codes. Either N unique codes (one per employee) or one generic code with N redemptions — see the unique-vs-generic decision below.
2. Distribute the codes to the subgroup (HR sends a mail-merge, the partner shares internally, the event organiser puts a code on the badges, etc. — see distribution notes below).
3. Build a Smart Campaign Rule with trigger Enters a coupon code, condition Coupon code is one of [your-code], action Tag member with a tag like CompanyX_Employee.
4. Build a separate Deal (a Smart Campaign Deal, not a Rule) scoped to members tagged CompanyX_Employee. This is the actual discount — once a member has the tag, the Deal applies automatically at every check-close as long as the cashier identifies them. The member never has to mention the code again.

The split — Rule writes the tag, Deal reads it — is what makes this clean. New benefits for the same subgroup come as new Deals targeting the same tag; the coupon-code distribution doesn't need to change.

Distribution notes:

For unique codes, distribution requires pairing each code with a person. The two paths in practice:

• Manual — for small companies (a handful of employees), HR or the business owner emails each person their code one at a time.
• Automated mail-merge — for larger lists, HR pulls the codes into a spreadsheet alongside employee email addresses and uses a mail-merge tool to send each person their unique code automatically.

For generic codes, distribution is just sharing the code internally — pin it in the company chat, write it on the office whiteboard, however the company normally communicates. The risk is that employees forward it to friends and family; the bound on that risk is the Available per code number you set when generating.

Pattern 2 — Gift cards

The pattern: the business sells prepaid credit as a gift product. The buyer purchases a card; the card carries a code; the recipient enters the code in their loyalty wallet to load the credit. A typical implementation sells gift cards in physical and digital variants and in several denominations (100 €, 150 €, 200 €, 300 €).

End-to-end flow:

1. Generate the codes — typically unique codes (each gift card has its own code that gets used once). One coupon-code record per denomination (100 €, 200 €, etc.) with as many unique codes as you want to sell.
2. Sell the cards through the online ordering surface your merchant uses. Each sale draws one code from the pool and pairs it with the buyer's order:
   • Physical card — the code is printed on a card and sent by postal mail to the recipient.
   • Digital card — the code is emailed to the recipient. The email is sent by the platform via the External event submitted trigger — the ordering system posts an event with the recipient's email + personalized text, and a Smart Campaign Rule on that trigger sends the email through a Comm. Template.
3. Build a Smart Campaign Rule per denomination with trigger Enters a coupon code, condition Coupon code is the matching code-record, action Add credits with the corresponding amount. Each denomination is one Rule — the 100 € card has its own Rule that adds 100 €; the 200 € card has its own.
4. Recipient enters the code in the loyalty Web app's "Código de activación" page; the credit lands in their balance.

For the digital path, you'll typically have two Rules per denomination — one on Enters a coupon code (the redeemed-side: add credits) and one on External event submitted (the sold-side: send the email with the code). The screenshot below shows what a real implementation's Smart Campaign list looks like — many parallel Rules, one per denomination × delivery method:

The naming convention in the screenshot — Tarjeta regalo | denomination | action — is a good template if you're building this from scratch. Keeps the list scannable as it grows.

Unique vs generic codes

The single decision you make when generating a coupon code is how many codes to create vs how many redemptions per code to allow. The two extremes:

• Many unique codes, 1 use each — generate, say, 1,000 codes of length 10, each redeemable once. Distribute one per recipient. Safer (a leaked code costs you exactly one redemption); harder (you need a way to deliver one code per person).
• One generic code, N uses — generate 1 code, allow it 1,000 redemptions. Distribute it once; everyone uses the same string. Easier to share; riskier (anyone can pass it on, and the bound is just the redemption count — not "only the people you intended").

Hybrids exist (10 codes × 100 uses each, for example) but most clubs land at one of the two extremes.

When to pick which

• Small group, trusted channel — unique codes are over-engineered. Generic with a low redemption cap (50, 100) is fine.
• Larger group, mixed trust — unique codes via mail-merge. The per-recipient delivery is the cost; the per-leak bound is the benefit.
• Anything sold for money (gift cards) — always unique. Each card carries a value tied to a sale, and value-bearing codes that can be redeemed multiple times are a refund hazard.

Where to manage them

Marketing → Coupon codes in the left nav opens the list of code records — each row is one campaign's worth of codes (e.g. "Tarjeta regalo digital | 100 €" with 3,000 codes of length 10, each available for 1 use):

The columns capture the unique-vs-generic decision at a glance:

• Quantity — how many codes exist in this record.
• Available per Code — how many redemptions each code allows.
• Quantity × Available per Code = total possible redemptions.

A Quantity 3000, Available 1 row is unique mode (3,000 single-use codes). A Quantity 1, Available 1000 row would be generic mode.

Click into a row to see the codes themselves and to generate / import / export them:

Three operations on the detail screen:

• Generate codes — produces a new batch of random codes within the record's parameters (length, quantity). Use this when first setting up the record, or when topping up an existing record for a new distribution.
• Import codes — upload a CSV of pre-existing codes (e.g. for migrating from a previous loyalty system). Useful when you've already printed cards with specific codes that need to keep working.
• Export codes — download the codes as a CSV for offline distribution (mail-merge, partner handoff). The export includes the redemption status — used / not used, who used it, when.

The Used / Used At / Used By columns make it easy to audit which codes have been redeemed and by whom — particularly useful for staff-discount programs where you want to spot leaked codes (e.g. one code redeemed twenty times in one week from non-employee members).

Gotchas

5 things to watch for when running coupon-code campaigns

• A code with no Rule does nothing. The Coupon codes management surface generates the string and tracks redemptions; the Rule with Enters a coupon code trigger is what actually rewards the member. Build the Rule before you distribute the code, or members will enter codes and see no effect.
• Generic codes can run out mid-distribution. If you set Available per code to 100 and the code reaches 100 redemptions before the last person has used it, late entries error. Pad your cap or switch to unique codes if the audience is bigger than your cap allows for.
• Once shared, generic codes leak. Bound the risk by capping Available per code, but assume any generic code reaches an audience beyond your target. The Used By column on the code detail is your audit surface — spot check it for non-members or off-segment redemptions.
• The Rule's Coupon code is X condition is what scopes the action. A Rule with the trigger but no condition fires on every coupon entry tenant-wide — the wrong action runs for the wrong members. Always set the condition to the specific code(s) the Rule should react to.
• Codes don't expire on their own. Unless you build expiry into the Rule (e.g. via a timing condition or by setting the Rule to Paused after a date), old codes can still be redeemed years later. For seasonal campaigns, plan the wind-down.