Loyalty, rewards and CVM teams

Reward the behaviour a reward can actually change

A customer has hit the points threshold the programme promised a reward for. Another is about to lapse, and a reward might keep them. A third would have stayed anyway.

View requirements The product that runs it: Loyalty & Rewards

A pilot's requirements are specified: the data, the authority and the consent design.

Seen by the customer · App

From the record, not a run: what would reach them, on App, SMS, USSD, Partner.

The case

Annotated from the record

What happened

A customer crosses a loyalty threshold, or is about to stop doing what the programme rewards.

A customer has hit the points threshold the programme promised a reward for. Another is about to lapse, and a reward might keep them. A third would have stayed anyway.

What it reads

Points, tier and redemption history
Recent recharge and usage behaviour
Reward cost and the programme's liability position
Consent and abuse signals

Checks before anything is sent

Eligibility, reward budget, liability, abuse and consent checks pass.

Every option considered, including doing nothing

The promised reward, granted as the programme's terms requireConsidered
A smaller reward, or a partner benefit, where it changes the outcome at lower costConsidered
A tier change instead of a one-off rewardConsidered
No reward, recorded, where the behaviour would have happened anywayConsidered

Doing nothing is one of the outcomes, and it is recorded with its reason. The options are the record's own; a run decides between them.

Evidence record

Preview

Reference: The reference of the saved run.
Decision: One of the options, including no action, with the reason.
Checks: Eligibility, reward budget, liability, abuse and consent checks pass.
Evidence kept: Threshold event
eligibility
reward cost
liability position
grant record
redemption
outcome
The measures: Behaviour kept or changed against a held-out group, net of the reward's cost and liability.
Connection: Written on every record: the systems the run read, and the sample it ran on.

The shape of the record, with no values. A reference appears only after a run is saved.

The improvement, and how it is measured

Hypothesis

A reward that changes behaviour earns its cost; one that rewards what would have happened anyway is liability with a thank-you note attached.

Modelled

The mechanism that could produce the result, stated; the figure is measured in the pilot.

Observed

Measured in a pilot’s validate stage, on your systems, against a comparison agreed first.

The result, the mechanism, the measurement, and the record’s five answers

Desired result

Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails

Mechanism

Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain

Measurement

Randomised holdout where feasible; intent-to-treat primary view; pre-declared denominator; guardrails for complaints, margin and opt-out

Measured on: Eligible population; treatment rate; conversion; incremental revenue; ARPU; churn; contact rate; margin; opt-out; decision latency

01
Desired result
The result wanted.
Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails
02
Mechanism
The mechanism that could produce it.
Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain
03
Evidence required
The records kept to show it.
Decision log; eligibility snapshot; price/order response; delivery receipt; control assignment; revenue/outcome ledger
04
Costs and risks
The cost, and the ways it can go wrong.
Costs: Setup fee + annual product subscription; optional managed execution fee; optional verified-outcome fee with agreed baseline
If it fails: Fail closed on eligibility/consent/price; queue retryable events; do not duplicate orders; route exception to campaign operations
05
Measurement approach
The measure that shows it helped.
Randomised holdout where feasible; intent-to-treat primary view; pre-declared denominator; guardrails for complaints, margin and opt-out
Measured on: Eligible population; treatment rate; conversion; incremental revenue; ARPU; churn; contact rate; margin; opt-out; decision latency

Measured in the pilot's validate stage, on your systems, with the comparison agreed first. Every line above is the record's own design intent.

The business side

The change: Behaviour kept or changed against a held-out group, net of the reward's cost and liability.
Running cost: Setup fee + annual product subscription; optional managed execution fee; optional verified-outcome fee with agreed baseline
What evidence supports it: Threshold event, eligibility, reward cost, liability position, grant record, redemption and outcome.

The journey in detail

Step by step, from both sides

Step	What the customer experiences	What the operator does
The momentThe moment that started it.	A customer crosses a loyalty threshold, or is about to stop doing what the programme rewards.	Reads points, tier and redemption history, recent recharge and usage behaviour, reward cost and the programme's liability position, consent and abuse signals.
The decisionThe decision to be made.	The customer's screen is unchanged.	Ranks a reward, a tier change, a partner benefit or no reward against its cost and its likely effect.
The safeguardsThe conditions that stop it.	Still unchanged: the action waits until every check has passed.	Eligibility, reward budget, liability, abuse and consent checks pass.
The actionThe action that reaches the customer.	Grant the reward through the loyalty ledger and tell the customer how to use it. Reaches them on App, SMS, USSD, Partner.	Recommends. The system that holds the right confirms, charges or provisions.
When it goes wrongThe failure, and the recovery.	The reward would go to an account that is farming the programme, and the liability grows without any behaviour changing.	The abuse check holds the grant, the case is routed to the programme owner with the evidence, and the customer is told the reward is under review rather than silently denied.
The resultThe change it made.	What changed for them is what is counted; nothing else is claimed.	Behaviour kept or changed against a held-out group, net of the reward's cost and liability.
The proofThe proof anyone can check.	Can be answered for, later, from the record.	Threshold event, eligibility, reward cost, liability position, grant record, redemption and outcome.

Operator systems remain authoritative. HeuriTel reads these to propose an action; it does not decide on their behalf.

The failure, and the recovery

What goes wrong

The reward would go to an account that is farming the programme, and the liability grows without any behaviour changing.

What happens then

The abuse check holds the grant, the case is routed to the programme owner with the evidence, and the customer is told the reward is under review rather than silently denied.

The products in this journey

Runs the decision
Loyalty & Rewards
When a threshold is crossed or a customer is about to lapse, compare the promised reward, a cheaper one, a tier change and no reward, against the cost and the likely effect.
Contributes
Pack, Pricing & Recharge
the packs a loyalty pack or discount is drawn from
Contributes
Customer Growth & CVM
the decision that says whether a reward is the right treatment at all
The definition it demonstratesHeuriTel Personalised Rewards
Results it movesGrow customer revenue

Available to see today

A pilot's requirements are specified: the data, the authority and the consent design.

Request a working session