Test voice interruption at the moment it changes the task, not only when it stops the bot's audio. A good acceptance case checks that the agent hears the correction, updates the right detail, and does not continue an action based on superseded input.
Level AI describes interruption handling in its virtual-agent product. Google Cloud documents barge-in settings for interrupting response audio. Neither description establishes a measured correction-success rate in your telephony environment.
What is the difference between barge-in and task correction?
Barge-in means the caller can interrupt playback. Task correction means the conversation incorporates the new instruction. Test both separately. Stopping a sentence while retaining the wrong order identifier is an audio success and a task failure. Conversely, a correct final answer can still hide an uncomfortable interval of both speakers talking.
Define the point after which an action has already been committed. A caller saying “stop” before commitment and saying it afterward may require different responses. The bot should explain the real state instead of suggesting that interrupted speech automatically cancels a completed action.
Which interruption cases belong in the matrix?
| Caller event | Expected state check |
|---|---|
| Corrects an identifier mid-confirmation | Old value is replaced and new value confirmed |
| Says a brief acknowledgment | Task continues without an unintended new intent |
| Pauses inside a long identifier | Partial input is not treated as complete |
| Changes task during an explanation | Prior task is paused or closed explicitly |
| Requests cancellation during execution | Reported status matches the actual action state |
These are proposed behaviors to validate. Choose the supported action and expected policy with the operation's owner. Do not use a generated phrase as the sole evidence that cancellation or a data update occurred.
How should the tests be recorded?
- Keep the same task and change only the interruption point.
- Mark when the caller starts speaking and when playback stops.
- Record the recognized correction and the parameter value used afterward.
- Compare the final business state with the expected state.
- Repeat with different devices, speaking rates, and realistic background noise.
Retain failures that look awkward rather than deleting them as “bad audio.” Label genuinely unusable input separately and state why. Report distribution and examples; a single average can conceal a recurring delay on one phone route or language.
When should a configuration change be accepted?
After changing endpointing, interruption handling, or response length, rerun both the affected cases and ordinary conversations. A setting that improves corrections might also trigger on background speech or cut off an identifier. Maintain a small unchanged reference set so apparent progress can be compared against stable inputs.
Use the broader voice-agent evaluation for overall task selection and the human-handoff contract when a correction cannot be resolved automatically.
Where should an interruption occur in an acceptance script?
Place interruptions at specific state boundaries. In this illustrative delivery-date script, the caller changes “Friday” to “Monday.” Repeat the correction while the agent is speaking, after confirmation but before submission, and after the business system has committed the original date.
| Interruption point | Expected state evidence | Failure to record |
|---|---|---|
| During response audio | Audio stops and the corrected date is captured | Agent talks over the correction or retains Friday |
| Before action submission | Only the intended, reconfirmed value reaches the action | Old value submitted despite a recognized correction |
| After committed action | Agent explains the actual result and uses an allowed amendment route | Agent pretends the first action never happened |
Collect audio timestamps, recognized values, action submissions and final stored state. Stopping speech is one behavior; canceling an action is another. Define when cancellation remains possible in the connected system and make that boundary explicit to reviewers.
Add a false interruption, such as background conversation, and a caller asking only for clarification. The correct response may be to continue or clarify rather than replace a parameter. These proposed cases reveal over-sensitive interruption handling as well as missed interruptions; no timing threshold or success rate is established here.
Limits
This matrix specifies acceptance tests; it does not report latency results or certify any vendor's turn-taking quality. Feature settings, integration behavior, speech models, and supported languages can differ. Confirm the audio path and committed-action semantics in the exact deployment being evaluated.