← Back to Knowledge CentreCustomer Story

Two layers of customer, one governed inventory

A wholesale communications group automates inventory, ordering and trunk provisioning for its own customers and for their customers beneath them.

An anonymous production deployment. The customer is real and the platform is in production; the customer is not named.

Most numbering platforms assume one layer of customer. Wholesale does not work that way.

A wholesale provider sells to service providers, who sell to businesses, who allocate numbers to their own sites and users. Every one of those layers wants to order, to see what it holds, and to get an answer without raising a ticket. Build for one layer and the second one becomes an operations queue.

Three things at once

This group runs exactly that shape, across more than one region, and it uses the platform for three things at the same time.

Inventory, so there is one record of what exists and who holds it, rather than a reconciliation between a carrier portal, a provisioning system and a spreadsheet.

Customer ordering, so its customers and their sub-customers order for themselves. Self-service here is not a convenience feature. It is the only way a two-layer estate stays current, because the alternative is that every change at the bottom layer arrives at the top as a request someone has to type in again.

SIP trunk provisioning, so the configuration that makes a number work is created as part of the order rather than afterwards. A number that exists in a record but does not yet carry service is not a delivered number, and the gap between those two states is where wholesale fulfilment usually loses its days.

Integrated into what already ran

The platform was integrated into the session border and routing estate the group already operated. Nothing was ripped out.

That is the governing-without-replacing model working in the least forgiving environment for it: a live wholesale network with customers on the other side of it, where the cost of a migration is paid by people who did not ask for one.

Residency as a governance outcome

The deployment later moved to a dedicated regional cloud to meet a data residency requirement.

It is worth saying plainly why that is a governance outcome rather than an infrastructure one. Residency is a rule about where governed data may live. A governance layer that could not satisfy it would not be governing much, because the first question a regulator or a customer asks about a record is not what it contains but where it is held and who can reach it.

Why it is anonymous

The deployment is real and in production. The customer has not been asked to be named for it, so it is not named here, and no volumes or commercial details appear in this account.

For the discipline behind it, start with what Communication Identifier Governance actually means.

Wondering where your own estate stands? Arrange a platform walkthrough