“Prompt” is used to mean a wide variety of things, from the questions the system asks the callers to information it plays back to the stuff that doesn't really fit in either category, like discourse markers. Each category has further subdivisions as well. Here we briefly talk about different kinds of prompts.

Initial prompt writing
Guideline: Ensure that initial prompts (the prompt the caller will hear the first time in a dialog state) are succinct yet explanatory enough that callers know how to respond.

Comments: One of the most important things to consider when writing initial prompts is the caller demographic. Repeat callers? One-call-and-done situations? Elderly? Experience with automation? The answers to these questions will help determine how “wordy” or how much of an explanation is required for a response from the caller. It doesn't save any time to write a super short initial prompt when every caller has to end up hearing a reprompt to know how to respond. Conversely, it's a huge waste of time to go into a lengthy explanation of menu options when they're self explanatory (like “make a payment”, “hear balance”, etc.). Another critical aspect is context - ensure that you know what has come before this intial dialog state prompt so that there are no continuity problems, and so that you know whether the modality needs to be flagged to the caller e.g. “What's your account number?” vs “Please say or enter your account number”.

Reprompts
Guideline: Ensure that reprompts serve their purpose – to enable to caller to recover quickly from an error made in response to the initial prompt.

Comments: Reprompts (or retries) are prompts that are presented ONLY after callers (1) fail to provide an input to the initial prompt or (2) fail to respond to to the initial prompt in a manner that the IVR was built to understand.

Generally speaking, there are two types of retry categories:

1) No Input reprompts are prompts that are presented to callers when they fail to provide any input to the initial prompt. The no input reprompt would usually play after a pre-determined number of seconds has passed since the completion of the playing of the initial prompt.

2) No Match reprompts are prompts that are presented to callers when they provide input to the initial prompt in a manner that the IVR was not built to understand OR the IVR did not understand a valid speech response (either because the utterance was not clear or the recognizer did not have sufficient confidence in the utterance to interpret it). A DTMF example of a no match reprompt would be when a menu is configured to offer 5 options and the caller presses “6”. An ASR example of a no match reprompt would be when a menu is configured to accept 5 specific grammars equating to 5 specific menu options and the caller says something that does not match any of the defined grammars for that menu.

An effective reprompting strategy is one where the reprompt informs the caller about the specific sort of input required to progress in the system. An example of an effective reprompt would be:

• System: Say your account number.

• Caller: Um, where's my account number?

• System: Sorry. Please say your nine digit account number. You can find it at the bottom of your billing statement.

• Caller: 123-456-789.

3) Disconfirmation reprompts play if the caller says “No” to an utterance that is confirmed. Let's say confirmation is set to Always, so the system confirms the caller's utterance (“You'd like to pay your bill. Is that right?”). If the caller says “No”, it's better for the IVR to recognize this situation as something different than a no match. It would make more sense for the caller to hear “My mistake” (a disconfirmation prompt) instead of “I didn't understand” (a no match prompt). The caller may be confused by the no match prompt, thinking the system didn't understand the “No” response, and this leads to the caller saying something like “I said no” when the IVR has now transitioned to listening for a menu response instead of a yes/no. It is absolutely okay to use the specific content of the no match prompt in the disconfirmation prompt, as long as the generic portion of the prompt (“My mistake” versus “I didn't understand”) is specific to the case at hand. Here's an example:

• System: Say your account number.

• Caller: 123-456-789

• System: That was 123-496-789. Is that right?

• Caller: No.

• System: My mistake. Please say your nine digit account number. The number can be found at the bottom of your billing statement.

Reprompts can be conceptualized in terms of number of levels. The aforementioned example is an example of a “first” level reprompt – in other words, it is the first time the caller has been reprompted. A properly constructed “second” level reprompt – the second time a caller is reprompted for the same initial prompt – would offer additional support for the caller. Often, this might be DTMF input as an alternative to ASR input:

• System: Say your account number.

• Caller: Um, I'm still not sure where to find this.

• System: Sorry, I “still” didn't understand that. Let's try this another way. Using your keypad, enter your nine digit account number. The number can be found at the bottom of your billing statement.

• Caller: 123-456-789.

Help messages
Guideline: Ensure that caller knows that (1) help is available (2) how to access help and that (3) help prompts are helpful. By this, it is meant that help prompts should not be mere repetitions of initial prompts. Help prompts should provide additional information necessary for the caller to succeed in the dialog state.

Comments: Ideally speaking, help should not be a necessary offer of IVRs. A properly constructed dialog state should concisely convey the caller input required without need for further explanation. Currently, many systems are moving away from the use of “help” as a globally-recognized utterance, as the shortness of the “help” utterance is very easily confusable.

That being said, however, in practice, there are times when the caller requires additional support in order to provide valid input but that this additional support would be impractical, due to length, to provide as in the initial prompt. In this instance, it is useful to provide the caller with access to dedicated help. In this case, the prompt might not even be accessed by the word “help.” For example, this might be a system written for expert users:

Command? (pause 1 second) Or, say “list commands.”

It is important to let the caller know that help is available. Making the caller aware of help availability may be done at the initial prompt in a dialog state or at the reprompt level. Where it is anticipated that callers may experience some ambiguity as to how to make a valid input or what option to select among several, it is useful to make help accessibility known in the initial prompt. Where it is not anticipated that many callers may experience trouble providing valid inputs to a dialog state, it is useful to make accessibility known in the reprompt; this so that most callers will not have to endure listening to a lengthy initial prompt.

For DTMF-enabled IVRs, it is recommended that the “star H” be used to access help. For ASR-enabled IVRs, it is recommended that the designer craft a help grammar greater than one syllable in length. Single-syllable grammars are often mis-recognized by the system and a grammar as short as “Help” is no exception. It is recommended that the system offer grammars such as “Help me” or “I need help” are better alternatives. Making Sure Help is Helpful It has become an unfortunate practice to merely repeat the information presented in the initial prompt or reprompts. Callers will usually find such help to not be of much utility. For help to be truly helpful, it is critical that the designer understand the potential for callers to misunderstand the task at hand. Consider the example of a dialog state soliciting a user ID from a caller. If the user has more than one user ID, to which user ID is the system referring? Is the proper jargon referring to the ID even being used? Perhaps the caller knows the required ID not as a user ID but, rather, as a UID. If so, then such clarifying information, along with a practical example of a valid input, would be helpful to the caller.

Guideline: Ensure that the caller knows that they are exiting from the IVR, where they are being taken to, and any additional information or actions that will be required of them.

Discussion: Two categories of exit prompts exist: (1) Hang-ups and Goodbyes; and (2) Transfers.

• Goodbyes Goodbyes occur when the IVR initiates to end the call. Disconnects can be designed to occur for a variety of reasons such as failure for the caller to provide even one attempted input or some sort of system error where the information the caller requests cannot be retrieved and the agent will not be able to either.

• Hang-ups Hang-ups occur when the caller initiates to end the call. End calls are different than hang ups as the latter can happen for a variety of reasons anywhere in a call flow. On the other hand, end calls happen when a caller had traversed a call flow path and has no further need of the IVR at that time.

For more details and strategies for designing Hang-up and Goodbye prompts, see Chapter 6: Hang-ups and Goodbyes

• Transfers Transfers occur when (1) the caller wishes to be connected with an agent; (2) the IVR is not capable of handling the caller's need through self-service; or (3) the caller has exceeded the number of reprompts allowed for the dialog state.

For more details and strategies for designing transfer prompts, see Chapter 6: Transfers

Play states
A play state is used when the system isn't expecting a response from the caller. Typical examples include: (1) greetings; (2) transfer and end call prompts; (3) important informational type messages that shouldn't be interrupted.

Putting the system on hold
Certain applications may require that the caller step away from the system, or put the system on hold. A common example is an IT support system. If the caller needs help diagnosing a problem with her Internet, the application may walk her through multiple steps, some of which require her to do things like rebooting a modem, unplugging a router, etc. In these situations, the application goes into “wait” mode until the caller gives a signal indicating she has completed the task. A common way to do this is as follows: “I'll stay on the line while you reboot your modem. When you're finished with that step, press 1 to continue.” Many times the system will play audio, like hold music, indicating it's still waiting and hasn't disconnected the call. Also, after a specified amount of time, the system will ask the caller, “Are you still there? If you'd like me to continue to wait, press 1.”

Repeating
Some information deserves to be repeated without having to ask the caller if she'd like to hear it again. Here are some common examples: (1) tracking numbers; (2) confirmation numbers; (3) anything short enough that could have already been replayed in the amount of time it took the system to ask the caller if she'd like to hear it again.

In situations where information is being summarized or recapped, it makes more sense to allow the caller to request it be repeated. A good example of this is transferring funds in a banking application. Once the transaction is complete and a confirmation number is provided, the system may recap that “$1000.00 was transferred from account ending in <1234> to account ending in <4566>.” The caller has stepped through the individual components already (providing an amount, a from account, and a to account), and the transfer has been confirmed. This is just a way of wrapping up the call, and the information that is provided isn't “new” information to the caller like a confirmation number would be. The caller knows how much she requested to transfer and she knows which accounts she's transferring between. The chance of needing that information repeated is less, whereas she can't predict the confirmation number and by the time she's asked to have it repeated, the IVR could have easily just played it twice: “Your confirmation number is <AB12345>. again, that's <AB12345>.”