AI Phone Capacity: Test What Happens When Call Demand Spikes

The workbook below is an original operational test design. A successful test establishes behavior under those conditions; it does not prove unlimited capacity or production reliability.

Build a demand profile using observed call arrival patterns

Monthly call totals help describe workload but cannot show how many conversations overlap. An opening-time burst or closure event is a useful scenario to investigate when it appears in your own records, not a universal peak pattern.

Start with whatever call data your current phone system or carrier already exports. Choose a documented observation window that includes relevant operating patterns. Record call arrival and end timestamps when available, plus transfer requests and time spent waiting. Keep offered-call interval counts as a summary alongside those event records. Then mark the following for each day:

• The single busiest interval and its call count.
• The number of intervals above your rough staff-answerable threshold.
• Any identifiable cause for the spike (closure, recall letter, schedule release, holiday backlog).

Summarize the highest observed simultaneous-call count, arrival bursts, call-duration distribution and transfer overlap. If only interval totals are available, label concurrency unknown and design tests across plausible duration and overlap assumptions. For example, six one-minute calls can be sequential or can overlap completely; the same interval count can imply very different demand.

AHRQ's toolkit identifies administrative workflow as part of health IT assessment. That supports mapping who handles calls and exceptions; it does not supply a phone-capacity formula or load-test threshold (AHRQ toolkit).

Separate concurrent conversation capacity from staff-transfer capacity

A vendor can quote a concurrency figure for the AI itself. That figure, even if accurate, answers only half of the question. Check the receiving staff's capacity and the routing components between the caller and those staff. A limit may sit in the proposed service, your phone setup or the receiving workflow.

Treat these as two separate lines in your workbook:

Line A, AI conversation capacity. How many simultaneous conversations the system will hold before callers hear something other than the normal greeting. Ask the vendor for the number, the behavior past the number, and whether the limit is per practice, per phone number, or shared across their customers. Record the answer as a vendor claim until demonstrated.

Line B, staff-transfer capacity. How many transferred calls your team can accept at once, and what happens to the next transfer when every staff line is busy. Your practice defines staffed availability; the relevant phone and AI providers must demonstrate how transfers reach that destination and what happens when it cannot accept more calls.

In a fictional setup with three receiving lines already occupied, test the fourth simultaneous transfer. The next action depends on queueing, availability and approved fallback rules, not just the AI's concurrency claim.

Also distinguish concurrent active calls from call-start rate. Twilio, for example, documents a calls-per-second limit for outbound calls created through its Calls API. That is a rate at which calls start, not the number of active conversations. Ask each provider which limit a quoted figure describes (Twilio Call resource).

If you are also evaluating broader call automation, the method in healthcare call center automation covers routing scope. This article stays on saturation behavior only.

Define what callers experience when a limit is reached

Write a one-page limit behavior table before any test. Each row is a limit; each column is what the caller hears, what the caller can do, what your team sees, and what gets logged. A minimal version:

Fill in the question marks with the vendor's stated behavior, then replace each with what you observed during testing. A row that stays as a question mark after the test is an evidence gap, not a pass.

For each fallback, define what can be promised. A callback option needs an approved contact route, an owner and capacity to perform the work. Record an unavailable or declined callback route explicitly. Test how an interrupted transfer is surfaced even when the caller number or context is unavailable.

Run peak and recovery scenarios with synthetic conversations

Agree the test window, target numbers, maximum load, stop conditions and affected dependencies with the responsible providers and practice owners. Use synthetic conversations on an approved test setup. Do not unplug production staff lines or place an unapproved load on a shared service. The Linear Health evaluation kit's first rule applies here: run a real workflow with normal complexity, missing data, and at least one exception, because a scripted happy path is not enough (Linear Health). For capacity testing, the exception is saturation itself.

Capacity scenario workbook (illustrative synthetic example)

The numbers below are invented for illustration. They are not Linear Health customer results and not benchmarks. Replace every figure with your own observed data.

These invented arrival counts do not define concurrency until the start times and durations are specified. Choose test levels from your observed overlap and a documented planning margin. State which production features and limits the test setup does not reproduce.

Load-test acceptance questions

Bring these to the vendor and record each answer as not addressed, claimed, demonstrated, or verified, the same scale the evaluation kit uses so your decision record stays consistent across vendors (Linear Health).

1. What is the stated concurrent conversation limit for our configuration, and is it shared with other customers?
2. What does a caller hear at that limit, and can we change the message?
3. When all staff transfer lines are busy, what happens to the next transfer, and where is it recorded?
4. When a transfer fails mid-call, what does the caller hear, and what does our team see?
5. Can we run a synthetic load test on a non-production number before go-live, and who observes it?
6. After an outage or saturation, how are queued callbacks released, and how are duplicates prevented?
7. Which of the above have we watched, and which remain vendor statements?

If you would like to walk through a saturation scenario on Linear Health's voice AI using your own demand profile, you can book a demo and bring the workbook with you.

Compare vendor capacity claims with observed outcomes

Capacity figures from any vendor are advertised scope until tested in your environment. Public vendor material establishes what is claimed, not independently verified behavior. The useful comparison is not whose number is biggest; it is whose stated limit behavior matched what your synthetic callers experienced, and whose did not.

Keep a short comparison grid with one row per vendor and columns for: stated concurrency, observed behavior at Line A, observed behavior at Line B, failed-transfer handling, recovery handling, and evidence level. Resist filling empty cells with assumptions. A blank cell means the vendor did not demonstrate it to you, not that the product cannot do it.

One boundary to keep clear in the write-up: capacity results describe caller experience and staff workload. They are not a cash figure. If you later build a business case, keep capacity, staff time, and spend as separate lines, as outlined in voice AI ROI in healthcare.

A conversation with the Linear Health team can establish which configuration, provider limits and receiving-team assumptions would be tested. Ask what evidence would remain unavailable after the proposed demonstration and how that gap would be resolved before launch.

The broader scorecard and gate logic lives in the operational AI evaluation kit, and the platform context is on the patient engagement platform page.

Frequently asked questions

Sources

Sources accessed October 29, 2026.

• AHRQ, Workflow Assessment for Health IT Toolkit.
• Linear Health, Operational AI Evaluation Kit.
• Twilio, Call resource documentation.