Hypothesis
A decision with its control group can be shown to have worked; a decision without one can only be shown to have happened.
Desired result: Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails
Decisioning, data and CVM operations teams
Make one decision per customer, and keep the group you did not treat
A customer event arrives. Three rules, two models and a campaign each want something to happen. Only one thing can, and somebody has to be able to say afterwards whether it worked.
No demonstration is configured for this journey yet.
Seen by the customer · App, Kiswahili
From the record, not a run: what would reach them, on App, SMS, USSD, Web, in Kiswahili, English.
The case
Annotated from the recordWhat happened
A customer event arrives and three rules, two models and a campaign all have an opinion about what should happen next.
A customer event arrives. Three rules, two models and a campaign each want something to happen. Only one thing can, and somebody has to be able to say afterwards whether it worked.
What it reads
- The event and the customer's features at that moment
- Eligibility rules and the offer catalogue
- Consent and the contact cap
- Data quality and lineage of the sources
Checks before anything is sent
Data quality, eligibility, consent, contact cap and control assignment 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.
Evidence record
Preview- Reference
- Issued when a run is saved. An evaluation that was never saved has none.
- Decision
- One of the options, including no action, with the reason.
- Checks
- Data quality, eligibility, consent, contact cap and control assignment checks pass.
- Evidence kept
- Event
- feature snapshot
- rule
- model versions
- eligibility result
- consent
- control assignment
- decision log
- outcome ledger
- The measures
- Outcome of treated customers against the control group, per decision version.
- Connection
- Stated on every record. In the demonstration no operator system is connected, and each record carries that state.
The shape of the record, with no values. A reference appears only after a run is saved.
The improvement, and how it is measured
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
- 01Desired result
The result wanted.
Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails
- 02Mechanism
The mechanism that could produce it.
Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain
- 03Evidence required
The records kept to show it.
Decision log; eligibility snapshot; price/order response; delivery receipt; control assignment; revenue/outcome ledger
- 04Costs 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
- 05Measurement 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
- Outcome of treated customers against the control group, per decision version.
- Running cost
- Setup fee + annual product subscription; optional managed execution fee; optional verified-outcome fee with agreed baseline
- What evidence supports it
- Event, feature snapshot, rule and model versions, eligibility result, consent, control assignment, decision log and outcome ledger.
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 event arrives and three rules, two models and a campaign all have an opinion about what should happen next. | Reads the event and the customer's features at that moment, eligibility rules and the offer catalogue, consent and the contact cap, data quality and lineage of the sources. |
| The decisionThe decision to be made. | Nothing reaches the customer yet. | Resolves one decision from the eligibility rules, the offer catalogue and the consent held, or no decision, and assigns the customer to a control group first. |
| The safeguardsThe conditions that stop it. | Still nothing. No action is sent until every check has passed. | Data quality, eligibility, consent, contact cap and control assignment checks pass. |
| The actionThe action that reaches the customer. | Execute the one decision through the system of record, or hold the customer back as a control, and log both. Reaches them on App, SMS, USSD, Web, in Kiswahili, English. | Recommends. The system that holds the right confirms, charges or provisions. |
| When it goes wrongRefusal, failure and recovery. | The feature store is stale for one source and the decision reads yesterday's balance, so an ineligible customer is offered a pack they cannot pay for. | The data quality check refuses the decision, the customer is deferred rather than treated, and the source's freshness is flagged to data operations with the lineage. |
| The resultThe change it made. | What changed for them is what is counted; nothing else is claimed. | Outcome of treated customers against the control group, per decision version. |
| The proofThe proof anyone can check. | Can be answered for, later, from the record. | Event, feature snapshot, rule and model versions, eligibility result, consent, control assignment, decision log and outcome ledger. |
Operator systems remain authoritative. HeuriTel reads these to propose an action; it does not decide on their behalf.
Refusal, failure and recovery
What goes wrong
The feature store is stale for one source and the decision reads yesterday's balance, so an ineligible customer is offered a pack they cannot pay for.
What happens then
The data quality check refuses the decision, the customer is deferred rather than treated, and the source's freshness is flagged to data operations with the lineage.
The products in this journey
- Runs the decisionData, Platform & Decision Operations
Customer data, features, eligibility rules, the offer catalogue and consent feed one decisioning layer, and every decision is logged with the group it was assigned to and the outcome it produced.
- ContributesCustomer Growth & CVM
the decisions this platform runs, and the checks they share
- ContributesAI Operations & Governance
the providers and controls behind an assisted decision
- The definition it demonstratesHeuriTel Real-Time Decisioning
- Results it movesGrow customer revenue · Reduce fraud and identity risk
Available to see today
No demonstration is configured for this journey yet.