IVR testing: a call-quality worksheet for each branch
Use repeatable caller scripts to verify menus, corrections, failed actions and telephone routing before publishing an assistant.
Table of Contents▼
An IVR test should identify the branch the caller reached and the outcome that actually occurred. Hearing a fluent answer is insufficient if a caller lands in the wrong queue, a booking is only simulated, or an unanswered transfer drops the call.
Build a branch inventory
Start with known business routes: opening hours, routine questions, appointment requests, billing and a human-help option. For each, record the approved answer or destination and the evidence that counts as success. Keep an explicit list of unobserved routes; an exploration that reaches three menus has not proved that the rest do not exist.
Burki's IVR Explorer can produce a saved map from bounded exploration. Review the observed prompts, branches and limits with the business owner. Authentication, changing hours, account-specific menus and depth limits can leave gaps.
Use this test-call template
Scenario: caller requests a repair, then changes the service address
Assistant revision: record the exact draft or published version
Channel: browser or the named telephone route
Caller facts: fictional name, permitted service area, controlled callback number
Expected behavior: ask for the issue, accept the correction, confirm the final details
External action: simulated request capture, or a specifically authorized test action
Failure: wrong address, invented appointment, premature transfer, or lost caller
Evidence: transcript, action result, routing result and settled usageKeep the expected result beside the script. Do not treat a reviewer liking the voice as evidence that the address was captured correctly.
Include the cases that expose failures
| Test | Observe |
|---|---|
| Caller corrects a detail | The final value replaces the earlier value in both speech and action arguments |
| Caller interrupts a long answer | Playback behavior and the next answer acknowledge the interruption |
| Unknown business question | The assistant states the limit and follows an approved next step |
| Connected action times out | No success claim without a verified result; no blind duplicate retry |
| Human destination declines or does not answer | The caller remains accounted for and hears the supported recovery path |
| Caller hangs up during an action | Resources close and the action state remains inspectable |
Transfer cases apply only to a runtime and route that support the selected behavior. They are acceptance requirements, not a claim that every Burki configuration has passed them.
Separate browser, telephone and volume testing
Browser practice is convenient for instructions and corrections. Telephone tests add the actual carrier, SIP, audio path and number configuration. A bounded load test adds concurrency and cleanup checks after a sequential scenario works.
Use controlled endpoints and fictional details. Real dialing and IVR exploration require funded usage; a free browser trial is not a carrier test allowance. Stored recordings also require the supported recording configuration and applicable consent.
Review before publishing
Compare the selected draft with the published version. Fix one issue, rerun the affected scenario and check that an adjacent branch still works. Record failures as failures even when the call completed. Publish only when the business owner can explain the supported outcomes, remaining limits and fallback path.
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.