Run every AI assistant on routed, metered and audited providers, with a fallback and a human handoff already in place.
Requests are routed by language, cost and quality across approved providers, cached where safe, filtered for safety and handed to a person when the assistant should not answer; every model, prompt and change is registered, evaluated and audited.
For AI platform, digital service and compliance teams accountable for what assistants say and what they cost.
A customer asks the assistant to dispute a charge, and the assistant's providers are routed, metered and filtered but not authorised to decide.
The provider that answers, the assistant's permitted scope, and the moment a person takes over.
Answer from the provider that fits, within the policyConsidered
Answer with a safe fallback, where the provider failsConsidered
Hand over to a person with the conversation's contextConsidered
No answer, where the safety filter refusesConsidered
Before anything reaches the customer: Safety filter, policy limit, provider health, cost control and consent checks pass.
What would reach them: A person takes the conversation with its context; the customer is told who is answering, and the handoff is logged with its reason. On App, WhatsApp, Web.
The provider that answers, the assistant's permitted scope, and the moment a person takes over.
A customer asks the assistant to dispute a charge. The assistant's providers are routed, metered and filtered, and none of them is authorised to decide a dispute.
Answer from the provider that fits, within the policy
Answer with a safe fallback, where the provider fails
Hand over to a person with the conversation's context
No answer, where the safety filter refuses
What it does
Three things it helps you decide or do.
Route each request to the provider that fits, and meter it
AI routing, language routing, cost control, provider management and usage metering choose the provider and record the spend per request; the cache answers what it may.
Offer
service message
reward
channel change
human follow-up
suppress
do nothing
Filter, fall back and hand off
Safety filtering refuses an answer, fallback takes over when a provider fails and human handoff routes the conversation to a person, so a channel outage or a policy limit stops the assistant rather than the customer.
No consent
ineligible product
price/catalogue mismatch
contact cap
credit/fraud block
channel unavailable
control assignment
Register, evaluate and audit every model and change
The model registry, prompt management, model evaluation, observability, incident management, change approval and decision audit keep the record a regulator or an operator can examine.
Decision log
eligibility snapshot
price/order response
delivery receipt
control assignment
revenue/outcome ledger
The journey
Hand the conversation to a person before the assistant guesses
Approval, evidence and intervention surfaces.
AI platform, digital service and compliance teams
Step
What the customer experiences
What the operator does
The momentThe moment that started it.
A customer asks the assistant to dispute a charge, and the assistant's providers are routed, metered and filtered but not authorised to decide.
Reads the request and the policy that governs it, provider health, cost and language fit, the safety filter's result, consent and the customer's channel.
The decisionThe decision to be made.
Nothing reaches the customer yet.
Routes the request to the provider that fits, filters the answer for safety, and hands the conversation to a person when the policy says the assistant may not decide.
The safeguardsThe conditions that stop it.
Still nothing. No action is sent until every check has passed.
Safety filter, policy limit, provider health, cost control and consent checks pass.
The actionThe action that reaches the customer.
A person takes the conversation with its context; the customer is told who is answering, and the handoff is logged with its reason. Reaches them on App, WhatsApp, Web, in Kiswahili, English.
Recommends. The system that holds the right confirms, charges or provisions.
When it goes wrongRefusal, failure and recovery.
The fallback provider answers the dispute question with a confident guess about the refund, and the customer treats it as a promise.
The policy limit routes dispute questions to a person regardless of provider, the guess is found in the decision audit, and the prompt and the routing rule are corrected under change approval.
The resultThe change it made.
What changed for them is what is counted; nothing else is claimed.
Handoffs resolved by a person, against answers the assistant gave that it should not have.
The proofThe proof anyone can check.
Can be answered for, later, from the record.
Request, routing decision, provider and cost, filter result, handoff reason, agent's resolution and the decision audit.
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
Handoffs resolved by a person, against answers the assistant gave that it should not have.
Request, routing decision, provider and cost, filter result, handoff reason, agent's resolution and the decision audit.
Technical detail
Inputs, decision logic, systems touched, records kept.
Four questions an evaluation asks in a different order every time. Every field is the workbook’s own, unedited.
What would we need from your systems, and how much history?
Attributes required
customer_id
account_type
tenure_days
active_products
recharge_30d
usage_30d
revenue_30d
last_contact
consent_status
outcome_label
Also useful, not required
Network experience
digital clickstream
complaints
location cohort
household/account links
partner purchases
8-12 weeks of customer, usage, revenue, product, contact and outcome history; stable customer key; one executable channel
How is the action chosen, and what stops it?
Actions it may choose between
Offer
service message
reward
channel change
human follow-up
suppress
do nothing
Conditions that stop execution
No consent
ineligible product
price/catalogue mismatch
contact cap
credit/fraud block
channel unavailable
control assignment
Fail closed on eligibility/consent/price; queue retryable events; do not duplicate orders; route exception to campaign operations
What does it connect to, and what stays authoritative?
Your systems involved
CRM/CDP
campaign manager
product catalogue
OCS
order management
billing
consent registry
Interfaces
Customer/profile API
catalogue/eligibility API
campaign API
charging/order API
consent API
outcome event API
Channels
SMS
USSD
app
web
WhatsApp
outbound call
agent desktop
Charging, billing, catalogue, consent and order systems remain authoritative; HeuriTel decides only within approved policy.
What is kept, and how would a claim be tested?
Evidence required
Decision log
eligibility snapshot
price/order response
delivery receipt
control assignment
revenue/outcome ledger
The measures
Eligible population
treatment rate
conversion
incremental revenue
ARPU
churn
contact rate
margin
opt-out
decision latency
Privacy and regulation
Purpose limitation
consent and suppression
data minimisation
retention
explainability for material customer effects
local marketing rules
Randomised holdout where feasible; intent-to-treat primary view; pre-declared denominator; guardrails for complaints, margin and opt-out
The 18 definitions underneath
18 in this product
HeuriTel AI RoutingDecision definitionHT-0202
Identify eligible records for ai routing, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0202
HeuriTel AI Cost ControlDecision definitionHT-0203
Identify eligible records for ai cost control, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0203
HeuriTel AI Quality ControlDecision definitionHT-0204
Identify eligible records for ai quality control, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0204
HeuriTel AI Provider ManagementDecision definitionHT-0205
Identify eligible records for ai provider management, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0205
HeuriTel AI Usage MeteringDecision definitionHT-0206
Identify eligible records for ai usage metering, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0206
HeuriTel AI OperationsDecision definitionHT-0207
Identify eligible records for ai operations, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0207
HeuriTel AI Language RoutingDecision definitionHT-0208
Identify eligible records for ai language routing, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0208
HeuriTel AI FallbackDecision definitionHT-0209
Identify eligible records for ai fallback, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0209
HeuriTel AI CacheDecision definitionHT-0210
Identify eligible records for ai cache, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0210
HeuriTel AI Human HandoffDecision definitionHT-0211
Identify eligible records for ai human handoff, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0211
HeuriTel AI Model EvaluationDecision definitionHT-0212
Identify eligible records for ai model evaluation, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0212
HeuriTel AI Prompt ManagementDecision definitionHT-0213
Identify eligible records for ai prompt management, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0213
HeuriTel AI Safety FilteringDecision definitionHT-0214
Identify eligible records for ai safety filtering, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0214
HeuriTel AI ObservabilityDecision definitionHT-0215
Identify eligible records for ai observability, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0215
HeuriTel AI Incident ManagementDecision definitionHT-0216
Identify eligible records for ai incident management, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0216
HeuriTel AI Model RegistryDecision definitionHT-0217
Identify eligible records for ai model registry, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0217
HeuriTel AI Change ApprovalDecision definitionHT-0218
Identify eligible records for ai change approval, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0218
HeuriTel AI Decision AuditDecision definitionHT-0219
Identify eligible records for ai decision audit, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Four stages, and what has to be true before the next one starts.
12-16 weeks to pilot; 2-4 additional weeks per market after reusable interfaces exist. A team of 8 roles, named in the record rather than promised.
01
Scope
One use case, one value unit and a denominator finance has agreed to. Without these there is nothing a later result can be compared against.
Confirm value unit
select use case
baseline denominator
02
Connect
The attributes mapped from your systems, and the decision and outcome interfaces working in both directions.
map attributes
integrate decision and outcome APIs
03
Validate
Eligibility agreed, a dry run with nothing sent, then a controlled pilot with a holdout that is actually respected.
build eligibility
dry run
controlled pilot
04
Operate
The live loop: decide, check, execute through your systems, capture what came back, and measure against the control.
Ingest
qualify
score
apply limits/consent
assign control
execute approved action
capture delivery and business outcome
monitor/retrain
Who does it. 1 telecom product lead · 1 CVM specialist · 1 data engineer · 1 ML engineer · 1 integration developer · 0.5 QA · 0.5 DevSecOps · 1 deployment coordinator
Four states are tracked, and each is assessed against your systems.
Readiness is assessed per client: nothing is offered as pilot-ready until your data, your integration and your authority have been checked.
Readiness
Needs client data and integration review
The client’s data and integration position.Runtime / build state
Target product definition
What exists as running software.Surface state
Not audited
Whether this product shows the entry anywhere.Client status
Not assessed
Where a named client has reached.
Next steps from here.
18 definitions sit under AI Operations & Governance. The two links that matter first are the journey this page describes, and the rest of the family it belongs to.
What does every product stand on, and who helps us put it in?
Data, Platform & Decision OperationsRun every customer decision on one platform that keeps eligibility, consent, the control group and the outcome together.
Global Telecom AI TaaS & Deployment ServicesPut a telecom AI team on the ground for twelve to sixteen weeks, with named roles, acceptance gates and a handover your people can run.
Telecom AI Engineering ServicesAdd the telecom AI engineer, architect or specialist your programme is missing, for a bounded engagement with a handover at the end.
