Test the calls your voice agent
will actually get.
A pre-loaded, editable set of voice-agent failure scenarios — interruptions, background noise, silence timeouts, accents, PII exposure, escalation, and dropped calls. Run them, mark pass/fail, and export a test plan.
No account is required, and nothing is sent to Dwayo unless you choose to save, export, or request a review.
| Test case | Category | Severity | Expected behavior | Result | Notes |
|---|
Voice agents fail in ways
chat interfaces never do.
A chatbot waits for the next message. A voice agent has to decide, in real time, whether a pause means the caller is thinking, finished, or gone. It has to handle someone talking over it, a dog barking in the background, a bad cell connection, a caller pressing random digits, or a long silence after voicemail picks up — none of which have an equivalent in a text-based evaluation suite.
Most voice agent demos are tested on a quiet microphone with a cooperative caller reading a script. Production calls are not that. This test pack focuses specifically on the gap between the two.
Five categories of
voice-specific failure.
Background noise, accents and dialects, overlapping speech, and low audio quality all degrade speech recognition before the model ever sees a transcript.
Interruptions (barge-in), long pauses, silence timeouts, and callers who change topic mid-sentence require handling that text chat doesn't need.
Spoken PII, recorded-call disclosures, and confirming actions the agent didn't actually take are higher-stakes in voice, where there's no transcript for the caller to check.
What happens when the agent is repeatedly misunderstood, the caller asks for a human, or the call drops mid-transaction.
Dead air, response delay during tool calls, and behavior on hold music, voicemail, or IVR handoff all affect whether a call feels broken.
Why "it works on my test call"
isn't the same as production-ready.
Barge-in during a long response
- Setup: Agent is mid-sentence reading a long policy explanation; caller interrupts to ask a different question.
- Common failure: Agent finishes its original sentence before responding, or restarts from the beginning, ignoring the interruption.
- Expected behavior: Agent stops speaking within roughly 300ms of detected speech and responds to the new question.
Confirms an action it didn't take
- Setup: A downstream tool call to reschedule an appointment times out or errors.
- Common failure: The agent says "you're all set, your appointment is rescheduled" because the model generated a plausible confirmation without checking the tool result.
- Expected behavior: The agent only confirms success after a verified tool response, and tells the caller clearly if something failed.
Running the
test pack.
- Load the full test pack and remove or add cases to match your actual call flows.
- Run each test case against a real call — not a chat simulator pretending to be a call.
- Mark the result and note exactly what happened, not just pass or fail.
- Treat every Critical-severity failure as a launch blocker.
- Re-run the full pack after any change to the ASR provider, prompt, or voice model.
- Keep the pack versioned alongside the agent and add new cases after every real-call incident.
What this test pack
doesn't cover.
- Load testing and concurrent-call capacity
- Telephony carrier-specific routing and compliance (e.g. STIR/SHAKEN, local regulations)
- Full linguistic and accent coverage across every target market
- Business-logic correctness beyond the conversational behavior
- Ongoing production monitoring and real-call sampling
- A statistically representative real-call pilot before full launch
When to run
this test pack.
- Before any customer-facing voice agent launch.
- When evaluating a voice AI vendor or platform.
- After changing the ASR provider, voice model, or core prompt.
- Following a real-call incident or escalation.
- Before expanding a voice agent to a new language or market.
- As part of a recurring QA cycle alongside production monitoring.
Before you launch
a voice agent.
Why do voice agents need a separate test pack from chatbots?
Voice agents fail in ways chat interfaces don't: interruptions, background noise, silence, telephony drops, accents, and the absence of a visual fallback when the agent is confused. A chat-oriented test suite misses most of these failure modes entirely — see our Voice AI page.
How many test cases should a voice agent pass before launch?
There's no universal number — it depends on call volume and consequence of failure. As a baseline, every Critical-severity case in this pack should pass before any customer-facing launch, and High-severity failures should have a documented mitigation or fallback.
Does this replace load testing or real-call pilots?
No. This is a functional and safety test pack for specific failure scenarios. Load testing, a limited real-call pilot, and ongoing production monitoring are still necessary to catch issues this pack doesn't simulate.
Can I add test cases specific to my voice agent?
Yes. Add rows for your own integration points — IVR handoff, specific DTMF menus, account-lookup flows, or domain-specific compliance scripts — alongside the general scenarios included.
What counts as a Critical-severity failure?
Typically: anything involving exposed sensitive data, an incorrect confirmation of an action that didn't happen, a caller unable to reach a human when needed, or a failure that leaves the caller stuck with no path forward.
Does Dwayo see the test results I enter?
The test pack runs in your browser. Your results are only shared with Dwayo if you choose to save, export through the lead-capture flow, or request a review. See our privacy policy.
A passing test pack is a baseline,
not a launch guarantee.
Run a real-call pilot before full rollout. If Critical or High-severity cases keep failing, a Dwayo engineer can help diagnose whether the gap is ASR, prompt design, or the underlying voice architecture.