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 years 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 dont 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?
Its 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
- 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? Lets follow an inbound transaction from start
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
- 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 customers 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
- 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
- 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. Lets examine the technical
components that are required.
The key technologies that make our scenario possible are:
- A common data record containing a history of all contacts,
- A repository for these data records, available for searching by any process in the
- A personalization engine capable of routing based on skills, customer profile, and
- Consistent and compatible connectors to any media type, having access to all the
features of the system,
- 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
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
If youve 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. Its 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
agents 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.