Incoming call testing: a bounded voice AI load-test plan
Separate conversation quality from concurrency testing, choose authorized endpoints, set spend limits and verify cleanup after each call.
Table of Contents▼
A useful incoming-call test answers a specific question: can this assistant finish the intended task, can the telephone route carry a two-way conversation, or can the system handle an agreed number of simultaneous sessions? Those are different tests. Starting many calls at once does not establish any of them by itself.
Start with one reproducible conversation
Write a short scenario with fictional business and caller details. Record the assistant version, provider configuration, expected outcome and a failure condition. For a receptionist, a useful script includes an ordinary service request, a correction to the address and a question the business facts do not answer.
Run it in the browser first. Check the transcript and the actual action result separately. Then test an authorized telephone number on the carrier route you intend to use. Browser success does not prove SIP routing, caller audio or transfers.
Define the load envelope before dialing
| Decision | What to write down |
|---|---|
| Endpoints | Exact numbers or rooms your team controls and has authorized for testing |
| Volume | Maximum simultaneous calls, total attempts and test duration |
| Budget | Maximum reserved and actual provider expense, including every telephone leg |
| Stop condition | An error rate, excessive response delay, failed cleanup or spend threshold |
| External actions | Simulated actions or a dedicated test connection; never a live customer booking by accident |
| Ownership | The person watching the run and the person who can stop new admissions |
Increase one dimension at a time. For example, compare sequential calls with two concurrent calls before considering a larger run. This is a testing sequence, not a recommended capacity limit for Burki. Carrier, provider and workspace limits remain authoritative; do not raise them silently to finish a benchmark.
Measure the whole call lifecycle
For each attempt, retain an internal test identifier and the selected revision. Observe admission, caller connection, assistant readiness, first audible answer, interruptions, action outcome and hangup. Afterward, confirm resources have closed and usage is settled or explicitly pending. A success response from a start-call endpoint only means the request reached that stage.
Compare latency from the same reference points. End of caller speech, recognition completion, generated audio and audible playback are different timestamps. Report the sample size and failures alongside any percentile. Keep internal test activity out of acquisition and customer-use reports.
What Burki's tools establish
Burki supports browser practice, call review and bounded IVR exploration. IVR Explorer can help inspect reachable menu branches; it is not a promise of unlimited traffic generation or complete load-test automation. Its calls consume funded usage and can be limited by depth, time and carrier capacity.
Use the IVR testing worksheet for branch expectations. When a test fails, preserve its evidence before retrying. A rerun can add cost and external actions, so it should be an explicit new decision.
Ready to try Burki?
Create an assistant and check your available browser practice allowance.
Create your assistantTrial eligibility and available practice are shown in your workspace.