Short answer: you need enough numbers to cover peak concurrent sessions, not total orders. A masked number represents one active pair at a time and returns to the pool when that session ends, so a platform running 10,000 orders a month with two-hour sessions needs tens of numbers, not thousands. Get the estimate wrong in the tight direction and session creation starts failing at exactly your busiest hour.
The Arithmetic
The input everyone reaches for first — monthly order volume — is the wrong one. The right one is:
Peak concurrent sessions = orders during your busiest window × average session lifetime ÷ length of that window
Work it through. A delivery platform does 800 orders on a Friday evening between 7pm and 10pm. Each session lives about 45 minutes.
- Busy window: 3 hours
- Orders in it: 800
- Average session: 0.75 hours
- Concurrent ≈ 800 × 0.75 ÷ 3 ≈ 200 sessions live at once
So roughly 200 numbers, plus headroom — not 800, and certainly not the monthly order count.
Two things move this number more than anything else:
Session lifetime dominates. Halving how long sessions stay open halves the pool. If you end sessions on delivery rather than letting them expire on a timer, you cut the requirement directly. This is the single biggest lever and it costs nothing.
Peak, not average, sets the floor. Sizing to your daily average guarantees failure at peak. Size to the worst hour you actually expect, then add headroom.
Rotation and Cooldown
When a session ends the number goes back to the pool and can be reused. That reuse is what makes a small pool serve a large platform — but it introduces one problem worth designing for.
If a number is reassigned immediately, a late call from the previous pair can land on the new pair. The buyer from the last order rings back twenty minutes later and reaches a stranger.
The mitigation is a cooldown: keep a number out of circulation briefly after a session ends. Cooldown costs pool size — numbers sitting idle are numbers you are paying for — so it is a deliberate trade between pool cost and cross-talk risk, not a setting to max out.
See number pooling for how pools are managed, and scaling number masking for the operational view.
What Running Dry Looks Like
Under-provisioning does not degrade gracefully. It fails abruptly, at peak, and it does not look like a telephony problem:
- Session creation starts returning errors during your busiest hour.
- Orders get created with no contact path attached.
- Support sees "the agent never called" complaints that are really allocation failures.
- Your monitoring shows a healthy voice platform, because no call was ever attempted.
Two defences. Alert on pool utilisation, not on call failures — utilisation crossing ~80% is the signal, and by the time calls fail you are already past it. And decide the degradation path before you need it: an order that cannot get a masked number should either queue, fall back to a monitored support line, or fail loudly. Silently creating an uncontactable order is the worst of the three, and it is the default if nobody chooses.
Number Health
Not every number in a pool behaves identically forever. Numbers can develop problems — carrier issues, reputation, downstream filtering. A pool that tracks per-number health lets you take a bad number out of rotation rather than discovering it through a pattern of complaints that took a month to notice.
Track connect rate per number. A number that connects noticeably worse than its peers is telling you something before your customers do.
Practical Starting Point
If you are launching and have no real data:
- Estimate concurrent sessions from your busiest expected hour, using the formula above.
- Add roughly 30% headroom for estimation error and cooldown.
- Instrument pool utilisation from day one.
- Re-size after two weeks of real traffic rather than guessing twice.
Starting small and growing is fine — the failure mode is not noticing you need to grow.
What Pooling Does Not Do
- It does not stop two parties exchanging real numbers on the call.
- Cooldown reduces cross-talk risk; it does not eliminate a determined callback.
- Pool size does not affect call quality — a busy pool does not produce worse audio, it produces failed allocations.