Alpine Solutions, Inc.


	Voice Response Tips and Strategies Click on the following topics to discover useful tips and strategies for developing Interactive Voice Response applications. Know Your Audience Know the Purpose of the Application Use Navigation Aids in Complex Applications Use Data Capture to Improve the Application Uses for Hang-up and Transfer Detection? Error Handling and Alarms Use Background Processing when Appropriate Database Query Processing Generic Parameters Collecting Alphanumeric Responses Also see our Avoiding Common IVR Pitfalls page. Know Your Audience Design the application to the target audience. You have more freedom with employees than customers. Employees can be provided with training materials, thus prompts can be more concise. Experiment on employees with new technologies such as synthesized speech and speech recognition. If you expect callers to access the application frequently, provide shortcuts to commonly used functions of the application. Top Know the Purpose of the Application If the purpose of the IVR application is to offload use of live agents, don’t offer the caller the chance to speak with an agent at every prompt. Be sure to allow for live operator support for errors and other situations the application can't handle. Top Use Navigation Aids in Complex Applications If an application supports more than 3 levels of nesting, support a consistent touch-tone sequence that allows the caller to return to the main menu. As application complexity grows, callers can actually lose track of where they are in the application. Supporting a sequence such as M to return to the main menu allows callers to return to a central reference point. Don't inundate callers by repeating navigation aids over and over, or offering so many that the caller can't remember even one. Complex applications that have many levels of prompts and menus, should use the type ahead capability. Type ahead allows the user to enter a string of digits that satisfy multiple prompts without requiring the caller to listen to each individual prompt. Top Use Data Capture to Improve the Application* Developing an IVR application is usually an iterative effort. It is difficult to anticipate where callers may have difficulty with a complex application. Rather than taking complaints from callers, or worse, losing customers, incorporate reporting capabilities into your applications. Log features that are most commonly used, and make every effort to streamline them. Log where callers error out of the application, analyze the data and make improvements in areas that have the highest default rate. For applications that access large databases, legacy systems, or other external systems, it is important to track transaction query time. Log and monitor the elapsed time required to compile database and host transactions, and investigate if response time grows unexpectedly. This data may save you from extended outages. While capturing application data and performing the subsequent analysis requires additional resources, improvements made to the application as a result of these efforts can be well worth it. Top Hang-up and Transfer Detection? Callers can hang-up anytime during the course of a call. It is important to understand where in the application this occurs, and use the information to make improvements to the caller interface. For example, if callers frequently hanging up at a particular prompt, review the prompt wording. It may be confusing, or have insufficient instructions to the caller. Top Error Handling and Alarms Many applications that communicate with database servers or legacy host systems assume a sunny day scenario (i.e. communication links are always up, there is sufficient bandwidth available over the links, the mainframe is always up, database indexes are always correct, databases are never corrupt). Experienced developers code for these possibilities. Top Time-outs If an application accesses an external system such as a database or legacy system, transaction time-outs should be set according to user tolerance. For IVR applications, it is unlikely a caller will wait more than 30 seconds before hanging up, thus the maximum time-out duration should be 30 seconds or less. Top Enhance the User Wait Experience Most callers will state that any delay is unacceptable when waiting for a response. To reduce caller anxiety, provide music on hold or even a promotional message if the anticipated wait is more than a few seconds. Sometimes, even masking the transaction by playing a message will suffice. For example, while background processing a transaction request, play a message such as "Please wait a moment while we retrieve your account balance" will be enough to mask the query time. Top Alarms Proper use of thresholds and alarms can be a great benefit to operations and maintenance personnel. For example, if the application stores general information in a database record and the information becomes inaccessible, the application should generate an alarm that operations can act upon. Alarms can be as simple as an Email message to the system administrator, or as complex as an SMNP trap that is be displayed on a management console. Examples of events that should be alarmed are database and host query time-outs, no response from an external system, and critical function call errors. Alarm data should always include application name, date, time, alarm ID number, failing function, and applicable descriptive text. Top Use Background Processing Although supported by most IVR systems, many applications do not take advantage of background processing. Brief announcements are an excellent way to mask query time to a host or database. Playing a message such as "Please wait, while we lookup your account," in the background when the query is initiated shortens the caller's perceived notion of the overall response time. Top Database Query Processing One of the most common mistakes made when using databases is the incorrect use of indices which are used to speed database queries. For example, a 200,000 record employee database used in an application would be indexed on a unique field such as social security number, or employee ID. Rather than searching all 200,000 records sequentially for the specified employee, a time consuming resource intensive operation, an index allows nearly direct access to the employee record. Top Generic Parameters It is more flexible to store many application parameters or attributes in a database rather than direct specification in the application. For example, most prompts have parameters that specify time-out and retry values. If stored in a database, the values can be changed by simply updating the database table without requiring any code changes. Although the parameter table need be read only once at call initiation, it does imply some extra overhead. We have found that the benefits of minimizing code changes outweigh the minimal additional overhead. Top Alphanumeric Response Collection This is one of the more requested features that frankly, there is not a very good solution for. Alphabetic only responses are typically handled by two-digit touch-tone sequences. The most common examples are brokerage IVR applications that need to support caller input of stock symbols. The caller enter a 2 digit sequence for each letter (e.g. A is 21, B is 22, C is 23). This works fairly well with stocks and callers that are familiar with the data entry technique. It is imperative that a help message be provided with detailed instructions and examples of character entry. A disinterested or untrained caller population will have a very difficult time with the character entry technique, we recommend it be avoided unless absolutely necessary. What about speech recognition you might ask. Currently, speech recognition does a good job of recognizing numbers and limited word vocabularies, but is not suited to individual character recognition. The human ear has a difficult time distinguishing between individual letters such as "b" and "d," and speech recognition technologies have an equally difficult time. Vendors are hard at work on the problem, but the solution is still in the future. Top

Voice Response Tips and Strategies
Click on the following topics to discover useful tips and strategies for developing Interactive Voice Response applications.

Know Your Audience
Know the Purpose of the Application
Use Navigation Aids in Complex Applications
Use Data Capture to Improve the Application
Uses for Hang-up and Transfer Detection?
Error Handling and Alarms
Use Background Processing when Appropriate
Database Query Processing
Generic Parameters
Collecting Alphanumeric Responses

Also see our Avoiding Common IVR Pitfalls page.

Know Your Audience
Design the application to the target audience. You have more freedom with employees than customers. Employees can be provided with training materials, thus prompts can be more concise. Experiment on employees with new technologies such as synthesized speech and speech recognition. If you expect callers to access the application frequently, provide shortcuts to commonly used functions of the application.
Top

Know the Purpose of the Application
If the purpose of the IVR application is to offload use of live agents, don’t offer the caller the chance to speak with an agent at every prompt. Be sure to allow for live operator support for errors and other situations the application can't handle.
Top

Use Navigation Aids in Complex Applications
If an application supports more than 3 levels of nesting, support a consistent touch-tone sequence that allows the caller to return to the main menu. As application complexity grows, callers can actually lose track of where they are in the application. Supporting a sequence such as *M to return to the main menu allows callers to return to a central reference point. Don't inundate callers by repeating navigation aids over and over, or offering so many that the caller can't remember even one.

Complex applications that have many levels of prompts and menus, should use the type ahead capability. Type ahead allows the user to enter a string of digits that satisfy multiple prompts without requiring the caller to listen to each individual prompt.
Top

Use Data Capture to Improve the Application
Developing an IVR application is usually an iterative effort. It is difficult to anticipate where callers may have difficulty with a complex application. Rather than taking complaints from callers, or worse, losing customers, incorporate reporting capabilities into your applications. Log features that are most commonly used, and make every effort to streamline them. Log where callers error out of the application, analyze the data and make improvements in areas that have the highest default rate.

For applications that access large databases, legacy systems, or other external systems, it is important to track transaction query time. Log and monitor the elapsed time required to compile database and host transactions, and investigate if response time grows unexpectedly. This data may save you from extended outages.

While capturing application data and performing the subsequent analysis requires additional resources, improvements made to the application as a result of these efforts can be well worth it.
Top

Hang-up and Transfer Detection?
Callers can hang-up anytime during the course of a call. It is important to understand where in the application this occurs, and use the information to make improvements to the caller interface. For example, if callers frequently hanging up at a particular prompt, review the prompt wording. It may be confusing, or have insufficient instructions to the caller.
Top

Error Handling and Alarms
Many applications that communicate with database servers or legacy host systems assume a sunny day scenario (i.e. communication links are always up, there is sufficient bandwidth available over the links, the mainframe is always up, database indexes are always correct, databases are never corrupt). Experienced developers code for these possibilities.
Top

Time-outs
If an application accesses an external system such as a database or legacy system, transaction time-outs should be set according to user tolerance. For IVR applications, it is unlikely a caller will wait more than 30 seconds before hanging up, thus the maximum time-out duration should be 30 seconds or less.
Top

Enhance the User Wait Experience
Most callers will state that any delay is unacceptable when waiting for a response. To reduce caller anxiety, provide music on hold or even a promotional message if the anticipated wait is more than a few seconds. Sometimes, even masking the transaction by playing a message will suffice. For example, while background processing a transaction request, play a message such as "Please wait a moment while we retrieve your account balance" will be enough to mask the query time.
Top

Alarms
Proper use of thresholds and alarms can be a great benefit to operations and maintenance personnel. For example, if the application stores general information in a database record and the information becomes inaccessible, the application should generate an alarm that operations can act upon. Alarms can be as simple as an Email message to the system administrator, or as complex as an SMNP trap that is be displayed on a management console. Examples of events that should be alarmed are database and host query time-outs, no response from an external system, and critical function call errors. Alarm data should always include application name, date, time, alarm ID number, failing function, and applicable descriptive text.
Top

Use Background Processing
Although supported by most IVR systems, many applications do not take advantage of background processing. Brief announcements are an excellent way to mask query time to a host or database. Playing a message such as "Please wait, while we lookup your account," in the background when the query is initiated shortens the caller's perceived notion of the overall response time.
Top

Database Query Processing
One of the most common mistakes made when using databases is the incorrect use of indices which are used to speed database queries. For example, a 200,000 record employee database used in an application would be indexed on a unique field such as social security number, or employee ID. Rather than searching all 200,000 records sequentially for the specified employee, a time consuming resource intensive operation, an index allows nearly direct access to the employee record.
Top

Generic Parameters
It is more flexible to store many application parameters or attributes in a database rather than direct specification in the application. For example, most prompts have parameters that specify time-out and retry values. If stored in a database, the values can be changed by simply updating the database table without requiring any code changes. Although the parameter table need be read only once at call initiation, it does imply some extra overhead. We have found that the benefits of minimizing code changes outweigh the minimal additional overhead.
Top

Alphanumeric Response Collection
This is one of the more requested features that frankly, there is not a very good solution for. Alphabetic only responses are typically handled by two-digit touch-tone sequences. The most common examples are brokerage IVR applications that need to support caller input of stock symbols. The caller enter a 2 digit sequence for each letter (e.g. A is 21, B is 22, C is 23). This works fairly well with stocks and callers that are familiar with the data entry technique. It is imperative that a help message be provided with detailed instructions and examples of character entry. A disinterested or untrained caller population will have a very difficult time with the character entry technique, we recommend it be avoided unless absolutely necessary.

What about speech recognition you might ask. Currently, speech recognition does a good job of recognizing numbers and limited word vocabularies, but is not suited to individual character recognition. The human ear has a difficult time distinguishing between individual letters such as "b" and "d," and speech recognition technologies have an equally difficult time. Vendors are hard at work on the problem, but the solution is still in the future.
Top