Loyalty, rewards and CVM teams
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.
A pilot's requirements are specified: the data, the authority and the consent design.
Seen by the customer · App, Kiswahili
From the record, not a run: what would reach them, on App, SMS, USSD, Partner, in Kiswahili, English.
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
Checks before anything is sent
Eligibility, reward budget, liability, abuse and consent checks pass.
Every option considered, including doing nothing
No action is a valid outcome, and it is recorded with its reason. Nothing is computed on this page: the options are the record's own, and no run has decided anything.
The shape of the record, with no values. A reference appears only after a run is saved.
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.
Desired result: Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails
Modelled not observed
No figure is modelled for this journey. The mechanism that could produce the result is stated instead.
Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain
Observed
Nothing yet. Measurement begins in a pilot’s validate stage, on your systems, against a comparison agreed first.
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
The result wanted.
Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails
The mechanism that could produce it.
Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain
The records kept to show it.
Decision log; eligibility snapshot; price/order response; delivery receipt; control assignment; revenue/outcome ledger
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
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
Nothing has been observed for this product. Every line above is the record's own design intent; measurement begins in a pilot's validate stage, on your systems, with the comparison agreed first.
The business side
| 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. | Nothing reaches the customer yet. | 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 nothing. No action is sent 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, in Kiswahili, English. | Recommends. The system that holds the right confirms, charges or provisions. |
| When it goes wrongRefusal, failure and 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.
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.
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.
the packs a loyalty pack or discount is drawn from
the decision that says whether a reward is the right treatment at all
A pilot's requirements are specified: the data, the authority and the consent design.