Customer Intelligence
One decision-ready view of a customer — identity, context, usage and the audience rules that include or exclude them — so that teams stop producing different answers to the same question from CRM, billing, charging and consent systems.
Runnable demonstrationintegrated workflow — The stages are joined by persistence, identity and authorisation inside the platform. This does not mean integrated with an operator system.
A journey you can run end to end on a synthetic dataset for your market, today.
Internal, simulated and disconnected. Nothing has been sent to or executed in an operator system.
The journey runs on approved sample data for a market, or on a workbook an operator returns. Every figure on the operator screens is labelled with the dataset it came from.
Verified work email required to run it. Demonstration data; no operator system is connected.
Three things it helps you decide, each visible in the run below
Understand the customer
One record, from the fields the schema requires, with the checks that read it.
- Inputs
- 10 required fields in the registered schema heuritel.pack-dropout.dataset v7
- Sources named by the contract: CRM, billing, usage, care, consent
- The sample customer: 36 months' tenure, 900 a month, 6 weeks since the last pack, 41% of the pack used
- Decisions
- Marketing consent: Has this customer agreed to be contacted for offers, on this channel?
- Contact frequency: Would this exceed how often the customer may be contacted?
- Fair value: Does the proposed pack suit how much they actually use?
- Margin floor: Does the incentive leave the action worth taking?
- Open service case: Is there an unresolved fault or complaint on this account?
- Evidence
- 5 of 5 checks pass for the sample customer on the neutral sample dataset
- Every check states its owner system and why it passed or refused, in this market
- Identity is a subject key; MSISDN, IMSI, IMEI and account ids are refused at upload
Compare actions
Every option the scenario permits, ranked, with the checks each one needs — and no action as an option in its own right.
- Inputs
- Offer a pack that matches how they actually use data (act)
- Discount the pack they were already buying (act)
- Check for a service or coverage problem first (investigate)
- Take no action, and record why (no-action)
- Decisions
- 4 of 4 options are permitted for the sample customer
- The ranking arrives at: Offer a pack that matches how they actually use data
- Why: Their usage fits a smaller pack than the one they were buying. A fair-value match is more likely to be taken than a discount on the pack they already stopped buying.
- Evidence
- The option chosen, and every option refused with the check that refused it
- The policy the decision was made under: heuritel.pack-dropout.scenario v1
- A second named person must approve the recommendation before it is recorded as decided
Follow the result
What a run keeps, what a second person decides, and where the record stops.
- Inputs
- An accepted dataset version, its content hash and the run's input fingerprint
- The recommendation, the options and the checks, stored as a snapshot
- Decisions
- Approved, rejected or revision requested — by a role that may decide and a person who did not make the run
- The decision changes the record and nothing else: no bill, no message, no case
- Evidence
- A stored run replays from its snapshot; it is never recomputed
- Execution mode is written as simulated on every run; connection is disconnected
- Not recorded, because not implemented: execution.request, execution.receipt, outcome.observed, attribution, reconciliation
The demonstration's computation, on the sample
- Checks5 of 5pass for the sample customer on the neutral sample dataset
- Options4 of 4permitted, including no action
- RecommendationActOffer a pack that matches how they actually use data
- Required fields10schema v7, template v7
- ApprovalTwo peoplea second named person decides; the maker cannot
- ExecutionSimulatedwritten on every run; connection disconnected
Synthetic sample dataset FX-NEUTRAL. No accuracy, uplift, recovered value or customer impact is measured here, because nothing has been executed; the measurement design is in the scenario and is a design, not a result.
Move an input and watch the decision change
Five bounded inputs on an example customer HeuriTel invented. Each one is read by a check, so moving it changes an answer that is computed, not displayed — including to no action, which is a result. The old value, the new value, the result and the rule that decided it are shown with every change. Nothing is written down and the sample dataset is not changed.
The customer, as the records have them
Customer · ILL-NEU-0001 · 36 months · Regular data buyer
Unchanged, as the sample records have it.
Offer a pack that matches how they actually use data
Their usage fits a smaller pack than the one they were buying. A fair-value match is more likely to be taken than a discount on the pack they already stopped buying.
Small weekly pack · 190 · 1.5 GB for 7 days · 72 margin after the incentive
Every check permits it, so the ranking chose the option worth the most to both sides.
The checks, and who owns each answer
| Check | Result | Why |
|---|---|---|
| Marketing consentConsent and preference system | Permits | Consented on SMS. |
| Contact frequencyCampaign management system | Permits | Last contacted 25 days ago; the floor is 14. |
| Fair valueProduct catalogue and pricing | Permits | Using 41% of the pack they were buying, so a smaller pack is the fair match. |
| Margin floorCommercial finance | Permits | 72 remains on Small weekly pack after the incentive. |
| Open service caseCare and service management | Permits | No unresolved case on this account. |
The open-case check reads this market’s own records rather than a field on the customer, so it is not one of the controls.
The customer’s outcome
A smaller weekly pack matching your recent usage is available. Reply 1 to accept.
Reply 0 to stop receiving these offers.
English · SMSThe failure this market demonstrates
Usage or care data has not refreshed inside the window the decision requires, so eligibility cannot be established.
No market has been configured, so usage and care data have no agreed freshness window. Eligibility cannot be established.
Remedy. No action is taken on stale context. The decision returns no-action with the source and its age named.
Handed to Data operations, with the source and freshness recorded.
Sample records, computed in your browser. Record set FX-NEUTRAL v3, scenario SCN-PACK-DROPOUT. See the whole journey, with the receipt and the evidence record
Inputs, decision logic, systems touched, records kept
What does the workbook carry, and what is refused?
Required fields (heuritel.pack-dropout.dataset v7)
- record_key · text
- subject_key · identifier · refused
- customer_moment · text
- eligibility · text
- proposed_action · text
- ai_confidence · number
- baseline_value · number
- expected_uplift · percent
- simulation_state · text
- data_status · text
The sample customer, on the neutral sample dataset
- Tenure 36 months · segment Regular data buyer
- Typical monthly spend 900
- 6 weeks since the last pack · 41% of it used
- Consented channels: SMS · last contacted 25 days ago
Identity policy
- Use subject_key; never upload raw MSISDN/IMSI/IMEI/account IDs
- Operator-controlled subject_key only; no reversible mapping in workbook
Template v7. Synthetic, invented by HeuriTel; an operator's own workbook replaces it only through the gated upload.
Which checks run, what each one owns, and how the ranking decides?
Policy checks, with the result for the sample customer
- Marketing consent — pass. Consented on SMS.
- Contact frequency — pass. Last contacted 25 days ago; the floor is 14.
- Fair value — pass. Using 41% of the pack they were buying, so a smaller pack is the fair match.
- Margin floor — pass. 72 remains on Small weekly pack after the incentive.
- Open service case — pass. No unresolved case on this account.
Validation rules the upload enforces
- Identity: Use subject_key; never upload raw MSISDN/IMSI/IMEI/account IDs
- Schema: Use the published column names and declared types
- Freshness: Declare source timestamp and reporting period
- Consent/authority: Supply purpose, consent and authority where applicable
- Provenance: Name source system, extract ID and transformation version
The ranking
- Offer a pack that matches how they actually use data: permitted
- Discount the pack they were already buying: permitted
- Check for a service or coverage problem first: permitted
- Take no action, and record why: permitted
Scenario profile heuritel.pack-dropout.scenario v1 · configuration heuritel.pack-dropout.scenario@1#2c886138. Deterministic: the same inputs give the same ranking.
What would an operator connect, and what is connected today?
Source systems in the contract
- CRM
- billing
- usage
- care
- consent
Connected today
- None. Every run computes from a synthetic sample dataset or from a workbook an operator returned through the gated upload.
Execution
- The operator's campaign management and charging systems. HeuriTel proposes the action and records it; neither the offer nor the charge happens anywhere else.. Not implemented: execution.request, execution.receipt, outcome.observed, attribution, reconciliation.
Internal, simulated and disconnected. Nothing has been sent to or executed in an operator system.
What does a run record, and what does it not?
Computed on every run
- recommended.id — The scenario option the ranking arrives at for this customer.
- recommended.kind — Whether the recommendation is to act, to hold, or to take no action. No action is a possible and complete answer.
- recommended.rationale — Why this option, in the scenario's own words. Deterministic rule reasoning, not a model's.
- options[].id — Every option the scenario considers, ranked, including the ones the checks refused.
- options[].permitted — Whether every check this option requires passed.
- options[].refusedBy — The checks that refused this option, by id. Empty where it was permitted.
- checks[].id — Each customer-protection and commercial check the scenario applies.
- checks[].state — pass, refuse or not-applicable, for this customer in this market.
- checks[].detail — Why the check passed or refused, in this market, for this customer. Deterministic rule reasoning.
- options[].margin — The margin after incentive the option would leave, formatted in the run's locale and the market's currency.
- provenance.scenarioProfileId — The scenario policy the decision was made under, and its version.
- provenance.configurationHash — A digest of the effective policy values the decision was made under.
- provenance.sampleDatasetId — The market sample dataset the run was composed against, and its version.
- provenance.profileVersion — The approved tenant profile version the run computed through.
- provenance.connection — Always "disconnected". No adapter to any operator system is connected.
- run.reference — A short reference a person can quote for this run.
- run.inputFingerprint — A digest of everything that decided the result: dataset, sample dataset, profile, policy and engine versions.
- dataset.contentHash — SHA-256 of the normalised dataset the run computed from.
- execution.outcome — The simulated execution state: delivered, undeliverable, held or no-action. What the operator's systems would return, derived from the run.
- execution.result — The simulated receipt's one-line result, and the detail beneath it.
Persisted with the run
- options[].price — The price of the offer the option would use, formatted for display.
- amounts.typicalMonthlySpend — The customer's typical monthly spend, formatted for the screen.
- run.executionMode — Always "simulated" until an authorised connector exists.
- run.engineVersion — The deterministic engine version the run computed under.
- approval.state — proposed until an authorised second person decides; then approved, rejected or revision_requested.
- approval.actorRole — The role that carried the authority at the moment of the decision.
- approval.reason — The decider's own words, never interpreted.
Not implemented
- execution.request — A request to an operator system to carry the recommendation out.
- execution.receipt — A receipt from an operator system confirming delivery.
- outcome.observed — What the customer actually did after the action.
- attribution — Attribution of an observed outcome to this decision.
- reconciliation — Reconciliation of this run against an operator's own records.
The output contract is the seventh workbook role; the guard refuses a contract that claims delivery or an observed outcome by editing a row. Where the contract uses its own engineering term for the synthetic sample dataset, it is shown here as “sample dataset”, and the key that names it as provenance.sampleDatasetId.
Schema heuritel.pack-dropout.dataset v7 · template v7 · scenario profile heuritel.pack-dropout.scenario v1 · configuration heuritel.pack-dropout.scenario@1#2c886138.
Four steps, and what is true of each one today
01 Scope
- Demonstrated now
- One scenario, pack-dropout recovery, with its checks, options and measurement design registered.
- Configured during a pilot
- The operator's own scenario, market and policy tolerances agreed and versioned.
- Required for production
- A scope with an accountable owner and a bounded cohort.
02 Connect
- Demonstrated now
- A workbook: the template downloads, an edited copy is validated and accepted as a version. No system is read.
- Configured during a pilot
- Indicative extracts from the named sources, on the subject key, through the same validation.
- Required for production
- Live connectors. Not built; refused to everyone by design today.
03 Validate
- Demonstrated now
- Structure, identifiers, bounds and the protected settings, on every upload; a run is computed from an accepted version and replays from its snapshot.
- Configured during a pilot
- The operator's validation rules and freshness expectations, enforced the same way.
- Required for production
- Reconciliation against the operator's own ledgers. Not built.
04 Operate
- Demonstrated now
- A recommendation, approved or refused by a second person, changing the record and nothing else.
- Configured during a pilot
- Decisions reviewed against the operator's policy; still nothing executed.
- Required for production
- Execution request and receipt, observed outcome, attribution. Not implemented, by contract.
Buyer and operator
- Buyer
- CVM Director
- Operated by
- CVM and retention analysts inside the operator's own tenant
The result this product produces
- A governed dataset an operator has formally accepted, with its version and hash recorded
- A deterministic recommendation with every option and the reason it was permitted or refused
- A replayable record that reproduces what was decided, on what data, under whose authority
Built today
- A workbook cell drives the runtime schema through a registry.
app/_lib/contracts/schema-registry.ts - An uploaded pack is validated, structurally and for direct identifiers.
app/_lib/demo/data-pack.ts - An accepted dataset is immutable and a run is computed from it.
app/_lib/demo/run-repository.ts - A run replays from its stored snapshot rather than recomputing.
app/_lib/demo/run-difference.ts - A second named person must approve the recommendation.
app/_lib/demo/approval-repository.ts
Still to build
- An output contract: the run states what it recommends, not what it is expected to produce
- Sensitivity analysis beside the no-action baseline
- Everything below the decision: execution, receipt, exposure, observed outcome, attribution
Propositions that include this product
- Managed CVM and ExperimentationWe run your value-management engine and prove what it earned, with your team in the approval loop.
- Next-best-action and Retention DecisioningOne ranked, permitted action per customer moment — including no action — with the reason recorded.
- Revenue Assurance and Anomaly OperationsFind revenue leaking between systems, and evidence the recovery.
Streams beneath this product
The workspace for this product
5 workspace screens belong to this product. They open for a member of an organisation whose subscription includes it.
Sources of this description
PRODUCT_01_CUSTOMER_INTELLIGENCE.md§1 Customer problemapp/_lib/contracts/customer-intelligence-runtime.ts— the registered schema this product validates