Download IC Cookbook - Intervoice

The Event Handler
Now that we have defined the initial error processes and messages for our menu, we need to define what
happens when the caller can’t get their menu selection right, even after three tries. We might want to transfer
the caller to a live agent, or perhaps verify that this customer has enough value to merit a live agent. Perhaps
we could send the caller to a separate speech input menu and prompt the caller to speak their choice, instead
of using the phone keypad for the selection.
No matter what we do to recover from multiple-menu errors, it is likely that we will want to define a similar
process for most of the menus in our application. In this recipe we only have one DTMF Menu, but in a large
application there can be dozens of menus. It would be nice if we could define a standard maximum-errorhandling process for all of the menus in an application, in one place. Otherwise, we would have to define this
process for each menu, which could clutter up a voice diagram significantly. Better yet, it would be great if IC
would provide one central place to put handlers for all kinds of commonly occurring events, not just errors. That
would keep our diagrams tidy, and make maintenance much easier.
IC has a solution for these issues, and it is called the event handler. Errors aren’t the only reason to call a
common handler routine, which is why we call it an event handler rather than an error handler. In our DTMF
Menu recipe, all of the events we want to catch are essentially multiple-error retry conditions. However, that is
only a few of the common events that might occur in an application, and we would like to centralize all of these
types of events in a common place. That place is the Event Handler.
Configuring the DTMF Menu Max Error Counters
Click on the DTMF Menu component’s Properties view > Events option (on the left). You should see four error
counters - Error, MaxNoMatch, MaxNoInput, and MaxErrors. Remember that these four specific parameters
are counters, not direct routine calls. They won’t do anything but count the occurrences of a specific error type,
until a maximum count is reached. However, when that count is reached, they will trigger a call to the event
handler that we select.
This section of our recipe will define how these counters work, and how to define the appropriate event handler
that is executed when a maximum count is reached. In subsequent sections we will describe how to set the
maximum counts for each counter, as well as how to configure the specific event handler that is called when
that maximum count is reached.
Here are the definitions of each counter:
MaxNoMatch- This counter increments each time the caller enters an option that is not a valid menu option. If
the caller enters 7 in the NWS recipe for example, that will increment the MaxNoMatch error count.
MaxNoInput- This counter increments each time the caller fails to enter a selection before the entry timer times
out. If a caller doesn’t respond to the menu prompt with any input, that event will increment the MaxNoInput
counter.
MaxErrors- This counter counts the sum of MaxNoMatch and MaxNoInput errors. Either type of error will
cause this counter to increment.
Error- This counter counts errors that are neither a MaxNoMatch nor MaxNoInput, error. These are typically
system or programming errors. For example, a TTS error, or a missing audio prompt file, will count as this type
of error. These kinds of errors are usually catastrophic, since it means that the system can’t play a specific
prompt. You won’t get to set a maximum error count for this condition. The max count for this condition is
forced to one, and you can’t change it. You will be able to select an event handler for this condition, however.
September 2013
Copyright © 2013 Convergys. All rights reserved.
77