A port that went quiet
The customer signed on the 3rd. Their existing numbers, a main line and forty direct dial numbers, are coming across to your hosted platform, and they have told their staff which Friday the phones change over. The port was submitted to the wholesale supplier the same week. Then nothing happened, or at least nothing anyone saw.
Nine days later the supplier portal shows the port as rejected. The reason is an address mismatch with the losing provider's records: the customer moved offices two years ago and never updated the account. The rejection has been sitting on a status page that nobody opened, because the person who submitted the order is also doing site surveys and chasing broadband installs. The first your team hears of it is the customer's office manager asking why the new handsets are showing a temporary number on the Friday.
Resubmitting is easy. Getting the date back is not. A rejected port usually goes back into the queue, and the customer's carefully planned switchover now needs replanning with call forwarding in the gap.
Why ports slip without anyone seeing
The port itself is not the problem. The problem is that the information needed to manage it sits in three places that do not talk to each other.
- The order and its status live in each wholesale supplier's portal, and each portal words its statuses differently.
- The date promised to the customer lives in your CRM or in an email thread, not next to the port.
- The paperwork (letter of authority, latest bill from the losing provider, account number) lives in a shared inbox or someone's downloads folder.
- Rejections arrive as a status change rather than a notification, or as an email to a generic address that everyone assumes someone else reads.
- Single number ports, multi-line ports and ranges of numbers follow different processes and lead times, so a single 'check ports on Monday' habit does not fit all of them.
When volume is low, a good provisioning person holds all of this in their head. As soon as they are on holiday, or you take on a batch of new customers after a PSTN migration push, the gaps show.
What a missed rejection really costs
The obvious cost is a delayed go-live. The less obvious ones build up behind it. You may be paying the supplier for new lines and seats that the customer cannot use yet, and you cannot start billing them in full. Your engineer's visit to swap handsets has to be rebooked. And the customer, who chose you because the last provider was hard to deal with, now has a story about you to tell.
| What happens | Where it lands |
|---|---|
| Port rejected, not seen for days | Go-live date lost, customer told late |
| Wrong account number on the request | Resubmission and a new wait |
| Port date moved by the losing side | Engineer visit on the wrong day |
| Port completes but routing not updated | Calls fail on the first morning |
| Numbers ported, old lines not ceased | Customer billed twice, blames you |
None of these is rare. Each one takes a person an hour or two to unpick, usually on the phone to a supplier help desk, and each one lands on the same small provisioning team.
The port tracker we build
- Every port order becomes one record, created when the sale is closed, holding the numbers, losing provider, account number, installation address, promised date and the customer contact.
- Required paperwork is checked before submission: letter of authority signed, a recent bill attached, and the address on the bill matching the address on the order. Mismatches are flagged to sales while the customer is still engaged.
- Port status is read from your wholesale suppliers, by API where the supplier offers one and by a scheduled portal check or the status emails where it does not, and mapped to a single set of statuses your team understands.
- Each port is compared against its promised date. A rejection, a date moved by the other side, or no movement past the usual lead time raises an alert to a named owner, not a shared inbox.
- Rejection reasons are recorded so the next order can be checked for the same problem before it is submitted.
- When a port completes, a checklist opens for the follow-on tasks: routing on your platform, test calls, and the cease on any lines the customer no longer needs.
We build this alongside your existing billing platform and CRM rather than replacing them. The tracker is the layer that watches the dates.
What Monday looks like afterwards
Your provisioning lead opens one screen and sees every live port sorted by risk: rejected, at risk of missing the promised date, waiting on the customer, and on track. Rejections turn up the morning they happen, with the reason and the customer contact next to them, so the call to the customer goes out while there is still time to save the date.
Sales see which of their orders are held up on paperwork. Account managers can answer 'where is my port' without asking provisioning. And when someone is off, their ports do not go dark with them.
Is this your situation?
- You find out about port rejections from the customer, not from the supplier.
- Port status is checked by logging into each supplier portal in turn.
- Letters of authority and bills are chased after the order is submitted, not before.
- Nobody can list, right now, every port due to complete in the next fortnight.
- Old lines keep billing after the numbers have moved.
If two or more of these sound familiar, the fix is usually visibility rather than more staff.