A useful voice self-service call ends with the caller's task completed or a workable route to assistance. Recognition accuracy is one ingredient. The prompts, waiting time, confirmation, alternatives and recovery steps determine whether the service is usable.
This guide is for teams specifying, buying or testing telephone services. It uses an invented bank-location lookup to make the decisions concrete. Adapt the method to your service and test it with the people who need to use it.
Define the caller's result
Write a task from the caller's point of view: “Find a branch with the service I need, confirm its address and know where to check its opening hours.” Identify the information required for that task and the authoritative system that supplies it.
Keep a public location lookup separate from account access unless an account is genuinely needed. A caller asking for an address should encounter a clear explanation if the system requests personal information. For a financial transaction, identity checks and transaction authorization require their own design and review.
Ask what happens when the caller uses a relay service, cannot produce the expected speech, needs more time or cannot remember a list of options. W3C's supplemental pattern on avoiding voice-menu navigation recommends ways to reach help and cautions that natural-language interfaces can also create barriers.
Make the call flow explicit
Those prompts are a design example, not commands that work on any particular bank's phone system. Implement only options that actually function. If a text message or web page is offered, check that the caller can use that route and that the result matches the spoken information.
For the physical terminal rather than the telephone lookup, see accessible ATM preparation and controls.
Give errors a route forward
Design the response to an uncertain or missing answer before the happy path is complete. A caller should be able to repeat information, correct one detail, ask what is supported or reach an alternative route without restarting the entire task.
| Situation | Design question | Test observation |
|---|---|---|
| Similar place names | Can the caller resolve the ambiguity with a short choice? | The intended location is confirmed before results. |
| More time needed | Can the interaction wait or offer a usable continuation? | The caller finishes without losing the entered details. |
| Speech input fails | Which keypad, text or human route is available? | The same task can continue through that route. |
| No matching service | Can the system explain the result and a next step? | The caller understands that no match was found. |
| Transfer to staff | What context can staff receive with appropriate privacy? | The caller knows where the call went and what to do. |
The W3C voice-systems research module discusses timing, cognitive load and fallback interactions. It is an early Group Note Draft and should be treated as work in progress. Together with the supplemental design pattern, it informs questions to investigate; it does not certify a system's legal or technical conformance.
Test with callers and representative tasks
W3C's guidance on involving users recommends participation throughout web projects and combining it with standards-based evaluation. The same planning discipline is useful for this service review: identify whose experiences are needed and document the limits of the sample.
- Prepare fictional locations or an isolated test dataset with known answers. Avoid using real customer credentials.
- Agree on consent, accessible instructions, recording arrangements, breaks and compensation where applicable.
- Ask participants to complete a task in their usual way. Record where assistance or a prompt was needed.
- Include an ambiguous request, a correction, a delay and a request for human help, as well as a straightforward lookup.
- Check relay and alternative-input paths with people who use them. Measure the complete interaction, including waiting and transfer.
Record success against the known answer, first-attempt completion, completion after recovery and any point where the person was unable to proceed. Ask whether the result was understandable and useful. A short call can reflect either efficient service or abandonment, so duration needs an outcome beside it.
Prioritize the barrier and verify the repair
Write an issue as a reproducible observation: task, input method, exact step, expected behavior, observed behavior and impact. “After the second failed town match, the call ended before offering help” is more actionable than “speech recognition was poor.”
Assign an owner and retest the affected flow after changing prompts, recognition, data or transfer logic. Check that the repair also works through the alternative route. For component and deployment questions behind the experience, see network speech systems.
Explore the library
Assistive Technology: Practical Guides for Everyday Access
Sources appear beside the claims they support. Reviewed October 4, 2026. Check current product instructions for your version, location and intended use.