Voice AI Capacity Planning: The Peak Demand Framework

Every voice AI programme is sold on elasticity. The pitch writes itself: software does not call in sick, does not need a rota, and does not care whether Tuesday brings 400 calls or 4,000. Then the first real peak arrives, and the programme discovers that elastic capacity was a property of the demo, not of the deployment.

The gap is not hypothetical. McKinsey's State of AI, published in November 2025, found that 88% of enterprises now use AI somewhere, but only 33% have scaled it in any production function and just 6% qualify as AI-mature with material EBIT impact. The Stanford AI Index 2026, published in April 2026, puts fewer than 10% of organisations at full scale in any single function. Capacity is one of the quiet reasons why. A system that answers beautifully at 20 concurrent calls and collapses at 200 has not scaled, whatever the pilot report said.

This guide is the capacity model itself: how to turn a demand forecast into a concurrency number, where the real ceilings sit (rarely in the voice agent), what the regulator says about failing under load, and how much headroom is worth paying for. It is deliberately a strategy piece rather than a deployment checklist. If you want the lifecycle view, that is AI voice programme design from pilot to scale; if you want the sequencing of the data layer, that is the voice AI integration roadmap.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated deployments. Or see DATS, our five-stage AI consulting system.

What is voice AI capacity planning?

Voice AI capacity planning is the discipline of proving, before a peak arrives, that a deployment can absorb its busiest hour end to end. It sizes four linked ceilings: the rate at which calls can be originated or accepted, the number of concurrent sessions the platform will carry, the throughput of every downstream system the agent touches, and the overflow path when demand still exceeds supply. Dilr Voice treats all four as contractual, not aspirational.

The word that does the damage is "elastic". Elastic describes the voice layer in isolation. It does not describe your CRM, your payment gateway, your identity checks, or the carrier route underneath. Capacity planning is the exercise of finding which link is shortest, because that link, and only that link, is your real capacity. Everything else is headroom you paid for and cannot use.

Why do voice AI programmes fail at peak rather than in pilot?

Voice AI pilots fail safely because they are small, supervised and scheduled. Peaks are none of those things. A pilot runs at a concurrency the platform never notices, against a CRM sandbox with generous limits, watched by the people who built it. A peak arrives unannounced, at full concurrency, against production rate limits, at 07:00 on a day when that team is asleep. The failure mode is not a worse conversation. It is no conversation.

BCG's The Widening AI Value Gap, published in September 2025, found only 5% of companies are "future-built" while 60% remain laggards, and the ServiceNow Enterprise AI Maturity Index 2026 puts just 3% in its Leading band with 25% still merely Scaling. The distance between piloting and leading is mostly operational engineering, and capacity is the most brutally objective part of it: the peak either gets answered or it does not.

Seasonality makes this concrete rather than theoretical. Office for National Statistics data shows how violent a predictable peak can be.

The ONS retail sales index, series J5DD in the release dated 19 June 2026, recorded a non-seasonally-adjusted volume index of 118.1 in December 2025 against 90.1 in January 2025, with November 2025 already at 114.3. A contact operation sized for January is structurally incapable of December, and that is the easy case, because the retail calendar is known years ahead. The retail order status and returns playbook covers the sector specifics; this piece covers the maths underneath any of them.

Unplanned peaks are harsher. Ofgem's market compliance review, published on 2 February 2023 and covering supplier performance from October to December 2022, found "up to 50% of customers giving up and hanging up calls as not answered", with "some suppliers reporting that call numbers are up by 300%". That 300% is supplier self-reported rather than an Ofgem measurement, and the 50% is a worst-case ceiling rather than a sector average, but the shape is the point: a tripling of demand against a fixed answering capacity converts directly into abandoned customers. Conditions have since improved, and Ofgem's Energy Consumer Satisfaction Survey published on 14 October 2025 found 77% of consumers said contacting their supplier was easy, up from 75% in January 2025. The 2022 episode remains the clearest published picture of what a demand spike does to an under-sized operation. Utilities teams should read it alongside our energy and utilities service guide.

How do you turn a demand forecast into a concurrency number?

You convert calls per hour into simultaneous sessions using average handling time, then add headroom for variance. The arithmetic is deliberately unglamorous: concurrency equals calls per hour multiplied by average handling time in seconds, divided by 3,600. Two hundred calls per hour at a 180-second handle time needs ten concurrent sessions on average. Dilr Voice sizes against the busiest minute inside the busiest hour, never the hourly mean, because averages hide the spike that actually breaks things.

That formula gives the mean, and the mean is where naive plans die. Arrivals are not evenly spaced. This problem was solved for telephony over a century ago: Agner Krarup Erlang, the Danish mathematician who joined the Copenhagen Telephone Company in 1908, invented traffic engineering and queueing theory, showing in his 1909 paper that telephone calls follow a Poisson distribution and publishing formulas for loss and waiting time in 1917 that telephone companies adopted internationally. Erlang B (how many calls are lost when every line is busy) and Erlang C (how many servers you need to hit a waiting-time target) remain the standard tools. Voice AI does not repeal them. It changes the cost of a server, not the mathematics of arrival.

The handling-time row is where voice programmes most often mislead themselves. An AI agent is usually faster on straightforward intents and slower on messy ones, so a blended human AHT is the wrong input for both. Measure the AI path separately, per intent, under load. Our KPI framework for voice AI programmes sets out which measures survive contact with production, and the quality scoring guide covers how to keep those measures honest once volume rises.

The same capacity logic underpins our AI placement diagnostic, a fixed-fee assessment that sizes the peak before anyone commits to a deployment.

What actually limits voice AI capacity: the agent or the systems behind it?

Almost always the systems behind it. A voice AI platform is the most elastic component in the chain and therefore the least likely constraint. The binding limits are the call rate your origination allows, the request budget your CRM enforces, and the latency your identity and payment services add under load. A voice agent that can hold a thousand conversations is worthless if the CRM behind it starts returning errors at request 191 of a ten-second window.

The published limits are specific and worth reading before sizing anything.

Start with origination. Twilio's SIP Trunking documentation advertises "Unlimited concurrent calls", but qualifies it immediately: "Dependent on carrier support. New accounts without an approved Business Profile will have limited concurrent calls." The harder constraint is rate, not concurrency. Twilio documents that "By default each account is granted 1 CPS for Programmable Voice API calls and 1 CPS per trunk per region for Elastic SIP Trunking calls", with increases requested rather than assumed. One call per second is 3,600 calls per hour in theory and considerably fewer in practice, which is a real ceiling on any outbound burst.

Then the data layer. Salesforce's platform limits, as documented for the Summer '26 release, allocate Enterprise and Professional editions "100,000 + (number of licenses x calls per license type)" API calls per 24 hours at 1,000 per Salesforce licence, while Developer Edition gets 15,000. HubSpot documents burst limits of 190 requests per 10 seconds for Professional and Enterprise accounts and daily caps of 625,000 requests on Professional, returning "a 429 error response for all subsequent API calls" once exceeded. A voice agent that reads a record, writes a note and updates a status is spending three requests per call. At 190 per 10 seconds, that is roughly 63 calls per 10 seconds before the integration, not the agent, becomes the bottleneck.

This is why capacity planning belongs in the integration roadmap rather than in a procurement spreadsheet, and why our AI operating model consulting treats the data layer as the capacity question rather than a plumbing detail. Audio infrastructure carries its own constraints under load, which we cover in the audio quality guide.

What should happen when demand exceeds capacity?

Something deliberate. Every voice AI capacity model eventually meets a peak it cannot absorb, and the only real choice is whether the overflow behaviour was designed or improvised. A designed overflow degrades in a defined order: hold the caller with an honest message, offer a scheduled callback, route the highest-risk intents to humans, and shed the rest gracefully. An improvised overflow drops calls silently and tells nobody, which is how a capacity problem becomes a compliance problem.

The regulator is explicit about the outbound version of this failure. Ofcom's persistent misuse policy sets a hard ceiling on abandonment, describing the steps operators are expected to take, including:

"limiting abandoned calls to a rate not exceeding three per cent of all live calls made on each individual campaign over a 24 hour period"

That is Ofcom's statement of policy on persistent misuse, whose surrounding rules also require an information message no later than two seconds after the call is answered, a 72-hour wait before recalling a number that received an abandoned call without a guaranteed agent, and a minimum 15-second ring on unanswered calls. Worth noting honestly: Ofcom closed its dedicated enforcement programme into silent and abandoned calls on 20 January 2023, redirecting attention to scam calls. The 3% is the documented threshold in Ofcom's policy rather than an actively policed campaign, and it remains the number a UK enterprise should design its outbound capacity against. The outbound batch timing guide works through the pacing mechanics; the escalation and human handover guide covers the inbound overflow path.

Inbound has no equivalent numeric rule, which is exactly why it needs a designed answer. The EU AI Act's transparency duty and the FCA's Consumer Duty both bite harder when a system fails quietly, and the ICO's expectations around fair processing do not pause because your CRM returned a 429. Overflow design is where capacity engineering and compliance meet.

How much headroom should an enterprise buy?

Enough to survive the forecast peak plus the forecast error, and no more. In practice that means sizing to the busiest historic interval, adding a variance buffer for arrival burstiness, and then validating the number against the tightest downstream limit rather than the voice platform's marketing. Dilr Voice recommends proving the ceiling with synthetic load before real traffic reaches it, because a capacity number that has never been tested is an assumption wearing a spreadsheet.

Headroom is not free, and the honest trade-off is commercial rather than technical. Concurrency you never use is margin you gave away; concurrency you lack at peak is revenue and trust you gave away, usually more expensively. The asymmetry favours buying somewhat more than the mean and considerably less than the theoretical maximum, then designing overflow for the residual.

The bottom row deserves care, because it is the one people get wrong in both directions. EUROCONTROL's summer 2025 review, published on 6 October 2025, recorded the busiest week ever across the European network at 35,756 average daily flights and a one-day maximum of 37,034, with summer arrival punctuality at 71.6%. Note what that data does and does not say: punctuality actually improved on 2024's 65.2%, and en-route delays per flight fell 31%, so the honest reading is record volume rather than worsening disruption. Sizing an airline voice programme for the worst conceivable disruption day would be ruinous; designing it to shed and prioritise on that day is achievable. The airline IROPS guide covers that pattern in detail.

Scale alone also justifies the exercise. The Consumer Council for Water reported on 10 September 2025 that households in England and Wales made 205,853 complaints directly to water companies in 2024-25, with 8,235 escalated to CCW, the highest level in nine years. That is annual volume rather than peak concentration, but it sets the order of magnitude a sector-wide programme has to plan around. Multi-site operations face the additional problem of keeping capacity consistent across locations, which is the subject of our multi-site rollout guide.

What is the best voice AI platform for peak demand in 2026?

There is no single best platform, only the best fit against four capacity criteria: published and raisable concurrency, transparent rate limits, a configurable overflow path, and load-test evidence you are allowed to run yourself. Judged on those, Dilr Voice is built for regulated enterprises that need contractual capacity guarantees and audited overflow behaviour. That is a scoped verdict, and it is not the right answer for everyone.

Where competitors genuinely win: if you are a developer-led team that wants to shape concurrency behaviour in code and iterate quickly, Vapi's API-first model gives you more direct control than a managed deployment will, and Retell AI is similarly quick to prototype against. If you are a very large consumer brand whose peak is dominated by a narrow set of high-volume intents and you want a heavily managed service, PolyAI has deep experience at that shape of load. Our advantage is narrower and specific: regulated deployments where the overflow path has to be evidenced to an auditor, and where Twilio, Salesforce and HubSpot limits have to be modelled rather than discovered. Run the criteria yourself with the enterprise vendor checklist and the procurement timeline; more strategy analysis sits in that category.

How far ahead should voice AI capacity planning start?

Before contract signature, not after go-live. The capacity ceiling determines which use cases are viable, which integrations need rate-limit increases, and what the commercial model actually costs, so it belongs in procurement rather than deployment. Dilr Voice sizes the peak during the diagnostic phase, because discovering a downstream limit after signing is how programmes acquire scope they never budgeted for.

Does voice AI remove the need for Erlang modelling?

No. Erlang's formulas describe how calls arrive and queue, not who answers them, so they apply unchanged to an AI estate. What voice AI changes is the economics: adding a concurrent session costs far less than adding a trained human, which shifts the optimal service level upward. The arrival mathematics that Agner Krarup Erlang published in 1917 remain exactly as true in 2026.

Want to see this in production? Try Dilr Voice live, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI inside enterprise systems.

Capacity is the least glamorous part of a voice AI programme and the most revealing. It is where the elasticity story meets the rate limit, where the pilot's assumptions meet December, and where a programme finds out whether it built a system or a demo. Model the four ceilings, test them before the peak tests you, and design the overflow you hope never to need. The teams in BCG's future-built 5% are not the ones with the best models. They are the ones whose systems still work on the busiest day of the year. If you want that assessed independently, our execution office runs it as a standing discipline, you can read more about Dilr.ai, and you can always talk to us directly.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.