Do not have “​help”​ as a universal command
For information on why not, see Commands.

Give callers a context specific command only where help may truly be needed, and call it something besides “​help”​ In most cases, the reprompts will be all the help people need. Almost nobody ever spontaneously says anything like “​help”​ without being prompted unless what the really want is to be transferred. Therefore it is much more worth a designer'​s time and effort to focus on the reprompts. But sometimes there may be something particularly tricky. A command is helpful when some callers will need extra information and some will not. It's also helpful when the extra information is awkward. Consider the following exchange:

* System: Say or enter your account number, or say, where do I find it.
* Caller: Where do I find it
* System: The account number is either in the subject line of your email confirmation,​ or it's in the box at the upper left of your printed statement underneath your name.

In this situation, the reprompt becomes quite long if we simply give the information on where to find it to everybody. Better to only play it when it's truly needed.

Play contextually relevant help messages when it's requested
There are two approaches to providing assistance when callers say “​Help”​ or a similar command: * Switch to a help mode * Play a contextually relevant help message

Because help modes seem to rarely provide the help that callers need in a given dialog step, the prevailing practice is to provide contextually relevant help messages. Help modes were used in the earlier days of IVR, and most designers eschew them in favor of context-sensitive help messaging.

These help messages are often based on the more concise messages played as reprompts for noinput and nomatch events, but tend to be a bit more verbose, covering a wider range of help information than the reprompts.

A related help strategy is to reuse the planned sequence of noinput/​nomatch messages. “In some specific cases it might be necessary to treat help, nomatch, and noinput events differently,​ but those are the exceptions. Usability testing in our lab has shown, however, that callers who say '​Help'​ once do not expect the system to provide different messages or reprompts as a result of saying '​Help'​ again. for this reason, it is a good practice to modify the duration of noinput timeouts for that dialog step from the standard 7 seconds to 3 seconds following an explicit request for help. This increases the likelihood that the caller who has requested help will hear the help message appropriate to the situation”​ (Lewis, 2011, p. 194).

Lewis, J. R. (2011). Practical speech user interface design. Boca Raton, FL: CRC Press, Taylor & Francis Group.