What to include
Represent the tasks that callers are most likely going to want to accomplish
To maximize usage of the IVR, offer callers the routine tasks that they seek most. To do any less than this will result in callers either hanging up or seeking immediate transfer to a live agent. Left unresolved, callers will ultimately learn to avoid the IVR altogether, instead opting for other communications channels.
Even when a task cannot be automated, if it is a frequent call driver, it needs to be included on the menu. It is perfectly OK to list an option that when selected, transfers to an agent.
It is also OK, and even desirable, to include an option that can neither be done through the IVR or with an agent if it is a frequent call driver. Consider this example.
In this case, not offering flights would be ridiculous. Somehow it has to be addressed, or callers will be confused or pick random options to get to an agent to learn they can't be booked offline.
Another approach is to explain the omission before the list of options.
Usage statistics and caller familiarity with the exceptions will dictate which approach is better.
Allow options to appear in multiple menus when it makes sense
There are times when an option genuinely fits in more than one place. Go ahead and put it in multiple places.
For example, “Pay a Bill” might be so frequently chosen that it makes sense to make it an option on the main menu. But if for some reason a caller doesn't notice and selects “Billing” from the main menu, it makes sense to include “Pay a Bill” on that submenu as well, although you should probably put it further down the list since it was already offered.
Another example is from a child support system. “Support Order Information” refers to what the court has ordered to be paid, how often, etc. (Never mind the fact that the label isn't all that clear.) This could easily belong under either “Payments” or “Case Information,” so it's included in both places.
If it's perfectly legitimate for a caller to think it would be in more than one place, then it's OK to include it in more than one place.
All applications that have a main menu should offer the caller the ability to navigate easily back to it Callers sometimes make the wrong selection from the main menu. This mis-navigation may be due to human error (e.g., fat finger, using wrong grammar) or may be application-induced (i.e., the menu options do not reflect the caller's expectations, or the menu options are confusing and overlap). Also, sometimes they do pick the right option, but the speech recognition lets them down and they end up in the wrong path.
As most callers do not have a mental model of the application, particularly those not familiar with the application (e.g., infrequent callers), it is difficult for callers to find a way to correct this initial mis-selection. The best way to allow callers to correct their initial mistake is to allow them to begin again. VUI designers can do this by broadcasting the DTMF option or grammar to go back to the main menu.
Another approach is to explicitly confirm the selection. This should be used infrequently, and only when there is data to support it. An example (real data) is a menu where only 3% of callers are recognized as choosing the last option, and of those, only 40% really wanted that option. The other 60% were roughly split between misrecognitions and misunderstanding of the option. The astute reader will say, ah, the option name needs to be changed if it's not clear and being misrecognized. Rest assured, that was the first path taken. Since it's such a low-use item, the decision was made to add an explicit confirmation that further explained what the option did once it was selected, giving the callers an easy out back to the main menu.
The order has to make sense to the caller. There are three factors that contribute to this. In general, start with the first rule, and modify based on the second and third.
Order the options by usage with the most frequent first
Callers want to expedite their time in an IVR just as much as the company does. To support this, it is usually most appropriate to present the menu options in the descending order in which you expect callers to select them.
Put similar or related options near each other
Since callers are comparing each option presented to their own goal, having related options near each other helps with the comparison. If there are two similar items in a 6-item list that would rank 2nd and 6th in frequency, go ahead and move number 6 up behind number 2 to facilitate the comparison.
If circumstances dictate going deep rather than broad, try to cluster the options into categories logical to the caller-base. Designers can often devise categories using a card-sort technique with the anticipated user population. Even then, the presence of multiple categories should not negate the guideline of presenting options in descending order, albeit a bit more complex. For example, a banking IVR could have two menus, each representing a series of tasks: 'Account Management' which could include (1) checking balances (2) savings balances (3) getting account history, and 'Transactions' which could include (1) scheduling bill payment (2) transfers (3) bill payment history. Again, the menu options within each of these menus should be in the descending order in which you expect callers to select them.
Where an option could be considered a subset of another, put the subset (more specific) option immediately before the superset (more general) option
In some cases, it will make sense to have one option that is a subset of another option due to usage statistics and routing considerations. In this situation, put the one that is a subset before the one that is the superset. It also helps to have those two items next to one another to highlight the difference. For example:
Setting up payments is in fact a billing question, but if your goal is to handle those calls differently, listing it before the generic category will help achieve that. In fact, if you don't put the specific option before the more general option, there is a risk that callers who hear the general option will select it immediately and will never hear the more specific option (Balentine & Morgan, 2001).
Another example. Look back at our travel prompt for new reservations. It's probably in a less than optimal order with 'a vacation package' being last. A caller could very easily select either 'flights' or 'hotel' before hearing the option that combines them.
Balentine, B., & Morgan, D. P. (2001). How to build a speech recognition application: A style guide for telephony dialogues, 2nd edition. San Ramon, CA: EIG Press.