Phone menu design: what the evidence actually says.

The short version

This page sits underneath two practical ones: the call routing and menu design guide (our design advice) and the phone menu script library (copy-ready wording). Rather than add advice, it checks the advice already in circulation, our own included, against what was measured or written into a standard.

How we graded each claim

The most common failure in menu advice is presenting a convention as a finding. We sorted every claim into four grades:

Scroll the table sideways to see every column.

Two limits apply throughout. Most of the experimental work we found dates from the 1990s and 2000s, studies large systems rather than a small business's few-option menu, and was run in English. And the international standard written specifically for IVR user interfaces, ISO 9241-154:2013, is sold rather than published openly; we read its official abstract, not its text, and we do not attribute any specific rule to it.12

Seven, plus or minus two: what Miller actually said

The source usually attached to short-menu advice is George Miller's 1956 paper in Psychological Review, "The magical number seven, plus or minus two"; the 2008 study discussed below describes the five-or-fewer guideline as "commonly citing Miller's (1956) paper".4 It is worth reading, because it does not say what it is used to say.

Miller described two separate limits. The first is the span of absolute judgment: how many levels of a single stimulus, such as the pitch of a tone, a person can identify without comparison. "I maintain that for unidimensional judgments this span is usually somewhere in the neighborhood of seven."1 The second is the span of immediate memory: how many items a person can repeat back straight away. He was explicit that these are different things: "In spite of the coincidence that the magical number seven appears in both places, the span of absolute judgment and the span of immediate memory are quite different kinds of limitations".1 And: "Absolute judgment is limited by the amount of information. Immediate memory is limited by the number of items."1 His closing paragraph declines to read anything deep into the repeated seven: "I suspect that it is only a pernicious, Pythagorean coincidence."1

Later work moved the number down rather than up. Nelson Cowan's 2001 review in Behavioral and Brain Sciences says Miller's seven "was meant more as a rough estimate and a rhetorical device than as a real capacity limit", and argues from a wide body of data for "a single, central capacity limit averaging about four chunks".2

Why neither number maps onto a phone menu

A caller listening to a menu is not doing a memory-span task. Nobody asks them to repeat the list back. They hear options one at a time and compare each against what they want. The memory demand is to hold the best match so far and its key while the rest plays, and, if they choose to hear everything first, to remember which earlier option was the candidate. That is why Commarford and colleagues wrote that "Miller's paper does not, in fact, support this guideline", and that modern working-memory theory "leads to the opposite conclusion".4

Grade: Folklore as applied to menus. Working memory is real and limited, and that is a good reason to keep each option short. It is not a basis for any particular option count.

Broad or deep: what the experiments found

If short menus were better because memory is limited, splitting a long menu into several short menus should help. Two studies tested that directly, and neither found it did.

Huguenard and Lerch, 1993. They built a computational model of phone-based interaction on Just and Carpenter's theory of working memory and tested its predictions against people using menus. Their abstract concludes that "contrary to general guidelines for the design of PBI, deep menu hierarchies (no more than three options per menu) do not reduce WM error rates".3 Storage demands were the strongest predictor of errors, and individual differences in working-memory capacity also mattered.3

Commarford, Lewis, Smither and Gentzler, 2008. Published in Human Factors, this experiment measured each participant's working-memory capacity, then had them complete email tasks with one of two speech-enabled IVR designs that were functionally equivalent, one broad and one deep. "Users of the broad-structure IVR performed better and were more satisfied than users of the deep-structure IVR", and the effect "was more pronounced for those with low working memory capacity".4 The authors' conclusion: "creating a deeper structure is more demanding of working memory resource than the alternative of longer, shallower menus."4

These studies do not show that a twelve-option menu is fine. The 2008 study used spoken input and email tasks rather than a keypad and a business call, and both were laboratory studies. What they show is narrower and still useful: adding a level costs more than adding an option, and the people who pay most are those with the least working memory to spare.

Where "four or five" and "six" come from

The numbers in circulation do have sources, but they are guidance documents, not experiments:

• ETSI ETR 096 (1993), a human-factors technical report for phone-based interfaces: "In general, no more than six options should be assigned to a menu that have no pre-assigned functions to a keypad."7 It is a technical report, not a standard, and the sentence is about keypad assignment alongside reserved command keys.
• AHRQ's Health Literacy Universal Precautions Toolkit, for medical practices: "Create a menu with no more than five choices", alongside "Always have an option to speak to a person."6 The page gives no study for the figure.

Older callers deserve a specific mention. Sharit, Czaja, Nair and Lee ran two experiments with simulated voice menus and three age groups (18 to 39, 40 to 59, 60 and over). With 196 participants they found "age differences in performance, especially for complex problems", and "no effect of speech rate on any of the performance measures". In a second experiment with 114 participants, "the older participants benefited more from the graphical aid".5 The lesson there is about memory support and task complexity, not a magic option count.

Grade: Tested for "avoid depth"; Standard for "about five or six options at most"; Folklore for any claim that four or five is a proven limit.

The keypad sets the real ceiling

ITU-T Recommendation E.161 fixes the arrangement of digits, letters and the star and square (pound) keys, and recommends a raised tactile marker on the 5 key so it can be found by touch.9 It also records, in a footnote, a convention North American callers know: "On the North American dials and keypads, the digit 0 is associated with the word 'operator'."9 That is the documented basis we found for "press 0 for a person": a regional association, reinforced by W3C accessibility guidance (see below), rather than a requirement in any menu standard we read.

ETR 096 adds three ordering conventions: options should be laid out so that "commonly selected options require the shortest available key sequence", they should be assigned "in a logical order starting on key [ 1 ]", and generic commands such as help and cancel are reached through the star key, so they do not use up menu digits.7

So in practice a single-level keypad menu offers at most the nine digits from 1 to 9 plus 0, and fewer once 0 is kept for a person and keys are reserved for a language choice. (For reference, Auto Attendant allows up to seven options in every layout, on keys 0 to 9; on a menu in more than one language, callers either choose the language first or use keys 7, 8 and 9 at the end of the menu for Spanish, French and English.)

Grade: Standard. Most common first, numbered from 1, 0 for a person.

Say the result before the key

"For billing, press 2" rather than "Press 2 for billing" has the longest standards paper trail of any wording rule on this page.

ITU-T Recommendation E.183, Guiding principles for telephone announcements (revised 1998), states it as principle 2.8: "If an action and its consequence are described, the consequence should be stated first, then the action (e.g. 'To receive this message, please press the # button', rather than 'Please press the # button to receive the message')."8 ETSI's 1993 report repeats it and credits the earlier CCITT edition of E.183 as its source: "In a menu item, the anticipated result should be indicated before the command. It is better to say: 'To listen to your messages, press key x' than: 'Press key x to listen to your messages'."7

The reasoning is about memory. W3C's cognitive accessibility research module explains that "the instruction 'to speak to a nurse, press 2' stands by itself and does not require remembering anything before or after", and that a pause between the two halves "gives users time to decide if they want to speak to a nurse before they are given the rest of the instructions".11 Key first, and the caller must hold an arbitrary digit while still deciding whether the label applies.

E.183 contains several other principles that are rarely quoted and are directly useful for a greeting:8

• "Announcements should not commence with a significant word." E.183 does not say why; our reading is that the opening words are the likeliest to be missed while a caller settles the phone at their ear, which is a good reason to open with "Thanks for calling" and the business name rather than with the first option.
• "Ideally only one piece of information should be conveyed in an instructional announcement, but for practical purposes a maximum of three is recommended."
• "The speech rate should not exceed normal conversation speed", which it gives for English as "150 to 200 words or 300 to 500 syllables per minute".
• When an announcement is repeated once, "the pause between the original announcement and its repetition should be about 2 seconds".
• Guidance announcements that ask for input "should normally be produced only once", whereas acknowledgement and error messages should be produced twice. In menu terms: do not play the whole menu twice by default; repeat it in response to silence or a request.

Grade: Standard, with a well-founded Reasoned mechanism.

Speech recognition or the keypad

The main alternative to numbered keys is letting callers say what they need. The evidence is genuinely mixed, and the mix matters for a small business.

Where speech won. Suhm and colleagues ran a field study in the call centre of a large telecommunications provider, comparing natural-language call routing with a standard touch-tone menu. With natural language, "more callers respond to the main routing prompt, more callers are routed to a specific destination (instead of defaulting to a general operator who may have to transfer them), and more callers are routed to the correct agent", and callers "overwhelmingly prefer natural language call routing".13 That is a large organisation with many destinations, which is exactly where a keypad menu struggles.

Where the keypad won. Lai and Lee compared speech and touch-tone navigation in a working natural-language message-retrieval system with 16 users. "A majority of users preferred interacting by speech even though the touchtone interface was more efficient as measured by the success rate and speed for each task."14 Preference and performance pointed in opposite directions.

Who gets misheard. Koenecke and colleagues tested five commercial speech recognisers (from Amazon, Apple, Google, IBM and Microsoft) on interviews with 42 white and 73 Black speakers and found "an average word error rate (WER) of 0.35 for black speakers compared with 0.19 for white speakers".15 That study measured transcription of conversation, not short menu commands, and the systems have changed since; but it is direct evidence that recognition accuracy is not evenly distributed across callers, and a menu that depends on it will fail some groups more than others.

Who cannot speak at all. The FCC's accessibility rules for interactive menus (47 CFR Part 7) list, among the modes a provider must offer where readily achievable, "Operable without speech. Provide at least one mode that does not require user speech."20 A keypad path is that mode.

If you do offer speech, use words callers already know. ETSI ES 202 076 standardises a minimum spoken command vocabulary: in English "Help", "Operator", "Main menu", "Options", "Stop", "Go back" and "Repeat", with French equivalents such as "Aide", "Menu principal" and "Répéter" listed alongside.16 It notes that the operator command "should also be used when offering relay services", and it explicitly "does not cover dialogue design issues", so it tells you which words, not how to build the menu.16

Our view: for a business with two to five destinations, the advantage speech showed in the call-centre study (getting callers to the right one of many destinations) largely disappears, while the costs (misrecognition, callers who cannot speak, noisy environments) remain. A keypad menu, optionally with speech as a second input, is the defensible choice. Grade: Tested, with results that depend on the size of the menu.

Silence, timeouts and the dead end

What happens when a caller says or presses nothing is the most neglected part of menu design and the one with the clearest guidance.

ETR 096 gives ranges rather than a single number: after user inactivity "the system should react by prompting the user (between 5 seconds and 20 seconds)"; after "a specified time (4 seconds to 8 seconds)" without input "either the last prompt should be repeated, or an in context help message should be presented"; and during multi-digit entry a reminder after "1 second to 4 seconds". It adds that time-outs "should be controlled so that the user is never left in a vacuum", and that "The system should be developed so that time-outs may be changed."7

The W3C's VoiceXML 2.0 Recommendation, the web standard for writing voice dialogues, deliberately leaves the number to the platform: the timeout "after which a noinput event is thrown" has a default that "is platform-dependent", as does the inter-digit timeout.17 So the figure you get is whatever your vendor chose:

Scroll the table sideways to see every column.

The Asterisk default is the dead end in its purest form: a menu missing one line hangs up on a caller who hesitated.

The accessibility rules point the same way. Among the modes 47 CFR Part 7 asks providers of interactive menus to offer is one that is "Operable without time-dependent controls. Provide at least one mode that does not require a response time or allows a response to be by-passed or adjusted by the user over a wide range."20 W3C's research module notes that users of augmentative and alternative communication or speech-to-speech services "may require significant additional time to respond before the system times out".11

Grade: Standard. Wait several seconds after the prompt ends, repeat once on silence, and make the final silence route end at a person or a voicemail box, never a hang-up.

Relay users, older callers and anyone without spare memory

Relay users

People who are deaf, hard of hearing or speech-disabled may reach a business through a relay service, where a communications assistant (CA) speaks and types for them. The FCC's minimum standards for relay acknowledge that menus are a known problem: "CAs must alert the TRS user to the presence of a recorded message and interactive menu through a hot key", and "Relay providers may not impose any charges for additional calls, which must be made by the relay user in order to complete calls involving recorded or interactive messages."21 The rule anticipates that a menu may take a relay user more than one call.

The same rules set a minimum CA typing speed of 60 words per minute,21 against an English announcement rate of 150 to 200 words per minute in E.183.8 Our arithmetic, not a measured result: a menu spoken at 150 words a minute and typed at 60 reaches a text relay user over two and a half times more slowly than it is spoken, so a timeout tuned for hearing callers can expire before the relay user has read the options. That is the practical case for generous timeouts and a 0-for-a-person route.

In Canada, the CRTC requires two text relay services to be available to all Canadians: TTY relay, reached by dialling 7-1-1, and IP relay, reached through the provider's web portal.22 The FCC rules quoted on this page are United States rules; we did not find a CRTC rule specific to how a business menu must treat relay callers, and we do not claim one.

Older callers and callers with weaker working memory

The studies above point the same way. Age differences grew with task complexity,5 the penalty for deep menus fell hardest on low working-memory users,4 and a memory aid helped older users more than a faster or slower voice did.5 W3C's cognitive accessibility design pattern turns this into concrete guidance: provide "a known word or reserved digit (such as '0' or 'help') that can be used at any time to skip the voice menu and go directly to a person", avoid "unnecessary or distracting information such as promotional information", and "Allow for easy error recovery".10 It is published as supplemental guidance, "not required to meet WCAG".10

Who the US rules bind

47 CFR Part 7 applies to "Any provider of voicemail or interactive menu service" and to manufacturers of equipment that performs those functions, and its obligations apply "if readily achievable".20 Whether a particular small business that merely uses a menu falls inside that scope is a legal question we do not answer here. We use the rule as a design benchmark, which it is regardless of who it binds.

Common claims, checked

Scroll the table sideways to see every column.

Evidence-graded rules for a small-business menu

Our rules, each tagged with the strongest support we found; where a rule is our judgement, it says so. The call routing guide covers the business decisions (ring order, after-hours) the research does not reach.

1. Prefer one level. If you need more destinations, add an option before you add a sub-menu. Tested.34
2. Keep the top level to what callers actually ring about, which for most small businesses is two to five reasons. Standard as a soft ceiling; the exact number is our judgement and should come from your own call log, not from Miller.67
3. Most common reason first, numbered in order from 1. Standard.7
4. Result before key, with a short pause between them ("To book a repair … press 1"). Standard, mechanism reasoned.811
5. Open with the business name and a neutral phrase, not the first option; nothing promotional before the choices. Standard.810
6. Reserve 0 for a person, and make it work at any point in the menu. If nobody can answer, 0 should reach a voicemail box that somebody reads, not a loop. Standard (regional convention plus W3C guidance).910
7. Keypad always; speech only as an addition. Tested and required as a mode for providers under the FCC's Part 7 rules.141520
8. Silence: wait roughly four to eight seconds after the prompt ends, replay once, then route to a person or voicemail. Never hang up. The range is ETSI's;7 the "never hang up" is our rule, made necessary by platform defaults.19
9. An invalid key gets a short "that is not an option" and one replay, then the same safe route. Standard (easy error recovery).10
10. Speak at a normal conversational pace; do not slow the recording down as an accessibility measure. Standard on pace;8 Tested on the absence of a benefit from slowing it.5
11. Assume some callers are relay users: generous timeouts and a working 0 matter more to them than wording. Standard.2021

Two topics the research barely touches are covered elsewhere: emergency wording (a business menu is not an emergency service; see emergency calling) and bilingual layout for Canada (see serving Canada).

A test protocol that produces evidence, not reassurance

The script library ends with a launch smoke test: call every route and confirm each one works. That checks the wiring. The protocol below checks whether callers can use the menu, which is the question the research keeps answering with "test it". The thresholds are our own judgement, labelled as such; we know of no published pass mark for small-business menus.

1. Build the scenario list from real calls

Log the reason for every inbound call for two weeks, or the last 50 calls, in the caller's words. Group them, and write one test scenario per group, phrased the way a caller would say it ("my furnace is making a noise", not "service request"). A scenario that uses your menu's own label tests nothing.

2. Recruit five to eight testers who are not staff

Include at least one person over 65, one whose first language is not the menu's, and, if you can, someone who uses a relay service. Relay services exist for their users, not as a test tool; otherwise simulate the delay: one person types what they hear and a second chooses from the typed text alone.

3. Run each tester through every scenario, by phone

Give one scenario at a time, read aloud, then have them call the real number from their own phone, ideally somewhere with ordinary background noise. Record, for each attempt:

• First-key success: was the first key pressed the right one?
• Time to destination: from the first ring to the moment the right phone rings or the right voicemail answers.
• Replays: how many times they let the menu repeat or asked for it again.
• Zero-outs: how often they pressed 0 or asked for a person instead of choosing.
• The tester's own words for what they expected an option to mean, collected after the call, not during it.

4. Judge it

Our thresholds: every scenario should be completed by every tester; first-key success should be at least four in five per scenario; and no scenario should need a replay from more than one tester in five. A scenario that fails is a wording or grouping problem, not a tester problem. Rewrite the label in the words testers used, and re-test only what changed.

5. Watch the live numbers

Once live, three figures from the call log say most of what a further test would: the share of calls with no key pressed, the share with an invalid key, and the spread of choices against your call-reason log. If option 3 gets a quarter of the calls but your log says a tenth, callers are using it as a catch-all and its label is too broad. Re-run the protocol after any change to options, staff or hours.

What this evidence does not settle

• No study we found tests a small-business menu. The experiments used laboratory tasks or large call centres, and the abstracts we read do not give the menu lengths compared. We are extrapolating, and have said where.
• ISO 9241-154. The current international standard for IVR user interfaces, confirmed in 2026, covers both touch-tone and speech-recognition systems.12 Its text is sold and we did not read it; a designer with access should check it against the rules above.
• Recent speech systems. The accuracy gap we cite was measured for a 2020 paper15 and the speech-versus-keypad comparisons are older. Treat them as reasons to test, not as a verdict on today's products.
• Our interest. We sell a keypad-based menu service, so a conclusion favouring keypads suits us. That is why every step of that argument above is cited, and why we have set out the evidence for speech alongside it.