Objects provide path to call center leadership for TSR

COMPANY: TeleServices Resources
PURPOSE: Improve customer interaction

APPLICATION: 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 telemarketing.

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.


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 Job.

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.

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% salary increases."

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," Parrish said.

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 engineer

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


LINDA GREEN, programmer






SCOTT THOMPSON, programmer

JOANNE STACH, programmer

MITCHELL SWINDELL, senior engineer

About the Author

Mike Bucken is former Editor-in-Chief of Application Development Trends magazine.