Number Porting and DID Inventory Software: Why Nobody Knows a Port Failed Until the Customer's Phones Go Dead

Why porting is the failure your customer notices first

A twelve line dental practice signs with you on the fifth. The port is submitted on the sixth. On the eleventh at 8:04am the practice manager calls because the phones are dead, patients cannot get through, and the practice has been open four minutes. Your team starts digging. The losing carrier rejected the request on the eighth because the service address on the customer service record reads a suite number your form omitted. The rejection arrived as an email to a shared mailbox. Nobody read it. The submitted date passed, the number moved out of your control window, and now you are inside a live outage with a customer who is measuring the damage in missed appointments.

Nothing about that sequence is unusual. Porting is a workflow that spans two companies who are commercially opposed, runs on regulated timers, and communicates through forms and email. The FCC's one business day interval for simple ports sets an expectation with customers that the mechanics do not always meet, and the mechanics fail in boring ways: an account number keyed wrong, a PIN the customer does not know, an authorised signature from someone who left, an address that matches the billing record but not the service record.

Meanwhile the other half of the problem sits in a spreadsheet. Spare DIDs, reserved ranges, numbers held for a customer who has not signed yet, numbers disconnected last quarter that are in an aging window before they can be reissued. Somebody maintains that file. Somebody else assigns a number from it that was already promised to a different account, and now two customers have a claim on the same DID.

Problem 1: port state is scattered across email, portals and memory

A port request has a real lifecycle: drafted, submitted, acknowledged, rejected with reason, resubmitted, FOC received with a date and time, activated, or cancelled. Every one of those transitions has a timestamp, a counterparty and a document. In most operators none of it lives in one place. The submission is in an upstream provider portal. The rejection is in email. The FOC date is in a note somebody wrote in the ticketing system. The activation is in the switch.

The consequence is that nobody can answer the simplest operational question: which ports are at risk today. Not which ports exist, which ones are sitting past an expected response, or have a rejection older than four hours, or have an FOC date tomorrow with no provisioning task raised. That question is the entire job, and it currently gets answered by a person reading a mailbox.

What a custom build does: make the port request a first-class object with an explicit state machine, hold every counterparty message against it, and drive a work queue from state and elapsed time rather than from a human scanning email. Rejections get parsed into a reason code and routed to whoever can fix that class of problem. The customer's expected cutover date is derived from the FOC, not from a promise made in sales. And the whole thing is an append-only history, because when a port goes wrong and a customer threatens to leave, the record of who did what and when is the difference between a credit and a lawsuit.

Problem 2: the incumbents solve adjacent problems, not yours

iconectiv administers the NPAC in the United States, which is the authoritative routing database that makes portability work at all. That is infrastructure, not workflow software. It tells the network where a number lives. It does not manage your relationship with a losing carrier or track why a request bounced. NetNumber sits in a similar space around number data, routing and registry services. TransNexus is strong on call authentication and related analytics, and useful in a voice operator's stack, but it is not a port order management system.

So the middle is empty. Between the regulated registry and your switch sits the part where the work actually happens: producing a correct request per counterparty, chasing a response, handling a rejection, and coordinating cutover with provisioning. Most operators fill that with a spreadsheet plus their upstream provider's portal, and if you use more than one upstream, you have more than one portal with different semantics and no combined view.

What a custom build does: normalise across counterparties. One internal port object, with per-counterparty adapters that know that this carrier wants a specific form layout, that one requires a copy of the bill, that another rejects anything where the authorised contact does not match the CSR exactly. That knowledge currently lives in the heads of two people on your provisioning team. Encoding it is the whole value.

Problem 3: number inventory is money, and it is in a spreadsheet

Numbers are stock. You hold ranges from upstream providers, you assign DIDs to customers, you reserve blocks for enterprise accounts mid-negotiation, you take back numbers on churn, and you hold disconnected numbers through an aging window before reissuing them so the previous owner's callers stop hitting them. Every one of those is an inventory state, and the spreadsheet models none of them.

The failures are predictable. Double allocation, where two accounts get promised the same DID. Orphaned numbers you are paying an upstream fee on that no customer is using, which is a pure monthly leak nobody notices because it is spread across invoices. Reissuing a number too quickly and inheriting the previous owner's inbound traffic, which in the United States also carries reassigned number exposure that your compliance team will care about the moment a customer uses those DIDs for outbound campaigns.

What a custom build does: inventory with states, expiry on reservations, aging windows enforced automatically, and reconciliation against upstream provider billing so you can see the numbers you pay for that nobody uses. That reconciliation alone typically finds enough dormant spend to be worth reporting to finance in the first month.

Problem 4: port-out is a retention event you are handling blind

Everyone builds port-in first, because port-in is revenue. Port-out is where you lose customers, and it usually arrives as a request from a competing carrier that your team processes without anyone commercially responsible being told. By the time account management hears about it, the FOC has been issued and the customer has already signed elsewhere.

There is also a validation obligation on your side. You should be rejecting requests that fail authorisation checks, and you should be applying the same criteria consistently, because inconsistent port-out rejection is exactly the behaviour that generates regulatory complaints. A build that treats port-out as a first-class flow gives you both: a consistent, auditable validation path, and an alert to the account owner the moment a request lands, while there is still time to have a conversation.

Problem 5: the cutover is a coordination problem, not a form

When the FOC date arrives, several things must happen close together: the number activates on the new network, your switch has the routing and the customer's users, devices are registered, and for business voice the emergency location record has to be right on the number that just moved. Miss the last one and you have a compliance problem attached to a working phone, which is worse than a dead one because nobody notices.

What a custom build does: derive a provisioning task set from the FOC automatically, sequence it, and block activation until preconditions pass. If the customer's seats are not built or the location record is missing, the system says so on the day before rather than at 8:04am on the day. Coupling porting to provisioning in one workflow is the difference between a scheduled event and a fire drill.

What this costs and how long it takes

Across projects Digital Heroes has delivered, a working port orchestration and DID inventory system runs $65,000 to $150,000 across 10 to 16 weeks. That covers inventory with reservation and aging, port-in and port-out lifecycle with rejection handling, FOC tracking, counterparty adapters for your main partners, switch provisioning hooks, an audit trail and an operations queue. A broader platform adding multi-country porting rules, toll-free RespOrg handling through the toll-free registry, automated request generation per counterparty, customer-facing port status pages and analytics runs $180,000 to $400,000 phased across 6 to 11 months.

What drives price up here: the number of counterparties and upstream providers, because each one is a different form, a different response format and a different set of unwritten rules. Multi-country, because porting regulation and timers differ by jurisdiction and there is no shared model. Toll-free, because RespOrg mechanics are their own discipline. And switch integration, because a BroadSoft-lineage platform, a class 4 softswitch and a cloud provider API are three different problems.

What keeps price down: starting with port-in only, one upstream provider, and the inventory model. Inventory is the foundation everything else attaches to, and it is the cheapest piece to get right first.

Build versus buy, and when buying wins

Buy, or rather stay with your upstream provider's portal, if you port fewer than about twenty numbers a month, use one provider, and your provisioning team is two people who talk to each other. At that volume a build is overhead. Use the portal, keep a clean spreadsheet, and spend the money on sales.

Porting justifies a build when two of these hold at the same time. You port more than roughly a hundred numbers a month. You use more than one upstream provider or port directly with multiple carriers. You sell to business customers where a failed port takes their main line down and your contract has service credits attached. You cannot currently produce a list of at-risk ports without someone reading a mailbox. Or you have no reliable count of numbers you are paying for that nobody is using.

The tipping point is not volume alone, it is the cost of a single bad port. If one dead phone system costs you a customer worth five figures a year, the system pays for itself the first time it catches a rejection at hour one instead of day three.

How to choose a developer for porting and number management

Ask them to draw the port state machine, including rejection and resubmission, before you sign anything. Someone who has done this will ask which counterparties you deal with directly versus through an aggregator, and they will know that a rejection is not an end state. Someone who has not will draw a status field with three values.

Ask how they will handle number aging and reservation expiry. If they treat inventory as a list of numbers with an assigned flag, they have not seen the double allocation problem yet and you will pay for that lesson.

Ask what they have integrated with by name: which softswitch, which upstream provider API, which ticketing system. Porting software that does not reach into provisioning is a tracking spreadsheet with a login screen.

Settle ownership of the repository, the counterparty mappings and the infrastructure accounts in the contract, before kickoff. At Digital Heroes the porting logic and the repository belong to the client from the first commit. Send us a month of your rejection emails and your current DID spreadsheet, and we will tell you where the port failures are actually coming from before we quote anything.