There is a moment that tells you everything about a numbers provider. You need forty numbers in three area codes by tomorrow, you send the request, and you get back an email that says "our provisioning team will review this and get back to you." That is the moment you realize you bought a vendor, not a system.
For anyone buying DIDs in volume, whether you are a reseller layering your own brand on top or a call center standing up local presence, provisioning speed is not a nice-to-have. It is the difference between reacting to what your operation needs today and waiting on someone's inbox. Here is what good provisioning looks like and how to spot the slow kind before you commit.
The email-thread trap
The default in a lot of the wholesale world is still the manual order. You email what you want, a person on the other side pulls numbers, replies with a list, you approve, they activate, you route. Every step is a round trip, and every round trip is measured in hours or days.
This is fine when you buy numbers once a quarter. It falls apart the moment your operation is dynamic: you are sizing up for a campaign, a block got flagged and you need replacements now, or a client wants to go live this afternoon. The provider's response time becomes your ceiling. You cannot move faster than their inbox.
The fix is not "a faster email team." It is removing the email from the path entirely for anything that does not genuinely need a human.
What self-service provisioning should do
Buying numbers that already exist in a provider's inventory is a solved problem. It should work like this, start to finish, without talking to anyone:
- Search the inventory by area code and rate center for the quantity you need.
- Buy the block in one action.
- Route the numbers to your trunk or endpoint at the same time, so they are live, not just reserved.
That last point is where a lot of setups quietly fail. Buying and activating get split into two requests with a gap between them, so you own numbers that cannot take a call yet. On a good system, you assign the route at purchase and the numbers are working immediately. This is the same self-service, buy-and-route-in-bulk flow that makes local presence dialing practical, because local presence only works if you can grab the right area codes the moment you need them.
The API is for scale, the portal is for learning
You do not need to start with code. The right sequence is:
- Use the portal by hand first. Search, buy, route a small block. Learn how the inventory behaves, how fast it activates, what the routing options are.
- Move to the API once volume or your own product justifies automating it. At that point you want the same operations, search, buy, assign a route, release, exposed programmatically so you can build provisioning into your own system.
A provider that offers only one or the other is telling you something. Portal-only caps your ability to automate. API-only with no usable portal makes evaluation harder than it needs to be. You want both, backed by the same inventory.
Separate the instant from the sourced
Not every purchase can be instant, and a good provider is honest about which is which. In-stock numbers should provision in minutes. Numbers that have to be sourced from elsewhere, or an existing block you are porting in from a losing carrier, come with a real timeline, because those involve other parties.
The problem is not that sourced numbers take longer. The problem is a provider that treats every order the same, so your in-stock purchase waits behind the same manual queue as a complex port. Ask the question directly: what provisions instantly, and what comes with a quoted timeline? A vendor who cannot answer cleanly is a vendor whose inbox is your bottleneck.
The questions that expose a slow provider
When you evaluate, get specific. Vague answers hide slow workflows. The full provider checklist goes deeper, but the provisioning-specific questions are:
- Can I search inventory by area code and buy in bulk without a sales call?
- Are numbers routable at purchase, or is activation a separate step?
- Is there an API that does everything the portal does?
- For a block that got flagged mid-operation, how fast can I get clean replacements?
The answers tell you whether you are buying a system that keeps pace with your operation, or a queue you will be waiting in.
Provisioning speed is easy to overlook when you are comparing providers on the headline rate. It is also the thing you will feel every single day once you are live. The rate matters once; how fast you can get and route numbers matters every time your operation moves.