The option labels must be clear on two levels. First, the caller must be able to easily understand the label. Second, the option must exactly represent the target task. Anything less will lead to confusion.

As much as possible, menu options should be mutually exclusive so there is no reason for a caller to need to waffle between options.

Avoid “For (blank) say (blank)” structure as much as possible
There are two extremes for this structure. One is where the blanks are identical or nearly so:

• For checking, say “checking.”

• For your checking account, say “checking.”

The other is where you take a big hairy option and boil it down to a word or shorter phrase:

• To set up billing arrangements, ask a question about a bill, or make a payment, say “billing.”

The former case is no more than a “speechified” DTMF prompt, and at that, it's actually more annoying than DTMF because of the repetition. A list of these type of options almost guarantees a sing-song delivery. And it doesn't afford the opportunity to taper that a DTMF prompt would do. There is almost always a better way to write this type of menu.

The latter example is a whole other story. It's a cognitive load, clear and distinct, and broad vs. deep issue all in one. A much better alternative is just to list them out as separate options.

• You can say “set up billing arrangements,” “question about a bill,” or “make a payment.”

And even with other options in the menu, broad and straightforward is still going to win over convoluted and deep. Because you know with the three-in-one option there will be a submenu underneath it. And suppose there's not; suppose that option goes straight to an agent, and a single agent group handles all three. That kind of logic (how does the call route) often drives prompt decisions (make it all one since they go the same place). However, breaking it out to three choices and routing them all the same way makes for a better caller experience, plus it has the added bonus of allowing you to track how many people choose each of the sub-options.

There are times when the structure is unavoidable. There are certain things that cannot be boiled down to a clear and distinct phrase for a prompt like:

• You can say a, b, c, or d.

In most cases, this will only apply to one of your options. So only use the other structure where you have to.

• You can say a, b, c, or for this complicated thing I need to explain, say d.

Make each phrase/grammar/menu option the right length
Phrases should be long enough that they are phonetically distinct to avoid speech recognition errors (when speech recognition is being used), short enough that the caller is able to reliably repeat options, long enough to be adequately descriptive such that the caller is confident that the selection he is picking maps to the task being attempted, but not so long as to be overwhelming. Quick, actionable phrases, such as “check account balance,” “cancel service,” “make a payment,” are usually the best balance in terms of practicality and semantic meaningfulness.

Taper when possible
Tapering is the process of eventually dropping away words that would otherwise become repetitive in a system prompt that callers will hear often. Here is a good example of tapering from Cohen, Giangola, & Balogh, 2004: 213:

System: …Now, what's the first company to add to your watch list?

Caller: Cisco Systems.

System: What's the next company name? Or, you can say “Finished.

Caller: IBM.

System: Tell me the next company name, or say “Finished”.

Caller: Intel.

System: Next one?

Caller: America Online.

System: Next?

The system is slowly shortening the way it prompts the caller to provide information as context and expectations are established, thus making the exchange briefer and more natural than it would be otherwise. In the context of menu option prompting, tapering can be a useful tool in systems where prompts must refer to both speech and DTMF options for a given menu choice:

You can say “Pay my Bills”, or press 1; “Check my Balance”, or press 2; “Transfer Funds”, or 3; “Make a Payment”, 4 …

A travel company has the following situation for its cruise number. All calls need to be split into sales vs. service to be handled by two different outsourcers who cannot transfer between themselves. So if the caller doesn't choose right, they have to hang up and call again. The caller may not have a reservation at all (sales), they may have put a cruise on hold without any payment information (sales), they may be making payments on it (service), or it may be totally paid for (service).

This proved to be an extremely difficult menu to write to get all four groups to correctly self-segregate. Internally the company thinks of the first two situations as new reservation and on hold, and the last two as booked. But the three levels of payment (none, partial, all) are different in callers' minds. There were multiple iterations, most of which were more elegant than the following. But ultimately, this is what worked.

I need to know where you are in the booking process. If it’s either partially or totally paid for, say it’s already booked. If you’ve put it on hold without giving us any payment information yet, say it’s on hold. Or say book a new cruise.

Part of what makes this menu work is the introductory phrase. It sets the stage for what the caller is listening for. This can make or break a menu, especially if there's anything tricky in it. It also helps you keep the phrases in the menu as short as possible.

Cohen, M. H., Giangola, J. P., and Balogh, J. 2004. Voice User Interface Design. Boston: Addison-Wesley Professional.

Nairne, J. (2002). Remembering over the short-term: The case against the standard model. Annual Review of Psychology, 53, 53-81.

Resnick, M. & Sanchez, J. (2004). Effects of organizational scheme and labeling on task performance in product-centered and user-centered web sites. Human Factors, 46, 104-117.