August 1999

Bridging The Gap Between Call Centers And The Web

STAN VESTAL, QUINTUS CORPORATION

Last December, I ordered a bestseller from an online book company. The book was a gift for a relative, and I wanted to have it sent directly to her home in north Kansas so it would be delivered by the time my wife and I arrived there for Christmas.

It was a simple transaction — until a crashed laptop and a snowstorm intervened. Two days before Christmas, we found ourselves stranded at a motel somewhere in Kansas, unsure whether or not the order would be delivered in time. I tried calling the bookseller — finding a telephone number for the customer service center was an adventure in itself — only to discover that the company was unable to help me because I did not know my order tracking number. Unfortunately, the number I needed was among the data casualties on my crashed disk. The book ultimately arrived on time, but not because of my futile efforts to follow up on its whereabouts.

My experience was not unique. In fact, at the end of the last year’s holiday season, television programming was awash with feature stories on the benefits and challenges of Web-based purchasing. But nearly all of the stories missed the point: The issue is not about how companies will do business over the Internet. The real issue, for today and the foreseeable future, is how companies will transact business across a combination of communications media, such as the Web, telephone and fax.

The truth is, using a combination of media to conduct a single transaction offers convenience for the customer, but a potential nightmare for the call center. Delivering consistent service and keeping track of transactions that flow across the phone and Web, for example, pushes most call centers far beyond their telephone-based parameters for architecture, staffing and workflow. Not only are most call centers not equipped to do it, they don’t know how to do it.

For many businesses, the strain is already apparent. Although companies may recognize that they need to prepare their call centers for an expanded role, the task is not straightforward. How do you plan your call center investments if you cannot possibly imagine the way your goods and services will be offered, or what combination of communications media you will need in the future?

The Vision
It’s impossible to plan without having a vision of what you want. The vision for a multimedia call center or contact center revolves around several fundamental characteristics:

• A scalable architecture that adapts to changing customer/enterprise communication needs without requiring massive infrastructure changes,
• Connectivity to many (and changing) media types,
• A common repository for coordinating data flow across all media,
• Functionality for delivering personalized service across all media,
• A platform for integrating business-specific applications, and
• Underlying technology for administration and reporting.

How would this contact center work? Let’s follow an inbound transaction from start to finish.

First stop. A customer visits your Web site and finds something of interest. In moving through the pages, the customer clicks on your “contact us” button.

• Contact record is created.
• Contact record is updated with customer activity and location.

Second stop. The Web server routes the contact to the site/system responsible for personalizing the transaction. The personalization engine looks in the contact record to determine the customer’s profile and recent transaction history. Further interrogation of the enterprise databases is performed, with an attempt to “match” the customer with stored records of previous customers. A match is found.

• Contact record is routed to first entry point.
• Customer is matched to his/her record of previous contacts in the database.

Third stop. Based on customer profile and likely activity, agents with the appropriate skills are identified and their availability is determined. An agent is selected and the routing process continues.

• Available agent list, sorted by skills, is checked.
• When one is found, the location is determined, and the contact record is passed to that location.
• Depending on media type, the agent receives “screen pop,” “Web page pop” or zip tone in his/her headset.
• Information from the contact record is displayed as appropriate, and the record is updated to reflect connection with an agent.

Fourth stop. The agent asks, “May I help you?” and begins serving the customer. The agent is aware of all previous activity since the data repository contains a record of each previous contact with the customer, including the communications medium involved. The happy customer signs off.

l The contact record is updated with this most recent activity.
l The record is archived in the repository, to be available for next contact.
l Agent is marked as “available.”

Although the process seems perfectly logical and is exactly what customers should expect from any call center, it is not all that common. Let’s examine the technical components that are required.

Technology Requirements
The key technologies that make our scenario possible are:

1. A common data record containing a history of all contacts,
2. A repository for these data records, available for searching by any process in the contact center,
3. A personalization engine capable of routing based on skills, customer profile, and customer intent,
4. Consistent and compatible connectors to any media type, having access to all the features of the system,
5. Business-specific applications.

The technical components have a variety of characteristics:

A common data record containing all contacts. This data element is the “clean slate” that exists at the beginning of a contact. It is the active repository of all data necessary to process the contact and is archived at the end of the transaction to provide tracking and reporting information. Some of its characteristics should include easy access, simple format, extensibility, availability across the WAN and the ability to synchronize agents and contacts.

A repository for these data records. There can, of course, be many data repositories, each suited to a specific purpose. For example, a cached version of the repository will be needed for rapid searching during the contact routing process, or for reconstructing a contact in the event of system failure. An archived version, complete with relationships to other customer and enterprise attributes, will be needed, logically in a commercial database format (ODBC, SQL-accessible). A filtered version, with specifics relevant to the enterprise reporting needs, would be available to reporting tools, both interactive and batch-repetitive. Links to the enterprise legacy databases will be required to allow post-contact updates to be made. All the repositories should either make use of commercial database management tools, or provide administrative and management tools as part of their installation.

A personalization engine capable of routing based on skills, customer profile and customer intent. The personalization engine will need hooks into the repositories above, in addition to knowledge of system resources, to be able to answer such questions as, “Is the agent available?” or “Where on the network will I find the appropriate database?” The connectivity from this engine to other components in the environment (PBX, ACD, IVR, agent desktops, etc.) should be consistently handled. The engine must have failure modes for graceful degradation to allow some form of routing to occur, regardless of the failure of any individual system or component. Further, the contact center managers must be able to easily modify the behavior of the engine by building new routing instructions that implement enterprise routing policy. Ideally, this task should be relatively simple, such as via a “drag and drop” capability.

Connectors to any media type. The key to building a smoothly functioning, scalable and competent contact center is the ability to connect to any device, any package, any system, and conveniently share data and results. One of the most complex points of connectivity is typically the communications medium. Each switch vendor invents its own protocol (ASAI Callvisor, Application Bridge, Meridian Link, etc.), each IVR vendor defines a new scripting language and development methodology, and so on. Most CTI vendors are capable of connecting to multiple switch types; several have convenient IVR interfaces, but few extend across other media, such as Web chat, e-mail streams, fax and the like. Look for those who provide open APIs and have developed working relationships with non-telephony media providers. Examine their technology. If the vendor does not have the desired media link off-the-shelf, how difficult will it be to add it? How much time is involved? These key questions will give you insight into the internal architecture and its extensibility.

Availability of applications and ease of integration. One can hazard a guess that no two contact centers are identical. Typically, the area of differentiation is the actual service application in use. These range from dumb-terminal interfaces with home-grown software to the most complex front-office applications imaginable. The key is not, “Does my vendor have the interface off the shelf?” Instead, focus on how long will it take you (or your vendor) to integrate your applications. A variety of interface methodologies is required (e.g., DDE, OLE, ActiveX, Java), along with an open API, a collection of tools to aid the integration, easy access to data collected and needed throughout the contact center, and available training and support during and after the integration.

If you’ve detected a decidedly architectural bent to my suggestions, you are correct: In my experience, difficulties in call center integration most often come not from the shortfall of features in the basic products in use, but in the difficulty of making multiple products work cohesively. That cohesiveness speaks directly to the quality of the architectural vision of the “glue” vendor in the contact center.

Preparing For Convergence
I would be delighted if the “big bang” theory of contact center integration — flip the switch and go on vacation — actually produced usable contact centers. It’s not a likely scenario in the real world, no matter what vendors tell you. A more likely plan for establishing Web-enabled call centers involves a phased implementation, with incremental steps.

Phase 1 — Separate, but equal. At this point, the telephony environment is in place and functioning, the Web environment is in place and processing transactions, but there is a limited interface between the two. (Note that this implies a “Phase 0,” which is to install and bring up those environments as separate entities, if they are not already in place.) What we hope to accomplish during Phase 1 is the design of a message for communication between — or among — the multiple worlds (silos of technology). The best method for doing this involves thinking back to the technology components above. Develop a mechanism to pass the contact data record between silos. In this way, you will have the means to move arbitrarily complex information between the major system components. What you do with that information is largely up to the silos, and can be worked out in later phases. For now, concentrate on getting the messages moving around. Note that there may be multiple, independent applications on the contact center agent’s desktop at this point, with lots of screens popping and shrinking. This is not an optimal way of working, but agents can be trained somewhat independently. And the evolution required later is gentle.

Phase 2 — Desktop integration. Here, we focus on the agent desktop and the front-office application. The goal is to minimize unnecessary screen flashes, conserve screen real estate and provide the first level of true integration between, for example, telephony and Web contact centers. Integrate the agent GUI by sharing the contact data record and its contents. If possible, some back-end integration may occur here, but in general that occurs in the next phase. In Phase 2, focus on screen appearance. This way, you can move the agent experience and skills all the way forward, with further changes being largely invisible to the front office.

Phase 3 — Common repositories for data. At this point, you have integrated desktops (at least in appearance) and the messages moving among media silos. Begin sharing back-end historical databases. This will greatly simplify unified reporting, data management and administration, and aid in the blending of the inevitable corporate organizational shuffle that will happen in the blended multimedia contact center.

Phase 4 — Common routing engine. This is a key phase. Merge skills databases, resource availability information and develop tools for specifying business routing logic common across media. A single engine will recognize the arrival of a contact, interrogate the intent, check for previous contacts, determine availability and finally, deliver the call.

Take a deep breath. You now have a functioning, multimedia contact center. Of course, there is still lots to consider for the future, but you can begin to see where your next focus should rest. Do you understand your contact population? Is one media type significantly more complex to manage than another? Are agent skills where they should be?

The promise of multimedia contact centers is great, although the realities of implementation can be challenging. But the challenge is not impossible; in fact, it is quite feasible, if you plan a phased implementation and have realistic expectations. When it is time to select vendors and evaluate technology, be sure to remember the three most important criteria: architecture, architecture, architecture.

Stan Vestal is manager, Eastern Operations, at Quintus Corporation. He is responsible for the development and deployment of call center solutions, with particular emphasis on CTI and telephony.