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

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

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

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: 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: 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

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

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: 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.	The customer's screen is unchanged.	Ranks the next offer the customer can buy in one confirmation, or none.
The safeguardsThe conditions that stop it.	Still unchanged: the action waits 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.	Recommends. The system that holds the right confirms, charges or provisions.
When it goes wrongThe failure, and the 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.

The failure, and the 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.

Request a working session