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.

Request a working session The product that runs it: Data, Platform & Decision Operations

Read the journey; a working session shows it running.

Seen by the customer · App

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

The case

Annotated from the record

What 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

The one action the rules, the models and the catalogue agree is permitted and bestConsidered
A control assignment, so this customer receives nothing and is measuredConsidered
A deferral until the missing data is freshConsidered
No action, logged with the rule that refusedConsidered

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: 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: 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 decision with its control group can be shown to have worked; a decision without one can only be shown to have happened.

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: 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.	The customer's screen is unchanged.	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 unchanged: the action waits 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.	Recommends. The system that holds the right confirms, charges or provisions.
When it goes wrongThe failure, and the 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.

The failure, and the 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 decision
Data, 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.
Contributes
Customer Growth & CVM
the decisions this platform runs, and the checks they share
Contributes
AI 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

Read the journey; a working session shows it running.

Request a working session