Handling Global NoInput/NoMatch Event Counters

1 Introduction

In some IVR service implementations, it is required to keep track of NoMatch and NoInput counters both globally and locally. The basic idea is that a caller is allowed only a certain number of input errors in a call before he is automatically transferred to an agent; the obvious motivation is to prevent frustration.

A typical design requirement might read like this:

In any given call, the caller will be transferred to an agent / disconnected / [...] in case

• Condition 1: he/she triggers 3 NoMatch or NoInput events within a given input state, or
• Condition 2: he/she triggers 5 NoMatch or NoInput events within the entire call.

This article shows best practices around implementing this kind of requirement in VoiceObjects. In the last section, we will extend this requirement by combining counters relating to NoInput and NoMatch events with custom counters relating to failed validation and declined confirmation steps.

2 The ASR - Invalid Answer Limit Event

Let's start by tackling the requirement outlined in the Introduction, defined by a combination of Conditions 1 and 2.

Condition 1 works within the scope of an input state, so it is easy to implement using the ASR - Invalid Answer Limit event handler in VoiceObjects, configured with Occurrence level 3:



This ASR - Invalid Answer Limit event handler is triggered when the caller causes 3 NoMatch or NoInput events in a given input state. (Note that this is different from the ASR - NoInput/Match handler that works as a shortcut representing two identical event handlers for NoMatch and NoInput events - which are counted separately.)

The ASR - Invalid Answer Limit event handler usually defined only once on the top-level Module object and is inherited by all Input, Menu, ? objects in the call flow. (Note how the Finish Tasks field is set to All, causing any Business Task that might be active at this point to be closed and marked as Incomplete / Recognition Error.)

3 Working with Global Event Counters

Now, with Condition 2 things get a little more interesting because it involves counting events both on a local (per input state) and on a global (per session) level.

The key ingredients for the solution of this implementation task are these:

• The ability to define the Occurrence filter in the Event handler dynamically, by linking in an Expression object. So, the ASR - Invalid Answer Limit event handler's Occurrence filter may be dynamically set to 3, 2, or 1, depending on the prior event history in the session.
• With the Expression EVENTCOUNTER("noinput", "global"), we can get hold of the number of times NoInput events have occurred during the dialog so up to this point. Of course it works just the same for "nomatch" events.

And this is our solution strategy:

Whenever an input state is activated, we first determine how many invalid attempts are still allowed for the caller, and use that for the Occurrence filter for the ASR - Invalid Answer Limit event counter.

To understand this in detail, let's consider a concrete scenario:

1. When the call starts, the ASR - Invalid Answer Limit is 3 (only Condition 1 is relevant).
2. Let's say the caller triggers two events (NoMatch or NoInput) in this first input state before making a valid input in the third turn. In the second input state, the ASR - Invalid Answer Limit still needs to be set to 3 because the global counter is now down from 5 to 3 - so Conditions 1 and Conditions 2 have identical effect.
3. Consider the caller provokes another NoMatch in this second input state (so the total count is now up to 3) before moving on to the third input state. There, the Occurrence filter of the ASR - Invalid Answer Limit event handler must be set to 2 - because now Condition 2 only allows for another 5-3=2 attempts, overruling Condition 1.

In any case, the ASR - Invalid Answer Counter must be set to either the (static) local limit (Condition 1), or to the (dynamic) limit derived from the session history (Condition 2) - whatever is the smaller value.

This algorithm is reflected by this expression:

Occurrence level for "ASR - Invalid Answer Limit" := MIN ( MaxLocalErrors, MaxGlobalErrors - GlobalSumOfNoMatchAndNoInputEvents )

The key expression that combines Conditions 1 and 2, building the required minimum value, is this one:

To get hold of the combined sum of global NoMatch and NoInput events (referred to as GlobalSumOfNoMatchAndNoInputEvents in the formula above), we simply use the SUM expression:

SUM(Global NoMatch count, Global NoInput count)

And this is how the Occurrence filter in our ASR - Invalid Answer Limit event handler now looks like in the main module:



For a full implementation sample, download the first sample application and load it into an empty VoiceObjects project. It contains a sample service with a central Module object with consecutive, simplistic Input objects: The caller can input "1", "2", or "3" in each input state, either via speech or via DTMF.

Apart from the ASR - Invalid Answer Limit event handler, global event handlers for NoInput (1) and NoMatch(1) are defined in this sample application. Note that these could of course be overridden with context sensitive reprompts on the level of the individual dialog components.

4 Combining Custom Error Counters With NoInput/NoMatch Counters

Now, let's up the ante. Consider this requirement:

In any given call, the caller will be transferred to an agent / disconnected / [?] in case

• 'Condition 1:' he/she makes 3 mistakes in a given input state, or
• 'Condition 2:' he/she makes 5 mistakes within the entire call

where a "mistake" can now be either

• A NoInput event,
• a NoMatch event,
• a failed validation of the caller input, or
• declined caller confirmation in a subsequent Confirmation step.

Examples for failed validation of caller input include an invalid credit card number, or a payment amount that exceeds the caller's credit limit.

The solution is pretty simple: First, we introduce a new variable Global Custom Error Count to keep track of failed validation attempts. It is manually incremented in the call flow whenever caller input validation (outside of an Input object) fails.

Now, we can slightly extend the approach described in the previous section. The decisive difference is that when we check the global error count, we need to add in our new custom counter:



You may want to inspect the second sample application which is a simple extension of the first one that we discussed above. It adds a Loop around the first input state. The grammar still allows to enter "1", "2", or "3", but this time, the value "1" will not pass validation in the Caller input invalid?, the global error counter will be incremented accordingly, and the caller will be re-prompted: