February 1998

BY DON FARBER

Multiple call centers are more trouble than they’re worth. Database replication is time consuming, resource intensive, and not real-time. Distributed access over the Internet is slow. Web-based service applications are, at best, pale imitations of their Windows-based counterparts. Still, in spite of these arguments, the distributed call center does exist. And in some cases (such as the European community), it’s actively flourishing. So, in this age of downsizing and centralization, the distributed call center cannot be viewed as either obsolete or archaic. Rather, we need to consider how today’s advances in customer service technologies allow us to address the long-standing arguments against a distributed call center environment. With these technologies, we can then strive to make the distributed call center as efficient and as seamless as the consolidated call center that it is often judged against.

To begin with, we must acknowledge that distributed call centers are a fact of customer service life. Organizations that provide service over a diverse geographical area (often across national boundaries), and organizations that support a wide variety of products and/or services are often required to provide multiple service centers or risk losing market share. Additionally, the recent surge in the growth of homebased employees is causing many organizations that had previously consolidated call centers to look at how they can now distribute their service technologies to these “virtual offices.”

So, given the necessary existence of the distributed call center, we can first analyze why the traditional technology that supports the consolidated call center is not a feasible solution in a distributed environment.

THE TRADITIONAL APPROACH
Traditional call center software is based on a client/server architecture. This architecture most often requires that each employee’s desktop (i.e., the client) be loaded with a significant portion of the customer service application. In some cases, a complete copy of the call center application may be required to reside on the client, and in other cases, only the user interface (UI) may need to be installed locally. In either case, the client machine is required to perform a significant amount of processing. This is referred to as a fat client.

Fat Clients
Fat client environments — although not ideal — are feasible in a consolidated call center. The reason for this is that most consolidated call centers operate on LANs (local-area networks), and so the information that needs to move from the server to each client (and vice versa) is readily available. Distributed call centers do not have the luxury of a high-speed network to utilize fat clients that receive huge volumes of information from a server, process that information, and then send it back. And so, the distributed call center has been forced to choose between two options (neither of which is terribly good) to handle the vast quantity of data that the traditional consolidated call center requires. These options are:

• Multiple local application servers (and database replication).
• Web-based (HTML) call center application interfaces.

High-bandwidth communication lines that link clients at distributed call centers with their corresponding servers represent a financial investment that is untenable for the vast majority of service organizations. And that’s why many distributed call centers opt for a distributed solution; an application environment in which each office is equipped with their own version of the corporate call center technology. In this environment, each distributed location may be thought of as a world unto itself; it has its own call center database, and its own arsenal of application servers. In fact, these “sub-call centers” often have an additional piece of hardware — the replication server — to enable them to upload their locallyrecorded data to the corporate database. And therein lies the problem.

First of all, we’ve exponentially increased the amount of hardware required to run the call center. In this environment, the resources needed to support a distributed call center of four locations with 25 users apiece is over four times the cost of a consolidated call center of 100 users. Secondly, the need to replicate data from the distributed locale to the corporate database is not only time and labor intensive, but it virtually eliminates any possibility of real-time, consolidated data analysis. (Not to mention that data replication rarely replicates all elements of locallystored data, thus providing an incomplete picture of the service environment.)

The Web
And this leaves us with the Web. Although the Web would seem to be the ideal technology for supporting distributed call centers, it just hasn’t worked. The reason (to quote a colleague of mine) is simple: “If Microsoft has invested decades of work in creating an efficient, widely-accepted application interface in Windows, why would anyone want to go back to the stone age with HTML?”

Why, indeed. HTML is well-suited to what it was initially designed for — the scanning of pages of information. HTML was not designed to be an interface for continuous, interactive, application usage. And the nonWindows look and feel of an HTML Web page isn’t the only reason it’s inappropriate for a distributed call center. Web pages simply display data: By not performing any degree of local application processing they create an additional load on a network (Internet or intranet) and they require direct database “hits” for any user requests. In short, although the Web is ideal for supporting brief visits by customers and prospects, it just doesn’t provide the robustness needed by a distributed call center.

Having said this, the Web is pointing us in the right direction. The concept of a single consolidated database is undeniably the right approach. It eliminates the problems of replication and numerous local servers. Also, the idea of using the Internet (or an intranet) as the universal communication medium to share call center information is a good approach. But the questions of speed, scalability, and usability still remain.

CONSOLIDATION CONCERNS
So let’s consider what the ideal consolidated call center would need and see if technologies that address these requirements also accommodate a distributed call center.

First off, a server-centric application (one driven by a platformindependent programming language such as C) provides exceptional scalability and reduces the requirements of a fat client. Secondly, an efficient and friendly UI (such as Windows) ensures application usability and short learning curves. And thirdly, an intelligent client reduces network traffic by combining some degree of local processing with optimal server communication.

The Java-Enabled Call Center
Enter into the picture the server-centric, Java-enabled call center solution. Although not every Java-enabled call center solution provides the requirements outlined previously, the combination of a non-scripted Java client (i.e., compiled Java code that runs on a server) with a scalable application server does meet these requirements nicely. In this environment, everyone works off of a central database. The processing of the call center application itself, with all of its resource-intensive components such as reporting, staff notifications, and call text indexing, is distributed to one or more servers in an organization’s central location. The key to this server-centric architecture is that changes made to the application (such as the addition of a field, the customization of workflow, etc.) are made just once and are then served out to all the appropriate clients. In a replicated database environment, application maintenance is not nearly as easy.

Java Client
As for the Java client — let’s begin by acknowledging that Java comes in many flavors.

A Java interface can reside (and be interpreted) on the client, or it can exist as compiled programming code that exists on the server. Both from the perspective of system resources (the thinnest of clients) and response time, compiled Java code is preferable. In this environment, the user’s session is actually running on the more robust server, and the size of the Java applet that is downloaded from the server to the client can be as small as approximately 300 KB.

This thin Java client has three distinct advantages over its HTML predecessor. First, it looks and functions just like MS Windows. Supporting the familiar look of “tabs” of information in a multiple windowed environment, Java offers the usability that HTML lacks. Secondly, since the Java applet performs some UI processing locally, the amount of network traffic is reduced and the application’s response time is improved. When this client architecture is combined with a servercentric application design, a distributed call center staff needs nothing more robust than 28.8 Kbps modem lines to effectively communicate with the corporate database. Thirdly, since the Java interface looks and functions like MS Windows, a Java-enabled call center solution lacks nothing in functionality or flexibility offered by its Windows counterpart. As another one of my colleagues described it, “It’s Windows, over the ‘Net.”

CONCLUSION
And so, perhaps the most interesting aspect of this configuration is that it is just as appealing to consolidated call centers as it is to distributed call centers. Server-centric, thin client architecture with a Windows-like interface is equally valuable to both environments. Thus, instead of weighing the pros and cons of a distributed call center solution versus many replicated consolidated call center solutions, the Java technology gives organizations the desired interface and speed of processing while offering a thin client environment that reduces an application’s cost of ownership. By virtue of an Internet browser or a “virtual Java machine” (such as a network computer) neither consolidated nor distributed call centers need sacrifice any degree of functionality.

Don Farber is the senior business analyst for Applix’s Enterprise product line and has 12 years experience in customer management software consulting, design, and marketing. Applix, Inc., is a leading provider of thin client business solutions for managing customer interaction, real-time decision support, and office productivity across globally networked, extended enterprise environments. The company provides thin-client computing solutions throughout its core offerings: Applix Enterprise, customer satisfaction software; Applix TM1, real-time multidimensional analysis for financial decision support systems; Applix office automation solutions, including Applix Office for UNIX and Windows NT and Anyware Office for Java-based desktops; Applixware, an open suite of desktop and development tools for accessing, analyzing, and communicating information in real-time; and Applix Anyware, an application development and deployment solution that leverages Java to customize and deploy Applix’s full suite of applications. Applix has offices worldwide and can be found on the World Wide Web at www.applix.com

One of the first distributed call centers to demonstrate the reallife value of a server-centric, thin client Java implementation is an organization called Brite Voice Systems. Headquartered in Gatley, England, Brite Voice is a leading provider of telecommunications equipment and services. With 10 offices located around the world, Brite Voice was facing an enormous financial and human resource expense for database replication, combined with the challenge of providing real-time analysis of a rapidly growing customer base.

In their first year of implementing a distributed Java-based call center solution, Brite Voice was able to grow their customer base by 30 percent without realizing any increase in customer service requests. This resulted from their call center professionals’ quicker access to a consoli-dated service database, more detailed resolution data, and less lag time in application availability.

Brite Voice also saw an exceptional increase in revenues. By using the Java interface to support the sharing of data among their distributed sales professionals as well as their service providers, Brite Voice saw a 25 percent increase in regular sales, a 70 percent increase in international sales, and a 50 percent reduction in the amount of time it required to get a new sales representative up to speed. In addition to the external benefits, Brite Voice also demonstrated how a thin client Java implementation could reflect a sizable IT infrastructure cost savings. Compared with the traditional distributed call center solution that required local servers and database replication, Brite Voice realized a distributed call center technology savings of approximately $1.6 million. On top of that, Brite Voice estimates their “per desktop” maintenance and upgrade savings is approximately $1,200 per year.

As one of the pioneers in the next generation of distributed call center technology, Brite Voice was rewarded for their work not only by increased revenues and decreased costs, but also by recognition in the industry. By being selected as winner of the U.K.’s IT Innovation Award for, “...successfully tackling a business problem in a unique way,” Brite Voice demonstrated that with the right technology, the distributed call center can be operated as efficiently, successfully, and seamlessly as its consolidated counterpart.