Call Center -- In the business of running a call center, knowledge
of the customer is the key to success or failure.
TeleServices Resources (TSR), Fort Worth, Texas, a unit of AMR Corp.,
has spent considerable sums over the past few years to improve interaction
between its call center agents and the customers of its outsourcing clients
in about 30 different businesses. Deft customer interaction can vastly
improve the productivity of agents, which in turn can quickly boost sales
and profits for TSR and its clients. Agents in TSR call centers support
several distinct lines of business, including airline reservations, cargo
sales and service, hospitality and travel services, and inbound and outbound
Competition in the call center business has become fierce through the
1990s as corporations look for new ways to get products and services to
consumers. Hence, call centers must constantly build innovative information
systems that can help agents direct customers for one product to other
merchandise based on their past purchasing histories. It is such a system
that TSR's I/S organization put in place for its agents over the past
couple of years.
The key to building a successful call center operation is technology,
said Phil Parrish, senior engineer at TeleService Resources.
To improve its customer interaction, TSR in mid-1996 started work on
the Visual Agent Environment (VAE) project, which aimed to seamlessly
integrate the company's internal systems with a wide range of client systems
in a three-tier, client/server implementation, said Parrish, who headed
up the project.
"At the time we were looking at several avenues to upgrade the system.
We wanted to take advantage of the Web. We needed a GUI (graphical user
interface). It had to be an interactive system. It had to reduce the talking
time for the agents. It had to make sure the agent was talking to the
client, and not to the screens."
Once those parameters were set, TSR I/S and corporate managers decided
the best system would require object technology, Parrish said. That decision
was made despite a lack of experience in using object technology within
the TSR engineering team and with the knowledge that tangible results
generally come later in object projects than in those using more traditional
tools. Parrish said the project, and the decision to use object technology,
was supported by TSR senior management, including James Welling, vice
president of information technology and sponsor of the project, and William
Jackson, president of the firm.
The project retained management support throughout the development effort
despite a slow start, Parrish said. In the earliest phases of the project,
developers had to work hundreds of hours to complete the modeling phase
and build the core business objects, persistence objects and visual components.
Parrish noted that the persistence objects were required to store data initially
to an IBM DB2 mainframe database and later to an Informix database running
on an AIX-based system. During this lengthy phase of the project, most of
the results could not be demonstrated to those TSR executives responsible
for funding the project. Nonetheless, the project continued to be backed
based on the long-term promise of object technology, he said.
Object-oriented development requires commitment,
discipline and consistent attention to detail. These are characteristics
that might not come to mind when discussing innovation. The implementation
of innovation, however, poses a number of challenges in waters not
well charted. We have witnessed a number of organizations wrestle
with the complexity of claims processing. The problem is ominous,
and the solution is not standard, or stable.
This application withstood some litmus tests that
we used to differentiate between a number of excellent submissions.
There is a strong business case in this example for investing in
an OO approach. This is a "bet the business" application
with a moving target for a solution and a serious degree of future
integration, that requires a long shelf life and the stability of
a mission critical application.
This application is built on a strong work-flow
concept, taking advantage of the distribution capabilities of the
architecture. While the project was longer and larger than many
might advise, most of the project risks were handled by the use
of a solid methodology, strong project management, and an appropriate
use of tools and outside expertise to supplement the project effort.
The inclusion of the mainframe technologies into the object architecture,
while becoming more common, still shows a commitment to preserving
investment and reusing stable systems.
This is not technology for technology's sake, but
a practical solution, deploying the right technology appropriately,
bringing innovation to benefit the business organization. Great
Early on, TSR decided to use internal programmers on the project rather
than hire costly developers with experience in object-oriented development.
The company also had to build a team of developers from internal resources
that grew up building traditional mainframe based legacy systems. Many
of the internal developers were wary of the promise of object oriented
development, Parrish recalled. "We all knew that the promise of object
technology was heavy reuse. We also knew that object technology is a problem
for some programmers because of what they see as a loss of control over
the development. We worked to avoid those problems."
Nonetheless, once TSR decided to go ahead with the project and use object
technology, I/S management had little trouble encouraging enough talented
volunteers to join the development team. "Right away we found a few
that were very interested in the project and were willing to take a career
risk," Parrish said. "For some of the team, the risk turned
out to be a great career move. We have lost two people who left for 60%
The team members that stayed with TSR have also benefited from the effort,
he said. "The project provided a new lease on life, career wise,
to a lot of them. These guys could move from here onto projects using
the newer technologies. Everyone on the team was trained in OO theory,
in OO best practices, and in the Smalltalk VisualAge environment,"
Right away, team members received training and experience using several
newer and popular development tools, computer hardware, operating systems
and a relational database, Parrish said. The team used Visual Age for
Smalltalk to build the systems. The IBM tool was selected over C, C++
and Microsoft's Visual Basic for its OO development environment support
for all IBM and several non-IBM hardware platforms, its reuse capability,
moderate complexity, and support for the AIX and Windows NT operating
systems, Parrish said. "The team has some very marketable skills
now," he said.
The server piece of the software runs on IBM RS/6000 SMP (symmetrical
multi processing) hardware running AIX and the clients on Windows NT-based
systems. The VAE system uses an Informix database running on the server.
Parrish noted that TSR implemented a three-tier architecture so the new
system could complement and interface with the existing TSR mainframe
legacy systems and systems running at client sites.
The team followed a methodology, though it did provide some flexibility.
Parrish said TSR selected the Fusion methodology, which incorporates pieces
of multiple object-oriented methods to avoid being tied to a single formal
procedure. The team also used the Microsoft Project software to track
tasks, deliverables, milestones, dependencies and the critical path.
The finished product consists of more than 1,000 classes and 5,000 methods.
The team built a distributed object-oriented design to create VAE. The
design was layered to include visual parts, business objects, persistence
objects and communications objects.
The system has been in place for more than a year, and TSR estimates
that VAE is saving the firm $4 million annually due to increased programmer
and call center agent productivity and the reduced agent training time.
In addition TSR estimates a decision to internally develop middleware
for the project saved about $2.3 million over the cost of off-the-shelf
middleware. Parrish estimated the cost of off-the-shelf middleware at
$6,000 per workstation compare to the $200 per workstation cost of building
the software internally.
- Michael W. Bucken
|PHIL PARRISH, senior
RICK JOHNSON, senior programmer
KEVIN HUIBREGTSE, senior programmer
PAM CROSSMAN, senior programmer
TAMMY WALSH, senior programmer
PHIL HARVEY, senior programmer
VICTOR GALVAN, senior programmer, EDP Systems
CLIFFORD O'KEY, programmer
BRIAN FIVES, programmer
MUNEEN MOHAMMED, programmer
LINDA GREEN, programmer
ROBIN REED-CAMPBELL, programmer
DEBBIE BREAZEALE, programmer
BEVERLY ARMSTRONG, programmer
MARILYN MAYFIELD, programmer
AILEEN INGRAHAM, programmer
SCOTT THOMPSON, programmer
JOANNE STACH, programmer
MITCHELL SWINDELL, senior engineer