Keypad or Voice Commands? DTMF Phone Menus Explained

The short answer

A phone menu takes input two ways. The caller presses a key, which sends a DTMF tone (dual-tone multi-frequency, the "touch tone"), or the caller speaks and a speech recognizer guesses what was said. Larger systems often accept both.

For a small business with a handful of choices, a keypad menu is the safer default:

• Every phone can send keypad tones, under an international standard that has existed for decades.
• A keypress does not depend on accent, room noise or language. A "2" is a "2" in a quiet office or a loud shop.
• Speech earns its place with many or hard-to-number choices, such as a staff directory. A five-option menu rarely needs it.
• When keypresses fail, the cause is usually the call path, not the caller: a VoIP device or PBX sending tones in a format the menu does not read. That is fixable.

What DTMF is, and why "press 1" works on any phone

Each key sends two tones at once, one from a low group and one from a high group. ITU-T Recommendation Q.23, the standard for push-button telephone sets, sets the low group at 697, 770, 852 and 941 Hz and the high group at 1209, 1336, 1477 and 1633 Hz: 16 combinations, the ten digits plus six other signals, with each frequency held within plus or minus 1.8% of nominal ^[1].

The A to D keys exist in the standard but are rarely found on consumer phones.

The receiving side is covered by Recommendation Q.24 ^[2]. Two points matter for menus:

• Tones must last long enough. The receiver parameters Q.24 lists for several administrations, including AT&T in the US, all require a tone of at least 40 milliseconds to register.
• Noise causes three distinct failures. Disturbances "may cause MFPB signals to be missed, split (double signal registration) or cause signal simulation": a press that is not heard, one press counted twice, or a digit nobody pressed.

Those are still the failures callers report, even though calls now travel over the internet.

How a keypress crosses a VoIP call

On a copper landline the tone travels as sound. On a VoIP call there are three common ways to carry it, and each link in the path must agree on one.

RFC 4733 (IETF, December 2006) replaced RFC 2833 and states the problem plainly: "low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition," naming G.723.1 as a codec that can make tones unintelligible ^[3]. Each key gets an event code (0 to 9 for digits, 10 for *, 11 for #), events share the audio's timestamps so they stay in step with the call, and the final packet of each event should be sent three times to survive packet loss.

For SIP INFO, RFC 6086 (January 2011) notes that companies have used INFO messages to transport DTMF and that "all mechanisms are proprietary and have not been standardized" ^[4].

Why this matters in practice: Twilio says its <Gather> menu command supports RFC 2833 DTMF but "does not support DTMF via in-band signaling or out-of-band SIP INFO messages" ^[5]. A caller whose office PBX sends only SIP INFO could press keys all day without the menu noticing. Platforms differ, so the fix is to check what each hop sends and what the next hop accepts.

Voice commands: where speech helps and where it fails

Speech menus let callers say "billing" or a name instead of a number. Microsoft's Teams auto attendant says "speech recognition accepts voice commands for hands-free navigation, but people calling in can also use the phone keypad" ^[6]. Amazon Connect's input block takes keypad digits or an Amazon Lex speech bot ^[7].

Speech helps with long lists that do not map to digits (dial by name) and with open questions in contact centres that can afford to tune a recognizer. It struggles with:

• Vocabulary. Callers do not know which words will work. Nielsen Norman Group's phone-tree guidelines say to "always provide an alternative navigation method," and that offering the keypad at the start, alongside speech, beats falling back to it after a failure ^[8].
• Accents and dialects. A 2020 PNAS study of recognizers from Amazon, Apple, Google, IBM and Microsoft found an average word error rate of 0.35 for Black speakers against 0.19 for white speakers, linked to pronunciation differences ^[9]. It measured interview transcription, not menu commands, but recognition quality clearly is not equal across callers.
• Language. In the Teams auto attendant, 14 of 54 listed languages support speech recognition; picking another "disables the voice inputs option within the menu" ^[10]. English (Canada), French (Canada) and Spanish (Mexico) are supported; Spanish (United States) is not in the table. Twilio's <Gather> listens for en-US unless told otherwise ^[11]. A bilingual menu usually needs a keypress to pick the language before any speech prompt.
• Noise. Traffic, wind or a busy counter reach the microphone. A keypad tone is generated inside the phone.
• Accessibility. Some callers cannot speak clearly or use a TTY or relay service. As of October 2026, the US federal Revised Section 508 Standards, mandatory for federal agencies rather than small businesses, require auto-attendant and IVR systems to be "usable with a TTY" (412.8.4, US Access Board). A speech-only menu fails that benchmark. This is educational information, not legal advice.

Even speech-first products plan for failure: Microsoft's reports for its AI phone agent include a "Fallback To DTMF" action, and its auto attendant reports split directory searches into DTMF and voice ^[12].

Hybrid menus and timeouts

A hybrid menu accepts either input at the same prompt. Twilio's input="dtmf speech" "gives precedence to the first input it detects"; the default is dtmf alone ^[11].

Timeouts set how patient the menu is, and defaults are short:

If a Twilio <Gather> gets no input it moves to the next instruction, so the "no input" path is whatever the builder set up. Make it deliberate: repeat once, then route to a person or voicemail. NN/g recommends that menus repeat automatically when callers do not choose promptly ^[8].

AWS also documents that when a call passes between flows, a caller who types ahead fast can lose digits: 5123 entered quickly may register as 23 or 3 ^[7]. One keypress per step avoids most of this.

Mobiles, speakerphones and cars

We found no published data on how often keypresses fail from car kits or Bluetooth headsets, so these are practical observations, not measured rates. On most smartphones the keypad is hidden during a call and the caller must wake the screen and tap "Keypad" first. In a car the dial pad may be on the dashboard, on the phone, or unavailable while driving. On speakerphone, callers often miss which number goes with which option. Design for them: option first and number second, presses accepted at any time, and "do nothing" leading somewhere useful.

What goes wrong: troubleshooting table

Menu scripts that work for keypad users

Three NN/g habits do most of the work: task before number ("For billing, press 2"), presses accepted before the prompt ends, and numbering from 1 ^[8]. Keep the menu broad rather than deep: in a study of a speech-enabled IVR, users of a broad menu performed better and were more satisfied than users of a deeper one, which demanded more working memory ^[13].

Single-level menu

Thank you for calling [Business name]. For appointments, press 1. For billing, press 2. For directions and hours, press 3. To leave a message, press 4. To hear these options again, stay on the line.

Bilingual start

Thank you for calling [Business name]. For service in English, press 1. Pour le service en français, appuyez sur le 2.

Hands-free friendly

You have reached [Business name]. If you are driving, stay on the line for [Name]. For sales, press 1. For support, press 2.

More templates: phone menu scripts for small business. The evidence on option count and order: phone menu design evidence.

Test checklist

• Call from a mobile on cellular and on Wi-Fi calling; press every option.
• Call from a landline and from any office PBX staff use.
• Call from a car or Bluetooth headset; note how long reaching the keypad takes.
• Press each key quickly, then hold one for a full second; check for double counts.
• Press during the prompt and confirm it is accepted.
• Press a key that is not on the menu; check what the caller hears.
• Press nothing; confirm the menu repeats and then goes somewhere useful.
• Test every language branch, during open and closed hours.
• Have someone unfamiliar with the menu reach a named option.

FAQ

Can callers say their choice instead of pressing a key? Only if the menu uses speech recognition. Many small-business menus are keypad only; if yours is, say "press" in every prompt.

Why didn't my keypress register? Usually a VoIP device or PBX between the caller and the menu sent the tone in a format the menu does not read, or a codec distorted an in-band tone. If the same menu works from another phone, the problem is on the caller's side of the path.

What is the # key for? On many systems # submits a multi-digit entry; it is Twilio's default submit key ^[11]. NN/g suggests * to repeat and # to go back or submit, used consistently ^[8]. Single-digit menus do not need it.

Do I need speech recognition for a small business menu? Usually not. With a handful of distinct options, a keypad menu is predictable for every caller. For how menus route calls in general, see what an auto attendant is.

Auto Attendant menus are keypad (DTMF) only, with up to seven options and no speech recognition.

Sources

1. RFC 4733, RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals (IETF, Dec 2006). https://www.rfc-editor.org/rfc/rfc4733 : codecs and tones, event codes, triple end packet.
2. ITU-T Q.23, Technical features of push-button telephone sets (11/88, in force). https://www.itu.int/rec/T-REC-Q.23 : DTMF frequencies and tolerance.
3. ITU-T Q.24, Multifrequency push-button signal reception (11/88, in force). https://www.itu.int/rec/T-REC-Q.24 : 40 ms minimum; missed, split or simulated signals.
4. RFC 6086, SIP INFO Method and Package Framework (IETF, Jan 2011). https://www.rfc-editor.org/rfc/rfc6086 : DTMF over INFO is proprietary.
5. Twilio, What are DTMF tones? https://www.twilio.com/docs/glossary/what-is-dtmf : <Gather> reads RFC 2833 only.
6. Twilio, TwiML <Gather>. https://www.twilio.com/docs/voice/twiml/gather : input modes, timeout, #, default language.
7. AWS, Amazon Connect: Get customer input. https://docs.aws.amazon.com/connect/latest/adminguide/get-customer-input.html : DTMF and Lex input, timeouts, lost type-ahead digits.
8. Microsoft Learn, Overview of voice applications (Teams). https://learn.microsoft.com/en-us/microsoftteams/plan-auto-attendant-call-queue : speech and keypad navigation.
9. Microsoft Learn, Teams auto attendant supported languages. https://learn.microsoft.com/en-us/microsoftteams/create-a-phone-system-auto-attendant-languages : speech recognition by language.
10. Microsoft Learn, Voice applications historical reports. https://learn.microsoft.com/en-us/microsoftteams/aa-cq-report-historical : "Fallback To DTMF"; DTMF vs voice searches.
11. Nielsen Norman Group, The UX of Phone-Tree Systems: 16 Usability Guidelines (Aug 2022). https://www.nngroup.com/articles/phone-tree-guidelines/ : keypad alternative, option before number, repeats.
12. Commarford, Lewis, Smither, Gentzler, A comparison of broad versus deep auditory menu structures, Human Factors 50(1), 2008. https://stars.library.ucf.edu/facultybib2000/233 : broad beats deep.
13. Koenecke et al., Racial disparities in automated speech recognition, PNAS, 2020. https://www.pnas.org/doi/10.1073/pnas.1915768117 : word error rates by speaker group.
14. US Access Board, Revised Section 508 Standards. https://www.access-board.gov/ict/ : 412.8.4, IVR usable with a TTY.