Call center architecture evolution
Feb 2, 2001
Gartner
© 2001 TechRepublic, Inc.
By B.
Elliot
As call center infrastructure evolves toward software-based
applications and to multichannel interactions, managers must develop a model
that both preserves investments and integrates the new channel
servers.
Call and contact center managers face a dilemma. On one hand,
they are being asked by management to support and integrate their telephony and
Internet contacts with one another, as well as with their front- and back-office
applications. On the other hand, these managers are being asked to preserve
investments in infrastructure and applications.
To address these
competing requests, and to avoid "scope-and-scale" paralyses, call center
managers and architects must develop a plan and blueprint for how they will
evolve their installations.
Gartner Research Notes |
Gartner Research Notes offer valuable data that is
compiled and written by analysts at Gartner, a business technology advisor
based in Stamford, CT. (TechRepublic is a subsidiary of Gartner.) Every
week in Support Republic, you'll find a new Research Note like this one,
which will provide you with a snapshot of information about a particular
mission-critical topic. To see more Gartner research, click
here. |
Two common problems that can bog
down contact center projects are "scope creep" and "scale creep."
- Scope creep: The project examines changing a single component of
the call center, for instance the CTI server, or an outdialer. As options are
reviewed, all other aspects of the call center and contact center become
included in the scope of what should be replaced, and the scope of the project
creeps up. The result is that managers are looking at a complete contact
center overhaul and unrealistic budget requirements. To avoid this problem,
managers should target very specific goals for the short term and clear, but
perhaps less-specific, architecture goals over the longer term. Then, the best
immediate solution that fits into the longer-term business strategy can be
found.
- Scale creep: As solutions are examined, the need to upgrade all
sites and all agents becomes part of the plan. Often this development occurs
before there is a clear large-scale demand from end users. The result is
unjustifiable budget costs to upgrade many desktops and servers. To avoid this
problem, managers should target a specific group of agents for a trial and for
initial rollout. Then, as experience grows and market validation is obtained,
the number of agents supported can be increased.
To address emerging
e-business requirements, preserve investments, and remain productive throughout
the change, three complementary design guidelines should be kept in mind as the
plan is developed.
Set goals
The initial,
and often most difficult, problem is organizational. To develop plans, managers
and architects must work closely with both the enterprise strategy planners and
the business-marketing units. This task is difficult because each group has its
own perspective and priorities.
Although often stated, this wisdom is
also often ignored: To succeed, clear, high-level business strategies,
priorities, and objectives must be articulated and backed by senior
management.
Contact center managers must discuss and develop an approach
in conjunction with the business units. The high-level strategic directives and
goals can then be combined with the more tactical business objectives in order
to be successfully translated into architecture planning guidelines and detailed
contact center plans.
Define layers
Defining
functional layers of a contact center's infrastructure and applications greatly
simplifies the task of integration and migration; in most cases, it is not
possible to develop an effective architecture without defining layers of
functionality.
Each new technology typically starts with its own approach
to integration. For instance, in a first release of a new type of application,
vendors may bundle Web or telephony functions within the application. This is to
be expected, as the initial goal is often evaluation, pilots, and time to
market. As the technology matures, use increases, and the functionality can be
modularized in subsequent revisions.
Interoperation of technologies
becomes critical; otherwise incompatible "silos" of application-specific
functionality result. Figure 1 shows the three layers of functionality in
contact centers: applications, middleware, and networks.
Figure 1 |
|
The middleware layer has
always been composed of channel-specific servers; increasingly functional
services are used to allow shared multichannel functions. Keeping these layers
distinct, and having well-defined interfaces between them, allows each level to
evolve at its own pace. For instance, one would not want to replace an ACD or a
LAN simply because a new back-office application is added to the call
center.
Deploy middleware
To both preserve
investments and allow evolution of infrastructure, managers should consider two
important middleware directions. First is the movement to "service-oriented
middleware architecture." This is made up of building blocks or modules of
contact center capabilities (to encapsulate and isolate the service
logic).
Middleware Modules |
Contact center middleware modules can include:
- Universal queuing and contact routing that provides contact
prioritization, scheduling, and routing.
- Agent skills and status that provide information about agent
availability and skills.
- Desktop screen pop and softphone functions. (Screen pop allows
information about incoming calls to be "popped" onto an agent's screen
at the same time the call is transferred to the agent; softphone
functions allow access to telephone functions via the agent's screen.)
- Common reporting in order to allow a single view of all contacts
across all channels.
|
These are
sometimes called n-tiered services, because they are able to call upon each
other, as well as to interact with the layer above and below. Second is the role
of message-oriented middleware. Increasingly, companies are looking at more
flexible, loosely coupled, message-passing systems using widely available
protocols like HTTP and interface definition tools, such as XML, operating over
an IP environment.
Contact center change is a continuous process.
Managers should expect continuous evolution of their environments because the
needs of businesses will change as they adopt new technologies, applications,
and strategies to better compete in the marketplace. To achieve this evolution,
by 2003, half of all large contact centers will have adopted new enterprise IT
standards, enabling enhanced interoperability and cross-application integration
via greater componentization and call center middleware (0.8
probability).
Acronym key |
ACD—Automatic call distributor HTTP—Hypertext
Transport Protocol IP—Internet Protocol LAN—Local-area
network XML—Extensible Markup
Language |
Bottom
line
To avoid expensive "forklift" upgrades and incompatible silos of
channel-specific infrastructure, contact center managers should evolve their
architecture toward middleware. Similarly, enforcing a well-defined layer
between applications and common contact center services will reduce dependencies
between applications and increase interoperability.
Gartner originally published this report on Sept. 19,
2000.
Copyright © 1999-2001 TechRepublic, Inc.
Visit us at http://www.techrepublic.com/