October 1997

IVR And The World Wide Web - Separate Worlds?

BY WAYNE JOSTRAND

Every business wants to offer quality customer service at a reasonable cost. An Interactive Voice Response (IVR) system emulates the actions of a customer service representative accessing information from a computer terminal and speaking the requested information back to a caller over the telephone. The IVR system automates the information retrieval and delivery processes, providing callers with the option to instantly access information without the need to interact with a service representative.

IVR systems are now a near-universal business tool. Whether you’re dialing an airline’s toll-free number for a flight’s arrival time, checking your bank account balance from your cellular phone or confirming a stock’s closing price by phone with your brokerage firm, you are probably using an IVR system. Many organizations have already implemented IVR systems to provide easily accessible and easy-touse transaction services.

What these organizations — and others who will be implementing IVR in the future — need to recognize are that some of these systems also have a role to play in the move to Internet- and WWWbased transaction services. Analysts at Hambrech & Quist have estimated that yearly transactions over the Internet could total 50 billion by the year 2000.

Typically, WWW applications have been new applications, not duplicating or replacing existing IVR applications. In most organizations, IVR and WWW applications are two separate environments (Figure 1).

Organizations have reason to Webenable existing IVR applications, such as to provide existing services to customers via the WWW, or to take advantage of its interactivity.

However, by developing a WWW application from scratch to carry out the functions of the existing applications, organizations are essentially duplicating the services provided on the IVR application. Aside from the obvious duplication of resources, there are other disadvantages to this approach. There are two systems to develop, maintain, document, and sup-port.support. The two systems may use different technologies and, in turn, requiredifferent operation staffs. Lastly, the company may risk inconsistent results presented to the customer based on method of access employed.

AN INTEGRATED APPROACH
There are major advantages to integrating IVR and the WWW customer service applications. Inherently, the only fundamental difference between IVR and WWW applications is the user interface or presentation layer. Existing IVR systems already have the interfaces to access the mainframe and/or server databases that contain the data required to complete these transactions. They also have application script programs in place that drive the transaction services. These application programs provide the logic to capture information from callers, interface, and interact with other data center systems and to process, package, and present information back to the caller. There are parallels for each of these within the Internet-based transaction service model.

A logical path to interactive transaction services on the WWW might be to add these services to the IVR system they already have in place. The IVR system then performs interactive transactions via two channels — telephone and Internet. Tools are available to provide this capability. In this configuration, the IVR system sits between the Internet and the database, controlling access to information and transactions (Figure 2). An IVR application is inherently interactive as the system response is dependent on the customer’s response.

Typically, the WWW presents users with static pages, and everyone sees the same text and graphics. Building static HTML Web pages is relatively easy, and is getting easier all the time with new and improved authoring tools. Constructing Web services that perform transaction processing (i.e., capture and/or delivery of information unique to an individual or account) is not so straightforward.

Striking Similarities
A WWW “caller” accesses the transaction services of the system through normal browser interactions. This is equivalent to using a touch-tone telephone to access the system. Once connected to the service, the session continues as in any WWW interaction.

These WWW operations are nearly structurally identical to those of a caller connecting to an IVR system by phone and hearing the organization’s service greeting message followed by a voice menu of service choices. The IVR caller makes a service selection and enters data by touch-tone keypad entry. The Internet caller makes service selections and enters data by a combination of targeted mouse clicks and keyboard entry. IVR callers receive output in the form of voice messages. Internet callers receive output as a combination of graphical images and text.

Many existing applications can be converted to Web access with only the effort of authoring the HTML documents corresponding to each transaction step. In this case, there can be a one-toone correspondence between IVR and the WWW prompts and responses. However, modifications can be made easily, without changing the application. Enhancements to applications might include grouping successive DTMF or voice input values into multiple fields on a single HTML page for efficiency. Once the basics are mastered, new application branches can be added, which are used only by Internet customers.

Most obviously, a WWW application can support more complex data entry and data responses than the voice interface, and therefore, a more complex customer interaction can be developed. What is less obvious is that the user’s navigation through the transaction is very different. While voice-based services are normally menu driven and offer only a welldefined range of valid choices at any point in the process, navigation by the user in a WWW transaction can be nearly random.

Of URLs And Such
To understand this point, it is necessary to understand that processing on the Web depends entirely on the Universal Resource Locator (URL). By specifying a URL, a user directs input to any accessible node worldwide, and each input can be completely independent of the previous entry. While the user will probably follow an orderly path to use a service, it’s perfectly possible for that user to pause in the middle of a transaction. The user may visit a news group, search for some related data, and then return after hours (or even days) to the next step in the transaction, simply by clicking an item on a browser pull-down list. This kind of behavior might be accidental, or it might represent new and productive ways for customers to take advantage of the power of the Internet. Whatever the reasons may be, software tools designed for Internet transaction processing must be able to support processing in this undisciplined environment.

Therefore, one of the most important responsibilities of a WWW application is to manage the context of a transaction, since the user information is otherwise static. This means that, without the capabilities of specific Internet software tools, each user input has essen tially no history of the inputs and outputs which have gone on before. Without such a history, there is no way to manage a complex transaction. Certain things, which are taken for granted in a voice response application, must be managed differently by the Internet software tool. For example, the usual time-out procedures while waiting for DTMF or voice input are intercepted and canceled by the Internet software tool, since the user may allow a long delay before entering information.

Only a total call timer remains in effect, and this is used for the purpose of deciding when a given user context should be treated as inactive. A user might enter inputs in an incorrect order, or might return to a transaction in midstream after a very long delay. The Internet software tool monitors for URLs that are stale or out of order, intercepts them, and returns table-driven indications to the user that the transaction needs to be restarted.

The biggest limitation of the Internet today, from a business standpoint, is that most of its content is canned. That means that the text and graphics seen are the same for everyone. The content is not customized for any user. The WWW will grow at an even quicker pace when personalized transaction services become widely available. There are a number of obstacles to the wide deployment of transaction services on the Internet and the WWW. One of the biggest has to do with security.

SECURITY
There is one key issue that must be addressed if you plan to conduct business transactions via the Internet: secure transmission of information.

Security concerns have been exacerbated by a few high-profile security breaches that have shaken the already fragile level of confidence the general public has in the Internet. To combat such breaches, Internet users and service providers are working to develop, agree upon, and adopt data encryption standards at both the WWW protocol layer (HTTP) and at higher levels. VISA, which has been aligned with Microsoft on the development of secure transaction technology for the Internet, and MasterCard, aligned in a similar effort with Netscape and IBM, have put their competitive differences aside and agreed to a common universal specification.

One approach to security is to work with an organization’s security infrastructure. The integrated IVR/WWW application can be viewed as working behind the existing infrastructure. In the environment illustrated in Figure 3, the application neither adds nor reduces security exposure.

CONCLUSION
As time goes on, those Internet and WWW services that provide tailored information and transaction services for individuals will increasingly be recognized as the most valuable to customers. Businesses and other organizations will come to see that they can improve the level of service they offer to a rapidly growing segment of their customer or client base, in a cost-effective fashion, by providing these interactive transaction services. For many, the quickest and most cost-effective route will be to build these services into their existing IVR systems, which already provide the capabilities, albeit with a different user interface. For many of those not currently providing IVR services, it makes sense to build an integrated IVR/WWW application on an IVR platform with its proven track record in supporting high-volume interactive transaction processing systems with connectivity to both legacy and client/server databases.

Wayne Jostrand is currently the Executive Director of Product Management at Periphonics Corporation, a leading supplier of high-performance voice processing systems for Interactive Voice Response (IVR). Periphonics is committed to providing industries with cuttingedge technologies like Internet Access, Large Vocabulary Speech Recognition, and Natural Language Understanding. For more information, contact Periphonics at 1-800-877-8269 or visit the company’s Web site at www.peri.com.