Run a Tiered Loyalty Program in n8n Without Rewarding Twice

A store launches a loyalty program, wires up "spend over $100, get a coupon," and calls it retention. Three months later the same five customers have each been emailed the same coupon eleven times because nothing tracked who already got rewarded. A trigger isn't a program. A program remembers.

n8n loyalty program automation turns one-off reward triggers into a recurring, stateful engine: it scores every customer into a tier on a schedule, sends the reward that matches their tier, and dedupes so nobody's rewarded twice in a cycle. The store API supplies the spend data, Google Sheets holds the points ledger, and n8n does the scoring and routing.

The templates ranking for this term are single-trigger ("order over $X → coupon") or referral-only. None of them recompute tiers on a schedule, scale the reward by tier, or guard against double-rewarding. That's the gap a real loyalty engine fills.

What a loyalty workflow can actually automate

A loyalty program is a recurring scoring job with rewards attached:

• Read order history per customer from the store or a Sheet on a schedule.
• Compute spend, frequency, and recency over a rolling window.
• Map each customer to a tier by threshold.
• Route each tier to a distinct reward via a Switch.
• Dedupe so a customer gets one reward per cycle, not one per run.
• Log points, tier, and reward issued to Google Sheets.

That's not a coupon trigger. It's a scoring engine that runs on a clock.

Why single-trigger reward flows fall apart

Here's the take worth standing behind: a loyalty automation without a dedupe guard actively harms retention. A recurring workflow that re-sends the same reward every run teaches customers the offer is permanent and infinite, so the coupon stops driving urgency and starts eroding margin on people who'd have paid full price.

Tiers fix the value side, dedupe fixes the timing side, and you need both. Recompute tiers each run so movement is automatic, but track the last reward per customer per cycle so the engine issues each reward once. The Schedule trigger drives the cadence; the ledger in Sheets is the memory. Drop the memory and the program becomes a coupon firehose.

A program that can't remember what it already gave away isn't loyalty. It's leakage.

The loyalty pipeline

Schedule trigger → Read order history → Score per customer
                                              │
                              Map to tier (bronze/silver/gold)
                                              │
                  Already rewarded this cycle? → yes → skip
                                              │ no
                  Switch on tier → tier-specific reward email
                                              │
                          Log tier + reward + date (Sheets)

1. Pull the history

A Schedule trigger fires weekly or monthly. Read each customer's orders from the store API or a mirrored Google Sheet. Keep the window explicit (trailing 90 days, say) so recency actually counts and a customer who's gone quiet drifts down a tier instead of coasting on a year-old purchase.

2. Score and tier

A Code node sums spend and order count, then maps to a tier by threshold. Recompute every run. A customer who crosses the silver line this month moves up without anyone touching a list. Write the new tier to the ledger.

3. The dedupe guard

Before issuing anything, check the ledger for a reward already sent this cycle at this tier. If one exists, skip. This is the guard that separates a loyalty program from a coupon firehose.

4. Route by tier

A Switch node sends each tier down its own branch: bronze gets free shipping, silver a percentage off, gold early access or a higher-value code. The reward scales with value instead of treating a first-time buyer like a top customer.

5. Send and log

Send the tier-appropriate email, then log the customer, tier, reward, and date to Sheets. That row both feeds next cycle's dedupe and gives you a clean view of what the program is actually spending.

Implementation patterns worth stealing

Pattern: cycle-scoped dedupe key. Build a key from customer_id + tier + cycle_period and check it before sending. The same customer at the same tier in the same month maps to one key, so the reward fires once no matter how often the workflow runs.

key = customerId + ":" + tier + ":" + cyclePeriod
IF ledger.has(key) THEN skip
ELSE sendReward(tier); ledger.add(key); log(...)

Pattern: tier-down is allowed. Don't lock customers into their highest-ever tier. Recency-weighted scoring should let a lapsed gold customer slide to silver, which makes the win-back email at that transition genuinely meaningful instead of just decorative.

n8n nodes you'll use most

Getting started

1. Decide tier thresholds and the rolling window before building anything.
2. Wire a Schedule trigger and read order history per customer.
3. Add a Code node that scores and maps each customer to a tier.
4. Build the cycle-scoped dedupe key and the IF that checks the ledger.
5. Add a Switch that routes each tier to a distinct reward email.
6. Send the reward and log customer, tier, reward, and date to Sheets.
7. Test by running the pass twice in a row and confirming nobody gets a second reward.

For the recurring tier-scoring, tier-specific email, and Sheets-log backbone, the Membership Churn Recovery Engine already wires daily per-member scoring and tier-routed personalized emails you adapt from churn risk to loyalty tier.

Loyalty works best when it's targeted, not blasted. The n8n email segmentation guide covers the engagement scoring that decides who's worth a reward in the first place, and the churn prevention patterns post shows the same scheduled-scoring discipline applied to saving accounts before they lapse. Pair them with the Membership Churn Recovery Engine and rewards land on the customers who actually move the number.