When asking the caller for input, issues of various types may arise. The caller, who has not understood the question, may not say anything as a result. Or the caller may answer, but the response may be something that the application cannot understand. This chapter describes how to best handle such cases from a Voice User Interface (VUI) point of view, and how VoiceObjects supports this.

Further information on event handling with respect to a high-quality Voice User Interface design can be found in Appendix A – Voice User Interface Design.

i8Note: This chapter only deals with event handling mechanisms for the voice channel.

Event Handling Mechanism

The standard mechanism for handling usage problems as well as other issues such as loss of back-end connectivity is event handling. Event handling allows designers to define actions (most often, playing a certain prompt) to take place when a certain event occurs. Typical event handling definitions would be to play I didn't hear you, or some randomized variant, in the case of a No Input event, or I didn't understand you, or some randomized variant, in the case of a No Match event. The prompt randomization enhances the naturalness of the dialog.

 

To complement the generic No Input and No Match system feedback, context-sensitive prompts will provide additional guidance to the caller, e.g. “To access your account, please provide your account number one digit at a time”. This is best accomplished by combining event handling with reprompting.

For detailed information on all fields within the Event Handling section see Event Handling in the Object Reference.

Reprompting

Reprompting provides an extended mechanism for dealing with input-related issues. It separates the generic portion, which is covered by event handling, from the context-sensitive portion, which is handled within the reprompting output.

As an event is activated, the appropriate event handling definition is processed first. Depending on the design, each event occurrence level (i.e. how often the event has been activated in succession) may lead to a different output or a different action. If the continuation mode in the event handling is set to Reprompt, then, after the event handling definition has been processed, the appropriate reprompt plays. This, again, may depend on the event occurrence level, as shown in the example below.

Reprompting is defined in the Initial or Event Reprompt sections in the output definitions of various object editors.
The example screenshots show the Input Request section in the Input editor.

 

Instead of configuring the initial or reprompt output as an embedded definition within the respective object, an existing Output object can be referenced by over-linking the embedded definition.
Note that when referencing an Output object for reprompting, any Output items with occurrence level Always and Only once in this linked Output object are ignored.

The Initial section defines the initial request prompt that is played to the caller as the respective object is processed.

 

In this example, the caller always hears “Please enter your account number” when entering this specific input.

In following VUI best practices for cases when the prompt will be heard often, it is recommended to make use of the built-in random prompting capabilities of VoiceObjects and to provide multiple variants for each initial output. This will make for a more natural caller experience by reducing the robotic effect of a single, persistently repeated prompt.

 

For more details and additional options, refer to the Output object in the Object Reference.

The Event Reprompt section defines the prompts that are played to the caller after successive events.

 

The Occurrence field defines on which occurrence level the respective prompt is played. In the example given, the prompt “Please say your ten-digit account number one digit at a time, or enter it on your telephone keypad” is played as the first reprompting and the other, even more descriptive prompt is played starting with the second reprompting and thereafter. It is typically a good idea to provide more and more detailed reprompts for increasing occurrence levels. The fact that the caller activates No Input or No Match events indicates that he or she is having trouble, so context-sensitive help that anticipates the kinds of problems callers may be having should be provided.

Of course, random prompting is also available for reprompting, as are the language layer and custom layers. For more details, refer to the Output object in the Object Reference.

Note that in order for event handling and reprompting to work together, it is important that the continuation mode in the respective event handling definition is set to Reprompt:

 

Reprompting is available in the Input, Menu, Confirmation and Hyperlink object.

Inheritance

Reprompting combines the power of inheritance for general event handling with the ability to locally define context-sensitive event handling. General event handling, which is independent of the specific place in the dialog, can be defined globally and, by means of inheritance, is then automatically available throughout the entire dialog.

Context-sensitive help, guiding the caller on how to interact with the respective object, is best defined within the local reprompt output, thus making it easy for developers to keep initial prompts and reprompts consistent.

For more information on inheritance also see Chapter 1 – Application Design – The Modular Concept.

Input Mode-Specific No Match Handling

The No Match event occurs when the caller says something or presses DTMF keys that do not match the active grammars. In an application that allows both voice and DTMF input, the designer may want to define different No Match handlers, depending on the mode used for the last input. Consider the following example:

Object - Caller	Call Flow
	Please enter or say your PIN.
Caller	[ spoken ] One five three.
	[ No Match (Voice): ] I’m sorry, I didn’t get what you said. Please say your PIN again, or enter it on your phone keypad.
Caller	[ DTMF: ] 1 5 3
	[ No Match (DTMF): ] Sorry, the number you typed in is not a valid PIN. Please enter your four-digit PIN.
Caller	1 5 3 4

 

In this example, the output played for the No Match events depends on the input mode used. In the case of No Match Voice, the application plays an appropriate prompt for invalid voice input (“I’m sorry, I didn’t get what you said”), whereas for No Match DTMF, the application addresses invalid DTMF input (“Sorry, the number you typed in is not a valid PIN”).

You can define input mode-specific No Match handlers by selecting ASR – No Match (DTMF) or ASR – No Match (Voice) in the Event Type field of an event handling item. See Event Handling in the Object Reference for more information on the definition of event handlers.

If you make use of the above-mentioned event handlers, note that there is only one combined counter for all types of No Match: ASR – No Match, ASR – No Match (Voice), and ASR – No Match (DTMF). Each of the three event types increases the occurrence counter for No Match by 1, regardless of the input mode.
Example: Define separate No Match handlers for voice and DTMF input both for occurrence level 1 and 2. The caller first makes an invalid voice input followed by an invalid DTMF input. The following event handlers are then activated: the ASR – No Match (Voice) handler for level 1, followed by the ASR – No Match (DTMF) handler for level 2.

The ASR – No Match handler is a more general one, encompassing both input modes and their associated events, ASR – No Match (Voice) and ASR – No Match (DTMF). If either one of the more specific handlers is missing in an event handling definition, especially with inherited handlers coming from parent objects, the ASR – No Match handler covers the respective missing definition.
Example: define an ASR – No Match handler in a Module object and an ASR – No Match (Voice) handler in an Input object, which is part of the Module object’s sequence. In the Input object, the ASR – No Match (DTMF) definition is inherited from the more general ASR – No Match handler coming from the Module object, since the Input object lacks a definition for ASR – No Match (DTMF). The ASR – No Match (Voice) is taken from the local Input object definition.

8  Caution: The support for input mode-specific No Match handlers depends on the media platform. On those platforms that do not support this feature, the ASR – No Match (DTMF) handlers are ignored, and the ASR – No Match (Voice) handler is used also for invalid DTMF input.