Validate DTMF Menus Before Connecting a Voice Agent

DTMF menu validation checks whether a keypad input produces the intended menu behaviour over the actual telephone route. Hearing a tone or seeing a digit in a log is useful evidence, but the business result is the branch the caller reaches.

This distinction matters when a voice agent navigates a menu or receives keypad choices from a caller. Digits can arrive at the wrong time, be repeated or trigger a different option than the current prompt describes. A careful test follows the input all the way to its result.

Map the expected choices first

Write the menu prompt, each advertised key and the expected destination. Include repeat, previous-menu and operator options if they exist. Mark any choices that are unavailable during the test window or depend on the caller's account.

For a hypothetical menu, “press one for service, two for accounts, nine to repeat” creates three separate expectations. The test should verify the destination and the wording heard after the choice, not merely the digit sent.

Burki's conversational IVR overview explains the mapping use case. A discovered map is a starting point for review; it does not automatically prove every menu branch behaves correctly.

Check the telephone capability

LiveKit documents DTMF support in its telephony feature guide. The relevant platform mode, carrier route and implementation still need their own acceptance. Browser microphone testing does not by itself demonstrate telephone keypad behaviour.

Ask the technical owner which sending and receiving path is being used. Record that with the test so a later provider change can be evaluated against the same expectation. Avoid assuming that all methods of representing tones are interchangeable on every route.

Test timing without guessing a universal delay

Try a digit after the prompt completes, then at an allowed earlier point if the menu supports early input. Record what the menu does with input during its greeting. Some workflows intentionally wait; others accept a choice immediately.

Test two digits that form a sequence separately from a single menu choice. Include the required terminator if the menu requests one. The important question is whether the receiving system interprets the intended sequence, not whether the sending side queued the characters successfully.

Do not change multiple timing settings together when diagnosing a problem. Use the same prompt and input, alter one condition and compare the observed branch.

Include invalid input and silence

A menu is incomplete operationally if nobody knows what happens after an invalid key or no input. Test one unadvertised digit and one silence interval. Observe whether the caller hears a helpful repeat, reaches a fallback or disconnects.

Also test a repeated valid key. It can reveal whether duplicate input advances unexpectedly into a second menu. If the assistant retries after not hearing a response, the retry should not silently create a different navigation path.

Keep a simple results table with prompt version, input sequence, timing, observed branch and verdict. An uncertain branch should stay uncertain until someone listens or inspects the destination.

When prompts change during testing, stop and update the expected menu. Continuing with an old key sequence can produce a misleading failure or an unintended destination.

Protect consequential destinations

Some menu branches may reach staff, emergency processes or actions that affect an account. Set the scope before exploration and stop at the agreed boundary. Use authorised test endpoints and a limited number of calls rather than treating a public menu as an unlimited testing target.

A successful digit test on one harmless branch does not establish permission or readiness to explore every path. Keep the acceptance conclusion as narrow as the evidence.

Retest after meaningful changes

Prompt changes, carrier changes and routing edits can invalidate previous results. Preserve the menu version and test date, then rerun the affected branches rather than repeating only the root menu.

Use Burki's IVR testing guide to build a reviewed checklist around the map. Begin with the advertised options, verify their actual destinations and include the silence and invalid-input paths callers inevitably encounter.