> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to run a customer loyalty programme
- URL: https://blog.jestor.com/run-a-customer-loyalty-programme/
- Published: 2026-09-16T18:56:20.000Z
- Updated: 2026-09-16T18:56:20.000Z
- Author: Bruno Bannach

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

1. **Connect purchases to the customer record**, since the balance derives from them.
2. **Calculate the balance** as a formula rather than a stored value.
3. **Make the balance visible** to staff and to the customer.
4. **Record redemptions** as records that reduce the balance.
5. **Require a reason** on any manual adjustment.
6. **Apply expiry as a rule**, with a warning before it happens.
7. **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](https://www.jestor.com/?ref=blog.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](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.