One of the most important steps in planning a good speech application is to plan for any potential problem and error condition you can think of and to include error handlers that can deal with these issues. For example, how should the system respond when one of these problem situations arises?
Technical or hardware limitations. What if the caller does not have a touchtone telephone? How does your system respond to TTY or TDD requests?
Accessibility for callers with physical limitations. Have you allowed for the extra time it can take for callers with physical handicaps or other limitations?
Language limitations. Is it likely that a caller will need to interact using a different language than the primary language? Do you have the necessary Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) servers and software to accommodate them?
Personal preferences. Have you allowed for the personal preferences of your callers? Some people would rather interact with the system verbally, while others can prefer to use touchtone, or Dual-tone multi-frequency (DTMF) , responses. Other people prefer to interact with a live attendant no matter how good your Interactive Voice Response (IVR) speech application is. How easy is it for such users to get to a live attendant?
If an application encounters an error that is not handled by its own error handlers, or if an application cannot be started due to problems with the application server or the speech servers, Experience Portal uses the error handlers installed on the MPP server. In addition to designing the speech applications, you should also design the error handlers that Experience Portal uses in these cases.
For example, you want your default event handler to:
Play a prompt explaining that there was a problem and that the customer is being redirected to an agent immediately.
Transfer the call to a special number reserved for such issues.
A call coming in on this special number alerts the agent that the caller has encountered and error in Experience Portal, and that the agent should find out what the customer was doing when the error occurred. The call center can then track these exceptions and fix areas that encounter frequent problems.
For more information, see Experience Portal event handlers.
