Skip to content
HeuriTel
Sign in
Decisioning and Next Best Action

Loyalty & Rewards

Reward what a reward can change, not what would have happened anyway.

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.

For Loyalty, rewards and CVM teams.

Read the journey More in Decisioning and Next Best Action
The decision, annotated from the record

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

The customers worth rewarding, the reward that fits, and the rewards that would only pay for behaviour already given.

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

Before anything reaches the customer: Eligibility, reward budget, liability, abuse and consent checks pass.

What would reach them: Grant the reward through the loyalty ledger and tell the customer how to use it. On App, SMS, USSD, Partner.

Annotated, not computed. No engine runs on this page. Read the journey in full

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

The journey below is written for a generic operator. Tell us your market and it will be presented in it.

Configure a demonstration
The decision

The customers worth rewarding, the reward that fits, and the rewards that would only pay for behaviour already given.

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.

  • The promised reward, granted as the programme's terms require
  • A smaller reward, or a partner benefit, where it changes the outcome at lower cost
  • A tier change instead of a one-off reward
  • No reward, recorded, where the behaviour would have happened anyway
What it does

Three things it helps you decide or do.

  • Read the behaviour, the threshold and the liability together

    Points, redemptions, recent spend and the programme's liability position are what a reward decision is judged on, not the threshold alone.

    • customer_id
    • account_type
    • tenure_days
    • active_products
    • recharge_30d
    • usage_30d
    • revenue_30d
    • last_contact
    • consent_status
    • outcome_label

  • Compare rewards against no reward

    The promised reward, a smaller one, a partner benefit, a tier change and no reward are ranked, and the budget, liability, abuse and consent checks can refuse.

    • No consent
    • ineligible product
    • price/catalogue mismatch
    • contact cap
    • credit/fraud block
    • channel unavailable
    • control assignment

  • Keep the grant, the redemption and the effect apart

    What was granted, what was redeemed and what changed against a held-out group are recorded separately, so a redemption is never counted as retention.

    • Decision log
    • eligibility snapshot
    • price/order response
    • delivery receipt
    • control assignment
    • revenue/outcome ledger
The journey

Reward the behaviour a reward can actually change

No demonstration is configured for this product yet.

Loyalty & Rewards: the situation this product is about

Loyalty, rewards and CVM teams

What the customer experiencesWhat 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.
View requirements Read the journey in full

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

Assumptions, costs and the record’s five answers
  1. 01
    Desired result

    The result wanted.

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

  2. 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

  3. 03
    Evidence required

    The records kept to show it.

    Decision log; eligibility snapshot; price/order response; delivery receipt; control assignment; revenue/outcome ledger

  4. 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

  5. 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

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

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.
Technical detail

Inputs, decision logic, systems touched, records kept.

Four questions an evaluation asks in a different order every time. Every field is the workbook’s own, unedited.

What would we need from your systems, and how much history?

Attributes required

  • customer_id
  • account_type
  • tenure_days
  • active_products
  • recharge_30d
  • usage_30d
  • revenue_30d
  • last_contact
  • consent_status
  • outcome_label

Also useful, not required

  • Network experience
  • digital clickstream
  • complaints
  • location cohort
  • household/account links
  • partner purchases

8-12 weeks of customer, usage, revenue, product, contact and outcome history; stable customer key; one executable channel

The 12 definitions underneath

12 in this product

  1. HeuriTel LoyaltyDecision definitionHT-0148

    Identify eligible records for loyalty, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0148
  2. HeuriTel RewardsDecision definitionHT-0149

    Identify eligible records for rewards, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0149
  3. HeuriTel Loyalty PointsDecision definitionHT-0150

    Identify eligible records for loyalty points, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0150
  4. HeuriTel Loyalty TiersDecision definitionHT-0151

    Identify eligible records for loyalty tiers, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0151
  5. HeuriTel Personalised RewardsDecision definitionHT-0152

    Identify eligible records for personalised rewards, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0152
  6. HeuriTel Partner RewardsDecision definitionHT-0153

    Identify eligible records for partner rewards, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0153
  7. HeuriTel Reward RedemptionDecision definitionHT-0154

    Identify eligible records for reward redemption, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0154
  8. HeuriTel Loyalty RetentionDecision definitionHT-0155

    Identify eligible records for loyalty retention, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0155
  9. HeuriTel Referral RewardsDecision definitionHT-0156

    Identify eligible records for referral rewards, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0156
  10. HeuriTel Customer GamificationDecision definitionHT-0157

    Identify eligible records for customer gamification, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0157
  11. HeuriTel Reward Liability OptimisationDecision definitionHT-0158

    Identify eligible records for reward liability optimisation, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.

    /d/HT-0158
  12. HeuriTel Reward Abuse PreventionDecision definitionHT-0159

    Detect and prioritise reward abuse prevention risk using bounded rules and models, then pass the signal to the authorised fraud or transaction-control system.

    /d/HT-0159

Search definitions across every product

Implementing it

Four stages, and what has to be true before the next one starts.

12-16 weeks to pilot; 2-4 additional weeks per market after reusable interfaces exist. A team of 8 roles, named in the record rather than promised.

  1. 01

    Scope

    One use case, one value unit and a denominator finance has agreed to. Without these there is nothing a later result can be compared against.

    • Confirm value unit
    • select use case
    • baseline denominator
  2. 02

    Connect

    The attributes mapped from your systems, and the decision and outcome interfaces working in both directions.

    • map attributes
    • integrate decision and outcome APIs
  3. 03

    Validate

    Eligibility agreed, a dry run with nothing sent, then a controlled pilot with a holdout that is actually respected.

    • build eligibility
    • dry run
    • controlled pilot
  4. 04

    Operate

    The live loop: decide, check, execute through your systems, capture what came back, and measure against the control.

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

Who does it. 1 telecom product lead · 1 CVM specialist · 1 data engineer · 1 ML engineer · 1 integration developer · 0.5 QA · 0.5 DevSecOps · 1 deployment coordinator

Four states are tracked, and each is assessed against your systems.

Readiness is assessed per client: nothing is offered as pilot-ready until your data, your integration and your authority have been checked.

Readiness

Needs client data and integration review

The client’s data and integration position.
Runtime / build state

Target product definition

What exists as running software.
Surface state

Not audited

Whether this product shows the entry anywhere.
Client status

Not assessed

Where a named client has reached.

Next steps from here.

12 definitions sit under Loyalty & Rewards. The two links that matter first are the journey this page describes, and the rest of the family it belongs to.

Read the whole journey Read the scenario in full The rest of Decisioning and Next Best Action Ask a question first

Related products, and why

In the same area: Customer retention and the next best pack

Which customer should hear from us, with what, and through where?