How to run a customer loyalty programme
To run a loyalty programme that works operationally, the rules have to be simple enough for a customer to predict what they will earn. In Jestor, purchases connect to the customer record, balances are calculated rather than maintained, and redemptions are records with their own approval where needed.
Why loyalty programmes create operational load
Programmes are designed by marketing and operated by whoever serves the customer. Complex earning rules mean staff cannot answer basic questions, so every query becomes an escalation.
Customers who cannot predict their balance stop engaging, which defeats the purpose.
What operational simplicity requires:
- Earning rules a person can explain in one sentence
- A balance the customer can see without asking
- Redemption that does not require approval for small amounts
- A record of every adjustment made manually
- Expiry rules stated clearly in advance
Design decisions that affect operations
| Decision | Simple option | Operational cost of complexity |
|---|---|---|
| Earning rate | One rate | Tiered rates generate queries |
| Expiry | A fixed period | Rolling expiry is hard to explain |
| Redemption | Fixed increments | Variable values slow service |
| Exclusions | As few as possible | Each one is a dispute |
| Adjustments | Recorded with a reason | Untracked adjustments become abuse |
Step by step to structure it
- Connect purchases to the customer record, since the balance derives from them.
- Calculate the balance as a formula rather than a stored value.
- Make the balance visible to staff and to the customer.
- Record redemptions as records that reduce the balance.
- Require a reason on any manual adjustment.
- Apply expiry as a rule, with a warning before it happens.
- Report on liability, since unredeemed points are an obligation.
Why calculating rather than storing the balance matters
A stored balance drifts whenever an adjustment is made outside the process, and reconciling it later is impossible. Calculating it from the underlying transactions means the number is always explicable, and any discrepancy points at a specific record.
Why choose Jestor
In Jestor, purchases and redemptions are connected records so the balance is a formula, manual adjustments require a reason and are recorded with their author, expiry runs as an automation with a warning, and total liability is an indicator on the same data.
Frequently Asked Questions
Should the balance be stored or calculated?
Calculated from transactions, so it is always explicable. See jestor.com.
What causes most loyalty programme queries?
Rules complex enough that staff cannot explain them in one sentence.
Why record manual adjustments with a reason?
Because untracked adjustments are how programmes are abused.
Video Tutorial: Step by Step
With Jestor, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by AI. Discover Jestor at jestor.com and see how to take your company's operations to a new level of efficiency and control.