AI agent · Telecom · Sort & route
Number porting exceptions
A rejected or stalled port leaves a new customer waiting, and sometimes without service. The agent reads each porting exception, fixes and resubmits what your data can resolve, asks the customer only for what is missing, and routes the rest to the porting desk.
Typical volumes for this process, not a client figure.
Rejected ports land in a queue; the desk reads each reason and calls the customer.
Data errors fixed and resubmitted; the customer asked only for what is missing.
Where the time goes today
When a customer brings a number from another operator, your order system sends a port request through the porting process used in your market. The other operator validates it and either accepts, rejects with a reason code, or does not answer within the timer. On the agreed day the number moves and routing is updated. At each step something can go wrong, and every failure lands in a queue for the porting desk.
Rejections are the bulk: account number mistyped, name or address not matching the losing operator's record, an invalid porting code, a number already in another port, a partial port of a multi-line account submitted as a whole. The desk reads the reason code, often a free-text note as well, opens the order, compares what was submitted with what the customer supplied, calls or messages the customer, corrects and resubmits. Stalled requests need chasing through the inter-operator channel.
The most harmful exceptions are the quiet ones: a port marked complete where incoming calls still fail because routing was not updated, and a new SIM activated days before the number arrives. Customers experience these as a broken service, not a porting problem, and they reach the complaints team long before the porting desk sees them.
How the agent works
- Read the exceptionThe agent reads the reject code, the free-text reason, the timer status and any completion notice, and links the exception to the order, the customer and every number involved.
- Compare submitted dataIt compares what was sent with what the customer provided at sale, including an uploaded bill where one exists, to find typing and transcription errors.
- Fix and resubmitWhere the correct value is already in your records, it corrects the request and resubmits within the limits the porting rules allow, keeping the date aligned with SIM or line activation.
- Ask the customerWhere the fix needs something only the customer has, such as a porting code or the account number on the old bill, it sends one specific request by text or email and waits.
- Check routingFor ports marked complete, it checks the number's routing status in your number management system and raises a network ticket when calls cannot reach the new service.
- Route the restDisputes with the other operator, repeated rejections, business ranges and anything that looks like an unauthorised port go to the porting desk with the history attached.
What stays with a person
The porting desk keeps disputes with other operators, multi-line business ports where the customer's instructions are unclear, and any case where resubmission limits are close. A customer without service for longer than your threshold is always handed to a person, because the next step is usually a call, not a resubmission.
Suspected unauthorised ports go to your fraud team, not back into the queue. Signs include a recent change of contact details, a mismatch between the buyer and the account holder, or several ports requested from one account in a short time. The agent flags; people decide whether to stop the port.
What it reads, what it produces
| It reads | It produces |
|---|---|
| Port request status, reject codes and timer notices from the porting interface | Corrected and resubmitted port requests, with the change recorded |
| Orders and the details the customer supplied at sale | Specific requests to customers for missing details |
| Uploaded bills from the customer's previous operator | Network tickets for completed ports with failing routing |
| CRM contact history and customer preferences | A desk queue with history and reason for every handed-over case |
| Number management and routing status | A daily view of exceptions by reason code and sales channel |
| Your porting procedures and the rules that apply in your market |
Controls that come with it
- Resubmission only when the corrected value comes from a record, never from inference
- A cap on automatic resubmissions per request, below the limit in your market's rules
- Customers without service past your threshold always handed to a person
- Fraud indicators always sent to the fraud team, never resubmitted
- Every change logged: field, old value, new value, source record
- Any resubmission cancellable before the port date
How you know it works
- Days from first rejection to completed port
- Resubmissions rejected again
- Completed ports with failing routing, and how long they stay undetected
- Porting-related complaints per thousand ports
- Share of exceptions resolved without a desk contact
Is your process ready?
- Written rules: reject codes and resubmission limits are defined by the porting rules in your market, and your desk procedures are usually written. Unwritten habits, such as which codes justify a call, need writing down.
- Systems: the porting interface, order system and number management system must be reachable by software, with licences that permit automated submissions.
- Cheap check: the other operator validates every resubmission, so a wrong fix comes back as a rejection within the porting timer.
- Volume: hundreds of exceptions a day repays the build; a small operator with a few a week does not need it.
- One description: sales, the porting desk and network operations must agree who owns a port between rejection and routing.
The five candidacy checks are explained, with an exam, in the free Module 01.
What goes wrong
- Reject codes used loosely by some operators, so the free-text reason contradicts the code.
- Sales channels that capture the account holder's name differently from the bill, generating the same rejection every day.
- Activation of the new SIM or line not tied to the port date, leaving customers with two half-working services.
- Completion notices trusted without a routing check, so failing calls surface only as complaints.
Questions we get
Does the agent work on ports leaving us, as well as arriving?
This agent works on ports arriving from other operators, where exceptions delay a new customer. Requests to port numbers away from you need a different control, centred on validating the request and detecting unauthorised ports, and they carry different rules. The same approach applies, but it is a separate agent with its own thresholds.
How does it avoid resubmitting the same wrong data?
It resubmits only when the corrected value comes from a record: the customer's uploaded bill, a correction the customer supplied, or your own order data. It never guesses a plausible account number. Each resubmission counts against a cap below the limit in your market's rules, and a second rejection for the same reason goes to the desk.
What does the customer receive?
One message per missing item, saying exactly what is needed and where to find it, for example the account number printed on the previous bill. Messages follow templates you approve and the channel the customer chose at sale. The agent does not promise a porting date until the other operator has accepted the request.
How do we know it is working?
Before go-live, run it on a few hundred past exceptions whose correct handling your porting desk has confirmed, and compare. After go-live, the other operator's response is a free check: a correct resubmission is accepted, a wrong one comes back. Track repeat rejections and time to completed port weekly.
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.