December 1997

BY BOB VILSOET, AMERITECH

Integration of Interactive Voice Response (IVR) applications has come a long way. The integration of voice, data, and host database information on voice response units (VRU) has been around for quite some time now, and many of the hurdles have been tripped over, understood, and overcome. To ensure that IVR applications are fully addressing customers’ (and your company’s) needs, call center managers need to consider multiple issues, including: development platforms, integration trends, accommodating business issues, database integration, voice recognition, software configuration management, and application design concerns.

DEVELOPMENT PLATFORMS
Development platforms are getting much simpler to program. Originally, you needed a communications programmer to write a device-specific line driver to interface with your specific device. This typically meant writing an X.25 driver to communicate to a switch and an SNA 3270 communications program to interface to a host application and emulate agent activities with a programmatic interface. After the communications software was completed, a programmer would create the application and modify it when changes were needed. Companies using IVR technology were dependent upon the programmers to make the changes in a timely and accurate manner, and since systematic testing was never included in the development process, callers were often disconnected when transferred or were transferred to the wrong location with no way to get back without placing another call.

As vendors grew more experienced at creating voice response applications, they wrote code that enabled the call center manager (or a technical person within the call center) to modify the scripts after significant training. To calm the fear of programming from the purchaser of the equipment, vendors employed such euphemisms as “configuring the system” or “modifying the scripts.” Vendors covered much of the error condition handling more thoroughly in the underlying application. This resulted in a steadily increasing stream of revenue for vendors because they were now able to charge for the hardware, software, and initial application development, as well as training, technical support, and professional services.

Application programming has become much more efficient through the use of pulldown lists, icons, and logic. Programmers can use these tools to create an application relatively quickly, turning what used to be a time-consuming process into a relatively quick job. A new IVR application can now take the customer from a day to several weeks to develop, test, and verify — thus realizing a significant improvement in speed. Significant tools are available to help debug the script, and some IVRs have an online tool that graphically highlights the progress of the test call. However, your screen needs to be big enough, and you need to isolate the path on your screen. This is an excellent tool to speed development and testing of a script. Minimally, all IVRs have the ability to log messages into a log file to verify the path of the call. There are programmatic tools to help the developer trap and handle error conditions, which is a significant improvement over lacing the C program with “printf” statements.

INTEGRATION TRENDS
The trend of simplified application programming — which first occurred in call centers in the area of switch development — is paralleled in most technical environments. The switch routing algorithms and database updates are now done by the call center manager; this alleviates the dependency upon the IT staff’s schedule and resources, and offers the additional benefit of affording call center managers control over their own destiny. Other components following this trend are IVR and workstation applications, the latter enjoying perhaps a slight lead over CTI server applications.

Consolidated reporting is just at the beginning of this trend. Soon, consolidated reports will be created and maintained by call center personnel instead of relying on vendors and report development consultants. Professional services, aimed at assisting the development reports, will always be necessary for strategic reporting initiatives and planning, but not necessarily for implementing the actual reports.

No matter how much of the integration of any of these components is placed into the hands of call center personnel, there will still be the opportunity for vendors to lend their professional expertise. A call center’s technical solution often includes a multitude of components (these may include a switch, voice response, CTI, network, workstation application, and database and host integration) and more often than not the vendor is the only one who can tackle the potential problems. A vendor has people on the staff that have installed many systems, seen many different uses for the system, and spoken to numerous call center managers about how to use the system.

ACCOMMODATING BUSINESS ISSUES
High turnover in the call center causes changes to be made periodically to the databases within the IVR, or the databases that the IVR accesses. Although this is more of a procedural issue than a programmatic one, facilities need to be designed and implemented, and training must be done, so that call center personnel have the ability to easily modify the databases to incorporate changes. In the example of an insurance company, if an adjuster leaves his position, the database would

need to be modified quickly, so that assignments go to a different adjuster. The changes could be entered any time to the database but with an execution date and time that could be checked automatically by the VRU application. While this increases the complexity, the flexibility of the system is also increased. Mistakes can also occur when callers who use the telephone keypad to enter information do so incorrectly. Both the script and the applicat i o n n e e d t o b e patient and polite with incorrect data entry. Consider how you would route a caller after invalid data entries have occurred a number of times. For example, it may not be the best call flow to disconnect the call when it timed out twice in a row for five seconds, or when incorrect information is entered more than once. Development needs to be done in conjunction with the user because what is intuitive for a programmer is not always intuitive to a call center administrator and can certainly pose a hurdle to a caller.

DATABASE INTEGRATION
When integrating databases, there are a host of issues that need to be addressed. Among them are database licensing, data integrity, and performance.

Licensing
Data needs to be accessible from the database. Often, the initial lookup into the database fails because the licensing is not properly set up. This causes extra steps to be taken by the programmer during the coding stage of the application. How the data is accessed needs to be determined. Sometimes there are APIs that need to be used to gain access to data. Sometimes the VRU has to emulate an agent’s screen and enter requests. During the design phase of the implementation there is always the issue of whether to use the IVR’s API or another API. Decisions like this often come down to questions of technical ability, development lifecycles, and out-of-pocket costs.

Integrity
Data integrity needs to be maintained. Typically, with an SQL relational database, two programs, applications, or users cannot modify the same data record at the same time. How often the data gets updated must be understood. For example, if a bank’s host application updates data every night, but callers call in before the update is made to the database, incorrect information could be given to the caller regarding account balances.

Performance
Speed of the updates has its own idiosyncrasies. For example, should a message be played to the caller while the VRU is looking up information on a very slow network? Perhaps a commercial announcement should be made. But should the announcement be interruptible when the data comes back? Should the caller be subjected to long messages if data lookups don’t take as much time? These design questions need to be answered for the programmer to stay on schedule with the project.

VOICE RECOGNITION
Voice recognition logic is among the more interesting software algorithms, but the logic is fuzzy at best. The software must recognize words from people with different accents, pronunciations, dialects, and speech inflections. Although different algorithms and design methodologies exist in the marketplace, the basic premise is worth understanding. Each word that is spoken by the caller is broken down into digital information, with each syllable having its own distinct electronic pattern. Those patterns are matched against the patterns of syllables, and the level of accuracy is scored. The syllables are then put together to do a word match, and the highest score is most likely the word spoken by the caller. If there are multiple matches in the word database that pass the user configurable threshold value, then the caller receives a prompt requesting a clarification. If there is no match with a high enough score, the caller is prompted to input the information again, or another method to get to the information is attempted.

These voice prints can also be used for secure voice communications. It is far more accurate to verify that the same caller with the same voice inflections and accent speaks a password than it is for the software to verify that a caller is making a specific request. An application of this nature is valuable in the banking industry where you only want to give financial information out, or allow updates, or withdrawals. By using a voice print instead of a personal identification number (PIN), the opportunity for fraud is significantly reduced.

When sentences are requested of the caller, certain keywords are chosen. For example, a caller who wants to know their account balance could ask, “Can you tell me how much money there is in my account?” The system will find no matches on many of the words and discard them. However, the software will have matched on keywords such as “money” and “account.” The bank balance will then be returned to the caller. There are significant levels of software involved in any such application. There is an operating system, software that digitizes the voice, an underlying application that does word and syllable searches, database access software — preferably fast — and an application that handles the logic of the call flow. There are different voice and software companies in the industry that have specialized in certain subroutines, or areas of speech recognition. Each of these software programs has procedures that can be called to help simplify the applications development. As time goes by, and as the speech recognition software modules improve and the user interfaces are simplified, call center managers will be able to create, design, and write applications — tasks formerly handled by programmers.

In the future, we will likely see voice recognition software enable a voice response unit to completely emulate a live agent, have a conversation with the caller, and handle a significant number of inquiries, requests, and updates.

SOFTWARE CONFIGURATION MANAGEMENT
Programming an IVR application does not preclude software configuration management issues. Test applica-tions that can be executed while the production application is running must still be written as well as method and training applications. Different types of callers may need to be supported with different types of scripts. All of these possibilities must be maintained along with the base version of the system code provided by the vendor. When a new version of software is placed into production, there must be a backup process in case the new code does not work properly, or has an incorrect call flow or path.

APPLICATION DESIGN CONCERNS
Some items to consider when designing an IVR application include:

• Always let the caller press zero to talk to somebody.
• Find a way for more experienced users of the system to skip past longwinded explanations of the VRU.
• Be consistent on your use of commands:
• “For this, press 1,” or “Press 2 for this.”
• Never disconnect a caller — especially after the caller has been in queue for an extended period of time.
• Don’t ever transfer a caller into a queue that ends up in a busy signal.
• Transfer the call and the associated data to an agent. Do not make the caller repeat the information that was just entered on the IVR to the agent.
• Read the management reports to look for routing improvements, where most callers drop, and misdirected calls. For example, if transferring money from savings to checking is the most common activity, you may wish to put it on the main menu.
• Whether the transaction is email, Internet, or voice (telephone), the logic should be the same.
• Tell the caller how to get back up the IVR tree.

CONCLUSION
Engineers and developers of all types should listen to the comments from the users of a system. Software development, systems integration, or data communications should be done with the user in lockstep. One methodology to use for software development is prototyping. A system or application is mocked up so that the user has an idea of what the technology is going to look and feel like. Then, one-by-one, additional features are added, and the user tests and verifies them as they are completed. This eliminates surprises, assists the programmer during testing, obtains buy-in from users, and makes a usable working system available at all times.

Bob Vilsoet is director of systems integration for Ameritech’s Call Center Solutions. Ameritech serves millions of customers in 50 states and 40 countries. Ameritech provides a full range of communications services, including local and long-distance telephone, cellular, paging, security, monitoring, cable TV, electronic commerce, online services, and more. For more information, visit the company’s Web site at www.ameritech.com.