AI agent · Telecom · Chase what is missing
Provisioning failures
The software watches each order through every provisioning step, reads the error behind a stuck order, retries only when it is safe and applies fixes you have approved. What it cannot resolve reaches the owning team with the cause and the evidence.
Typical volumes for this process, not a client figure.
Orders fail silently and get found days later.
Detected, retried, and escalated with the actual cause attached.
Where the time goes today
A customer order for a new line, a broadband connection, a SIM activation or a plan change passes through a chain of steps: inventory reservation, number assignment, network activation, subscriber profile, billing account, equipment shipment, sometimes an installation appointment. When one step fails, the order often stays 'in progress'. Nobody is told. The first signal is frequently the customer calling to ask where their service is.
Operations teams work a fallout queue built from reports of orders older than expected. For each one, an analyst opens the order, reads error messages in three or four systems and decides what kind of failure it is. A timeout on the activation platform needs a retry. An unrecognised address needs a data fix from another team. A number still being ported needs waiting. A defect in an interface needs IT.
The errors here are costly. A blind manual retry of a step that had half-completed activates a second SIM or opens a second billing account. Orders cancelled and re-keyed lose their history. And one failing interface can produce hundreds of fallouts before anyone connects them, because each analyst sees only their own share.
How the agent works
- Watch every orderThe agent tracks each order against the expected duration of each step. An order past its step deadline, or carrying an error, is opened as a failure.
- Find the failed stepIt reads order state and error responses from order management, activation, inventory and billing, then classifies the failure: transient, data error, dependency not ready, or system defect.
- Retry safelyFor a transient failure it first checks the target system to see whether the step half-completed. Only then does it retry, on the schedule you set, for example after five minutes and again after an hour.
- Apply approved fixesFor data errors on your approved list, such as an address format the activation platform rejects, it corrects the field and resubmits. Anything else goes to the owning team with the exact field and value in question.
- Escalate with the causeWhen retries are exhausted or the cause is unknown, it opens a ticket with the failed step, the error, what was tried and similar failures in the last hour. Failures with one cause are grouped into one incident, not hundreds of tickets.
What stays with a person
Network and IT engineers own system defects and decide when a platform is healthy enough to resume retries. Cancelling an order, changing a product or an appointment, and offering compensation stay with people, as does any conversation with the customer about a delay.
The list of approved fixes and the retry schedule belong to your operations team. The agent can show which unfixed errors keep recurring, which is often the quickest way to find the next fix worth approving, but it does not add fixes to its own list.
What it reads, what it produces
| It reads | It produces |
|---|---|
| Order management: order state and step history | A failure record per order: step, cause, actions taken |
| Activation and provisioning platform responses and logs | Logged retries and fixes, with before and after values |
| Network and number inventory | Tickets to owning teams with the evidence attached |
| Billing and CRM account records | Grouped incidents when one cause affects many orders |
| Your runbooks and known-error list | A daily fallout report by cause and by system |
| The ticketing system, for open incidents |
Controls that come with it
- State check before every retry, so a step that half-completed is never run twice.
- A retry limit per step; after the last attempt, the order is escalated rather than left waiting.
- Only fixes from the approved list are applied, each logged with before and after values and reversible.
- If failures with one cause pass a threshold within an hour, the agent stops retrying that step and raises an incident instead.
- A weekly sample of orders resolved without a person is checked by an analyst.
How you know it works
- Time from failure to detection
- Time from failure to service provisioned
- Share of failures resolved by retry, by fix, and by escalation
- Duplicate activations or accounts created by retries, which should be zero
- Orders first reported by the customer rather than detected
Is your process ready?
- Written rules: known failure causes and their fixes are documented in runbooks.
- Systems: order and activation platforms expose state and error codes, and vendor licences permit automated retries.
- Cheap check: the order either reaches a provisioned state or it does not, and that can be checked automatically.
- Volume: thousands of orders a day with a standing fallout queue.
- Same description: operations and IT agree on what counts as a failure and who owns each cause.
The five candidacy checks are explained, with an exam, in the free Module 01.
What goes wrong
- Generic errors such as 'internal error' that name no cause; step-level logs are needed first.
- Retrying calls that are not safe to repeat, creating duplicate activations or charges.
- Retry storms against a platform that is already struggling.
- Step deadlines set too tight for steps that legitimately wait, such as porting windows or installation dates.
Questions we get
Is this not just a retry script?
If every failure were a timeout, a retry script would do, and you should build that. The agent earns its cost when errors vary: different systems, different wording, some safe to retry and some not, some fixable from data elsewhere in the order. Reading those errors and deciding the next step is the work your analysts do by hand today.
Can it make things worse?
Yes, and the controls exist because of that. The main risk is repeating a step that had partly succeeded, which the state check before each retry is there to prevent. The second is retrying against a failing platform, which the incident threshold stops. Both risks are tested on past fallouts before go-live, and duplicate activations are tracked as a metric that should stay at zero.
Does it contact the customer?
Not by itself. It can trigger your standard delay notification when an order passes a deadline you set, using wording you approve. Anything beyond that, such as a new appointment, a different product or compensation, is a conversation for your customer team, who see the cause and the actions taken on the order record.
What do we need to start?
A few months of fallout records with the resolution written down, even briefly, and access to the error responses from each system. Those records become the reference set: the agent is run against them to check it classifies each failure the way your analysts did, and that the retries and fixes it would have applied match what actually worked.
Want this agent on your process?
Tell us about your version of this process — volumes, systems, what goes wrong. A person answers with an approach and a price, usually within two working days, or tells you it is the wrong project.