The Decision Authority for Money in Telecom Customer Operations

Polidex is the decision authority for money in telecom customer care: the thing that lets your AI agents make the refund, credit, and compensation decisions they hand to a human today, the same way on every channel.

A Cap Is Not a Decision

A guardrail says "no credit over $50." That is a limit. It is not a decision.

Take a customer disputing a $180 roaming charge, one of the most common money contacts in your markets. A decision is: if you never sent a bill-shock warning, credit the full overage; if you did warn them but they have been with you five years, credit half as goodwill; cap it either way at one month's plan value; and if this is their second goodwill credit in 90 days, don't auto-approve it, route it to a supervisor. Then apply the credit, flag whether to offer a roaming pack so it does not recur, and log which rule version decided it. That is what a telecom operator actually needs, and it is what a customer is asking for whether they reach chat, the IVR, the app, or an outsourced call center.

The same shape holds for an outage: credit one-thirtieth of the monthly plan for each day of the confirmed outage, cap seven days, route to a supervisor because this customer already hit their annual credit cap, and log the rule version that decided it.

Polidex is the authority that produces that decision, the same way, on every channel. Your billing system records what the customer was charged. It does not decide what they are entitled to when something goes wrong. Polidex does, before anything reaches billing.

Every Other Tool Is Built for a Single Agent. You Have a Dozen Money Surfaces.

Most CS solutions are built for a single agent. A telecom operator has a dozen places a customer can ask for money: chat, voice, IVR, the app, retail point of sale, and two to five outsourced BPOs, across multiple markets, currencies, and regulators.

When policy lives inside one vendor's agent, it is re-written and drifts in every one of them. It is locked to a vendor you may be mid-migration from. And it produces no cross-channel audit trail. The risk is not one bad refund. It is the same wrong SLA-credit rule firing across chat, voice, the app, and three outsourced call centers, in four markets, for six weeks before finance reconciles it, and then not being able to tell the regulator which rule applied to which customer.

For thirty years the authority on what a customer was owed was a person with a headset, with a supervisor as backstop. Telecom operators are removing that person this year, replacing them with AI across every channel at once. Nothing is replacing the judgment. Something has to be the authority.

The Gap, Made Concrete

Sixty days into your agentic CS deployment, the retention team flags a pattern. The AI agent has been approving full ETF waivers for customers citing general dissatisfaction. Your policy qualifies that reason code for a partial waiver up to $150, supervisor approval required. The agent has been granting full waivers. Consistently. On every contact where the phrase appeared. And your voice channel, running a different prompt, has been handling it differently again.

Your CS Director asks the obvious questions. What policy was it applying? What version? When did this start? Has it happened on other issue types? Did the app and the BPO apply the same rule?

The answers are all the same. It is in the system prompt. We can share the file. There are, it turns out, several files.

This is the natural outcome of deploying capable AI agents, one per channel, without a single authority that governs what they are all authorized to decide.

Why Telecom CS Is a Different Environment

Customer support is policy-intensive everywhere. Telecom is a different order of complexity, and that matters when AI agents are making autonomous money decisions at scale across many channels. Three things compound to make the environment uniquely exposed.

Policy surface area, all at once.

Most CS verticals have one or two policy-heavy domains. Telecom has all of these simultaneously: billing disputes and credit caps, broadband and landline outage credits, missed-engineer-appointment and delayed-install compensation, device upgrades and warranty exceptions, international roaming and bill-shock adjudication, ETF waivers and cancellation tiers, retention offers, plan management, and escalation routing across 12 distinct trigger conditions. Each scenario has its own credit limit, its own approval threshold, its own fault classification. An AI agent is not answering questions in this environment. It is making money decisions on nearly every contact, on every channel you run.

Regulatory and legal exposure with named enforcement.

Telecom operators operate under regulators with enforcement authority. The FCC in the US. Ofcom in the UK, whose automatic compensation scheme already sets fixed sums a provider owes for delayed broadband or landline repairs, missed engineer appointments, and delayed installs, paid whether or not the customer asks. The TCP Code in Australia. The EU AI Act's Article 26 deployer duties and Annex III requirements phase in through December 2027 and require demonstrable audit trails for automated decision systems, specifically the ability to show what an autonomous system was authorized to do, for a specific customer, at a specific time. Inconsistent treatment across channels is not just a CX failure here. It is a documentable record of differential treatment that regulators and attorneys are trained to find.

Churn economics that measure errors in dollars per day.

Telecom is a thin-margin, high-churn business. Retention and credit decisions have direct P&L impact. A telecom operator handling 500 CS contacts per day with a 3% policy error rate on money decisions produces 15 wrong decisions every day. Over 90 days, that is 1,350 decisions, each with a dollar value attached. Now multiply the inconsistency by the number of channels answering the same question differently. At agent speed, the loss compounds before anyone notices.

What Your Agents Are Running On Today

Ask your CS operations team how your AI agent knows what it is allowed to do. The answer is almost always the same: the system prompt. Then ask how the IVR knows, and the app, and the outsourced BPO. The answer is a different prompt each, maintained by a different team, on a different schedule.

The system prompt is a text document. It contains natural language instructions: what the agent can offer, what it should escalate, how much it can credit. It is edited when something goes wrong. It accumulates rules after every incident. It is not versioned. It has no approval workflow. There is no conflict detection, so contradictory instructions coexist in the same document until someone notices. And when a specific decision is challenged, there is no reliable way to reconstruct which version of the policy was in effect on that date, on that channel.

In a telecom CS environment with over 50 baseline rules across four domains, five authority tiers, and regulatory obligations for consistent treatment, running that across a dozen channels is not a minor gap. It is a structural mismatch. Three failure modes follow.

Policy drift, and rogue by drift, multiplied.

Incremental edits to a system prompt do not check for contradictions, and no edit to one channel reaches the others. Different agents on different channels run slightly different instructions. The rule governing a credit decision last quarter may not be the rule today, and there is no record of the change. An agent running on outdated policy is rogue not because it was attacked, but because nobody updated its prompt when the rule changed. Now picture that drifting on a different timeline in every channel at once.

Unenforceable limits.

A credit limit written in natural language inside a system prompt is a behavioral instruction. An agent optimizing for task completion treats a constraint as an obstacle to navigate. Enforcement from inside the agent's own context is not structural enforcement. It is a suggestion, and it is a different suggestion in every channel.

The audit trail gap.

Observability tools capture what agents did: which tools were called, at what time, with what parameters. That is a log, not an authorization record. Knowing the agent called the credit API with a $400 parameter at 14:32:07 is a log entry. Knowing the agent was authorized to issue a credit of up to $100 under billing policy version 12, that it exceeded that authorization, that no policy governed the overage, and that the app applied a different rule to the same situation, that is the governance record. The log cannot produce it, and no per-channel prompt can either.

What Polidex Ships With for Telecom

Polidex is not a configuration project. The telecom CS domain model arrives pre-built. The default ruleset covers the four primary domains: billing disputes and outage credits, device upgrades and warranty, roaming and ETF/cancellation, and retention offers and escalation routing. This telecom-specific credit math, SLA-credit proration, ETF waivers, roaming goodwill, is what no general tool ships and what reads as an insider rather than an outsider.

Fixed-line money decisions, broadband and landline outage credits and missed-appointment compensation, are authored in the same model and routed through the same authority tiers. The pre-built ruleset is mobile-led today, and the fastest starting point for mobile-led and converged operators.

Over 50 pre-configured rules across four domains.

The policy baseline a telecom operator would otherwise author from scratch is already there. Credit caps, fault classification, eligibility windows, exception paths. Telecom operators confirm thresholds against their own margin model. They do not build the policy model.

Five agent authority tiers.

Frontline agent, senior agent, supervisor, retention specialist, director. Every decision routes to the correct tier based on context, dollar value, and rule classification. Permanent pricing changes and multi-month free service grants are explicitly excluded from agent and supervisor authority. The tier model is enforced, not advisory, and it is the same for every channel that calls the authority.

12 escalation conditions, mapped to target tiers.

Escalation routing is a policy decision, not a judgment call. Each of the 12 conditions has a specific target tier and urgency level. Your agents do not improvise the edge cases. They route them, the same way whether the contact came in over chat, voice, or a BPO desktop.

What you confirm: dollar thresholds, discount percentages, timing windows, and the specific authority levels for your operation. What you do not build: the policy model itself.

What Changes With One Decision Authority

Polidex sits between your channels and the billing, CRM, and network systems they act on. Any channel queries Polidex for a decision. Polidex evaluates the context against the configured ruleset and returns a structured envelope: the decision, the rule version in effect, the authority tier, and a signed authorization token. The channel does not interpret the policy. It acts on the result. Because they all call the same authority, chat, voice, the app, and the BPO cannot drift apart.

Polidex: one decision authority every channel calls

Plain-language authorization records.

Every decision Polidex produces includes a statement of what was authorized and why, in plain English. For example: "The agent was authorized to issue a partial ETF waiver because the customer cited general dissatisfaction without a qualifying condition. Maximum waiver: $150. Supervisor approval required before proceeding." That is the record a CS Director, a compliance reviewer, or a regulator can read, for any channel.

Consistent decisions across every channel.

The same policy query with the same context produces the same decision every time, regardless of channel, time of day, or which agent platform routed it. This is not a training outcome. It is an infrastructure outcome.

Versioned policy.

Every rule is versioned. Every decision envelope references the rule version in effect at the time of the decision. When policy changes, the change propagates immediately to every channel that calls the authority. No system prompt edits in six places. No redeployment. No drift.

Exception handling as infrastructure.

Not every customer situation fits within policy. Polidex routes out-of-policy requests to the appropriate human approver with full context: what was requested, what policy says, what the exception would require. Your agents do not improvise side channels. They escalate cleanly, with a structured record.

Governance and Responsible AI

If you are authoring a Responsible AI framework for autonomous customer operations, this section is for you. The framework describes what governance should look like. It assumes an infrastructure that enforces the same money-decision policy across every channel and proves it. That infrastructure does not exist in a system prompt.

Audit the money decision, not just the conversation.

The regulatory question is not "does your AI have policies?" It is "prove what your autonomous systems were authorized to decide, for this customer, on this channel, at this time, and that it was consistent with every other channel." A conversation log and a governance document cannot answer that. A signed decision envelope, tied to a rule version and an authority tier, answers it by construction, for every channel that called the authority.

Prove authorization across every channel.

EU AI Act Article 26 places deployer duties on operators running autonomous decisioning. Ofcom and the TCP Code govern consumer credit and compensation. When an AI agent decides what a customer is owed, across multiple channels and markets, "which rule applied, on which channel, under which version, and did they agree" is the record the regulator asks for. One authority produces that record. A dozen prompts cannot.

Enforce the framework you are writing now.

The Responsible AI framework your governance team is authoring assumes an enforcement layer it does not itself provide. Polidex is that layer: the point where the framework's rules become the decision every channel has to carry, versioned, auditable, and the same everywhere.

Getting to Production

The path from confirmation to active policy enforcement is measured in weeks, not quarters. Four integrations underpin the decisions where live data is required.

Billing system. Active plan rates, credit history, current balances. Required for outage compensation calculations against actual plan value and for credit cap enforcement against cumulative history.

NOC incident management. Outage validation. Required to distinguish a documented mass network event from an individual service complaint, and to gate auto-credit eligibility on verified incidents.

Network coverage API. Coverage verification for relocation-based ETF waivers and coverage misrepresentation claims. Required to validate the qualifying condition before the waiver clears the agent tier.

Device financing system. Active installment plan balances. Required for early upgrade eligibility, lost and stolen replacement adjudication, and ETF calculations that include device financing components.

These are read-only data queries at decision time. No customer data is stored in Polidex.

On cross-channel, plainly. Polidex is a neutral decision authority any system calls over MCP or REST. Today's proven caller is your AI care agent. Because the authority is neutral and callable by any system, the same endpoint an agent calls can be called by an IVR, an app backend, or a BPO desktop tool. That is the architecture and the destination: one authority every channel answers to, rather than one more per-channel rulebook. We do not pretend to ship a pre-built connector for every channel today. We are the authority those channels call as you bring them on.