The design question for this topic is whether to only use local counts of events such as noinput, nomatch, and requests for help to drive a call flow or to also keep some sort of count based on a caller's global experience.

All IVRs use local counts, where local means the events that happen in any given dialog step (this capability is built into VoiceXML). A typical practice is to treat noinput (no detection of speech or a key press) and nomatch (speech or key press not in the currently active grammar) as errors and, upon the occurrence of two or three errors in that instance of that dialog step, to move the caller somewhere else in the call flow (e.g., transfer to agent if the call center is open). Designers' treatment of events related to requesting help is more variable, from allowing unlimited requests for help to restricting callers to no more than two in a given dialog step.

Few applications use metrics based on global event counts to direct the call flow. This is not part of VoiceXML, so would be custom-coded for an application. We know of no published research on whether it is ever advantageous to track global counts or the conditions under which it might be favorable.

Focus on local error counts rather than global
Until there is more research published on this topic, it seems like a reasonable course of action for designers to focus on call flow direction based on local rather than global events. It currently isn't clear whether any benefit associated with global counts could compensate for the increased complexity and expense of the application.

Consider also a situation where there is a global max set. Let's say it's seven errors. The caller makes six errors in the first three questions but manages to get through them. She then answers several more questions easily on the first try. On the next question, an error occurs, triggering the global max and off she goes to an agent when she was progressing well and seeing some success, and probably willing to keep trying. To combat this, some systems have become as complex as to increase the counter on errors and decrease on successes. Again, you'd need pretty compelling data to undertake such a strategy.