Voice AI: Call Concurrency Guidance

This article explains how concurrency limits work with Talkative's Voice AI, and how concurrent call capacity relates to your monthly minute allowance.

Concurrent call capacity is provisioned to match the number of minutes purchased for the month, based on how that usage is expected to be spread over time, rather than sizing for worst-case daily usage.

The underlying assumption is that purchased minutes are consumed reasonably evenly across the month, not all at once. For example, a customer with a 10,000-minute monthly allowance would not be expected to use all of it in a single day — usage is assumed to spread across an average month.

Within each day, usage is further assumed to concentrate around a typical working day of roughly 8 hours. Concurrency is calculated from this daily/hourly spread of the monthly minute allowance, with headroom added on top of that calculated baseline.

The general formula for working out baseline concurrency from a monthly minute allowance is:

Concurrency = Monthly Minutes ÷ Operating Days in Month ÷ Working Hours per Day ÷ 60

Using the standard assumption of an 8-hour working day, this simplifies to dividing the monthly minutes by a fixed number, which depends on how many days a week you operate:

Assume a customer purchases 100,000 minutes for the month, and usage is assumed to be perfectly flat across the month with no spikes.

If you operate 7 days a week (28-day month)

Spread over an average month of 28 days, that is 100,000 ÷ 28 ≈ 3,571 minutes of call time per day.

Spread over a typical 8-hour working day, that is 3,571 ÷ 8 ≈ 446 minutes of call time per hour.

Since there are 60 minutes in an hour, that works out to roughly 446 ÷ 60 ≈ 7.44 concurrent calls at any given moment — under this flat, no-spike assumption, the baseline concurrency requirement rounds up to around 8 concurrent calls, before any headroom is added.

If you operate 5 days a week (20 operating days)

Spread over 20 operating days, that is 100,000 ÷ 20 = 5,000 minutes of call time per day.

Spread over a typical 8-hour working day, that is 5,000 ÷ 8 = 625 minutes of call time per hour.

Since there are 60 minutes in an hour, that works out to roughly 625 ÷ 60 ≈ 10.42 concurrent calls at any given moment — so the baseline concurrency requirement rounds up to around 11 concurrent calls, before any headroom is added.

This same formula can be used in reverse to work out how many monthly minutes are needed to support a desired level of concurrency:

Monthly Minutes = Target Concurrency × Working Hours per Day × Operating Days in Month × 60

Using the same standard assumptions, this means multiplying the target concurrency by 13,440 if you operate 7 days a week, or by 9,600 if you operate 5 days a week.

For example, a customer who averages 10 concurrent calls across all working hours of the month would use around 10 × 13,440 = 134,400 minutes if operating 7 days a week, or 10 × 9,600 = 96,000 minutes if operating 5 days a week. Peak concurrency will be higher than this average.

Concurrency is set on a per-customer basis, based on an understanding of that customer's usage — the number of minutes purchased, and whether any additional overage has been purchased on top of that allowance. This ensures each customer has sufficient concurrent call capacity for their expected usage pattern, with headroom built in above the calculated baseline.

By default, concurrency is not guaranteed to an unlimited or fixed level. If guaranteed concurrency is required — for example, to support a specific peak-usage requirement — this is available, but needs to be arranged through a commercial discussion, as it involves provisioning dedicated infrastructure to support that guarantee.

If all available concurrency for a customer is in use at the moment a new call comes in, the call is not instantly rejected or failed. Instead, the call will continue ringing, similar to a brief hold, until capacity becomes available and it is connected to the bot or, if a timeout is configured, until that timeout is reached.

This extra ringing time gives existing calls a chance to complete — either because the bot has finished handling them, or because they've been transferred into the contact centre after being triaged — which frees up concurrency for the waiting call to connect. This approach helps smooth out short bursts of demand rather than causing an abrupt failure when limits are momentarily reached.

How this behaves depends on your telephony setup, so we recommend speaking to your technical resource to make sure it works for you. We plan to improve this in future, including making this behaviour configurable.

A number of further enhancements to concurrency handling are planned for the future. These include:

In some cases, concurrency pressure can be reduced through bespoke call-handling design, rather than relying solely on bot concurrency itself. Our professional services team can help design clever IVR and call-flow solutions for scenarios where a full conversational bot isn't actually required to resolve the caller's need.

For example, a contact centre handling outage reports for an energy supplier could look up the caller's number against known outages before the bot is engaged. If an outage is already identified for that number, the caller could simply be played an automated message confirming the known outage, along with a link to a website or a text message with real-time updates — without ever needing to activate the bot.

Because these kinds of call flows can be built using other provider solutions that don't rely on transcription services, they can support much higher concurrency than bot-handled calls. This makes them particularly well suited to deflecting predictable or spiky traffic that doesn't fit a customer's usual usage pattern — such as simple queries like checking for a known outage — helping to avoid unnecessary use of bot minutes for needs that don't genuinely require conversational handling.

In addition to a standard monthly minute allowance, overage bundles can be purchased to provide extra capacity for usage that goes beyond that allowance. Overage is generally intended to cover occasional, modest spikes — for example, where usage runs a little ahead of plan towards the end of a month — rather than to support a large, sustained surge in call volume.

By default, overage is handled on a best-effort basis within the prescribed concurrency limits already in place, rather than with dedicated guaranteed capacity. If a customer anticipates a genuine mass influx of calls — rather than occasional overage — and needs guaranteed concurrency to handle it reliably, this is a separate requirement from standard overage and should be discussed commercially so that appropriate capacity can be planned and provisioned in advance.

Concurrency on the Voice AI side is only one part of the picture. When a call is transferred out of the bot — for example, into a contact centre or PBX — the receiving system's own trunk capacity and licensing also need to support the expected call volume.

For example, if a customer has enough purchased minutes to support 100 concurrent calls on the Voice AI side, but the receiving PBX trunk — such as a Mitel trunk — only has 50 licensed channels available, calls beyond that 50 will not be able to transfer successfully and callers may experience busy tones on transfer. Licensing and trunk capacity on the receiving end should therefore be sized to match expected concurrency, not just the concurrency provisioned for the Voice AI platform itself.

Where receiving-end trunk or licensing capacity is a limiting factor, a professional services solution can also be considered to help manage the handoff more gracefully. This involves checking the receiving PBX's available capacity before transfer, and if it's currently at capacity, transferring the call to an external queue to wait rather than attempting a direct transfer straight away. Once capacity frees up on the PBX, the call can then be transferred in from that queue. This is available as a professional services option where required, rather than a standard default behaviour.

Where a bot uses tools or integrations during a call — for example, looking up a customer's account status via an API based on their phone number — the capacity of those external systems also needs to be considered alongside Voice AI and trunk concurrency.

Provisioning enough concurrency to handle a large volume of simultaneous calls has limited value if the APIs or systems the bot depends on during those calls can't support the same level of concurrent requests. If an integrated API or tool can't keep up with a sudden burst of calls, those lookups may fail or slow down even though the call itself connected successfully, which affects the experience just as much as a transfer failing on a receiving trunk.

As with trunk and licensing capacity, any upstream providers or tools the bot relies on during a call should be sized and tested to match the expected concurrency, rather than assuming they'll scale automatically alongside Voice AI capacity.

The typical, expected call flow is for a call to originate in the customer's own PBX and be transferred into our platform, where the bot handles it before referring the call back — for example, into the contact centre once the bot has finished triaging it.

This isn't the only possible setup. In some cases, the call can instead originate within our system, which then dials out into the customer's contact centre via a “SIP DIAL”.

The distinction matters for minute consumption. With the typical transfer-in flow, minutes are consumed for the portion of the call handled by the bot. With a sip dial setup, because the call originates within our system, minutes are consumed for the entire length of the call from start to finish — and this includes any time spent queuing after the call has been passed on, not just active conversation time. For example, if a sip dial call is transferred on and then sits in a queue for an hour before being answered, that full hour of queuing time is billed, in the same way as active call time.

This makes queuing time a significant cost consideration for sip dial configurations in particular, since a long queue can quickly become expensive when billed for its entire duration. This should be factored in carefully when estimating expected minute usage and concurrency for a sip dial configuration.

Alongside Voice AI concurrency, receiving-end trunk licensing, and any upstream tool or API capacity, SIP channel concurrency is another important factor to account for when pricing and sizing a solution. Depending on the call flow, a single call handled by the bot can consume more than one SIP channel at once — for example, where both a leg into the PBX and a leg out to the Voice AI platform are held open simultaneously. This means SIP channel capacity can be consumed faster than the raw number of concurrent calls might suggest.

See the Voice AI Mitel Integration Guide (START HERE) for more detail on how SIP channels are consumed across a call, which should be factored in alongside the concurrency considerations covered in this article.