Digital channel, app and e-commerce teams

Make the next in-app offer one the customer can actually buy

A customer opens the app to check their balance. Three banners compete for the space. Last month's banner was for a pack they had already bought.

View requirements The product that runs it: App & Digital Sales

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, Web, USSD, in Kiswahili, English.

The case

Annotated from the record

What happened

A customer opens the app with a need the catalogue can meet and a history that says what they will not buy.

A customer opens the app to check their balance. Three banners compete for the space. Last month's banner was for a pack they had already bought.

What it reads

What the customer came to do, from the session
Eligibility and the entitlements already held
Price, stock and fulfilment state from the catalogue and the order system
Consent and the offers already shown

Checks before anything is sent

Eligibility, price, consent, stock or entitlement and order-system checks pass.

Every option considered, including doing nothing

The offer the customer is eligible for and most likely to buy, with its priceConsidered
A reminder of something they started and did not finishConsidered
No offer, and the screen they came forConsidered

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: Eligibility, price, consent, stock or entitlement and order-system checks pass.
Evidence kept: Session
eligibility
offer rationale
quote
confirmation
order reference
fulfilment
The measures: Confirmed, fulfilled in-app orders against abandonment, not offers shown.
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

Hypothesis

An offer that can be bought in one confirmation earns; one that cannot be fulfilled is an abandonment the app caused.

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

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

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: Confirmed, fulfilled in-app orders against abandonment, not offers shown.
Running cost: Setup fee + annual product subscription; optional managed execution fee; optional verified-outcome fee with agreed baseline
What evidence supports it: Session, eligibility, offer rationale, quote, confirmation, order reference and fulfilment.

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 opens the app with a need the catalogue can meet and a history that says what they will not buy.	Reads what the customer came to do, from the session, eligibility and the entitlements already held, price, stock and fulfilment state from the catalogue and the order system, consent and the offers already shown.
The decisionThe decision to be made.	Nothing reaches the customer yet.	Ranks the next offer the customer can buy in one confirmation, or none.
The safeguardsThe conditions that stop it.	Still nothing. No action is sent until every check has passed.	Eligibility, price, consent, stock or entitlement and order-system checks pass.
The actionThe action that reaches the customer.	Show one offer with its price, take one confirmation and fulfil through the order system. Reaches them on App, Web, USSD, in Kiswahili, English.	Recommends. The system that holds the right confirms, charges or provisions.
When it goes wrongRefusal, failure and recovery.	The offer is confirmed, and the order system rejects it, leaving the customer with a charge pending and nothing delivered.	The confirmation is held until the order system accepts, the customer sees the state rather than a spinner, and a rejected order is reversed with the reason recorded.
The resultThe change it made.	What changed for them is what is counted; nothing else is claimed.	Confirmed, fulfilled in-app orders against abandonment, not offers shown.
The proofThe proof anyone can check.	Can be answered for, later, from the record.	Session, eligibility, offer rationale, quote, confirmation, order reference and fulfilment.

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 offer is confirmed, and the order system rejects it, leaving the customer with a charge pending and nothing delivered.

What happens then

The confirmation is held until the order system accepts, the customer sees the state rather than a spinner, and a rejected order is reversed with the reason recorded.

The products in this journey

Runs the decision
App & Digital Sales
When a customer opens the app, compare the offer they are eligible for, a reminder of what they started and the screen they came for, and fulfil through the order system or not at all.
Contributes
Pack, Pricing & Recharge
the packs and prices an in-app offer is drawn from
Contributes
Campaigns & Personalisation
the contact policy that decides whether a banner may compete with the screen the customer came for
The definition it demonstratesHeuriTel Digital Sales
Results it movesImprove customer acquisition · Grow customer revenue

Available to see today

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

View requirements Request a working session