Skip to content
HeuriTel
Sign in
Product 01

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.

Run the demonstration Inspect the sample data

Verified work email required to run it. Demonstration data; no operator system is connected.

What it does

Three things it helps you decide, each visible in the run below

  1. 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

  2. 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

  3. 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
Evidence

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.

Run it

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

Consented to be contacted on
With none of them, there is no permitted way to reach them.

Unchanged, as the sample records have it.

The decision

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

CheckResultWhy
Marketing consentConsent and preference systemPermitsConsented on SMS.
Contact frequencyCampaign management systemPermitsLast contacted 25 days ago; the floor is 14.
Fair valueProduct catalogue and pricingPermitsUsing 41% of the pack they were buying, so a smaller pack is the fair match.
Margin floorCommercial financePermits72 remains on Small weekly pack after the incentive.
Open service caseCare and service managementPermitsNo 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.

Every option considered, including doing nothing

  • Offer a pack that matches how they actually use dataChosenPermitted

    Small weekly pack · 190 · 72 margin

  • Discount the pack they were already buyingPermitted

    Monthly pack · 900 · 290 margin

  • Check for a service or coverage problem firstPermitted
  • Take no action, and record whyPermitted

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 · SMS

The 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

Technical detail

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.

Schema heuritel.pack-dropout.dataset v7 · template v7 · scenario profile heuritel.pack-dropout.scenario v1 · configuration heuritel.pack-dropout.scenario@1#2c886138.

Delivery

Four steps, and what is true of each one today

  1. 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.

  2. 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.

  3. 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.

  4. 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.
Who it is for

Buyer and operator

Buyer
CVM Director
Operated by
CVM and retention analysts inside the operator's own tenant
Intended outcomes

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
Evidence

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
Not built

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
Where it is sold

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.
All propositions
Catalogue

Streams beneath this product

Workspace

The workspace for this product

5 workspace screens belong to this product. They open for a member of an organisation whose subscription includes it.

Provenance

Sources of this description

  • PRODUCT_01_CUSTOMER_INTELLIGENCE.md §1 Customer problem
  • app/_lib/contracts/customer-intelligence-runtime.ts — the registered schema this product validates

Next steps

See a decision explainedAll sixteen products