July 1999

The New Business Environment: CTI In ECM Architecture

BY GREG STACK, TECHNOLOGY SOLUTIONS COMPANY

CTI (Computer-telephony integration) implementations are changing in revolutionary ways. Today's strategic call centers are evolving beyond such traditional components as ACDs, PBXs and VRUs to include expanded delivery channels and customer access methods such as e-mail, the Internet, kiosks and mobile sales. This expansion of architecture and implementation is becoming known as the customer contact center. The customer contact center requires a much broader approach and vision than ever before.

Traditional Organization
If you are a traditional organization, you most likely have numerous legacy systems that grew up around products or company divisions. As customer contact channels expanded beyond white mail to call centers, VRUs and now Web and e-mail, each new channel was connected to the legacy systems as a separate project. Projects were completed in an uncoordinated fashion by various divisions, product managers and IS groups. The result is a “spaghetti” architecture in which each channel is connected to legacy systems in a “siloed” manner . Architectures of this type cost 30 percent more to build and maintain.

Even more critical is that within a “spaghetti” architecture it takes as much as 30 percent longer to execute business changes across channels and systems. In today’s competitive marketplace, this creates a major time and cost disadvantage that cannot be tolerated.

Expansion Of Customer Contacts
Further complicating this picture are two factors. First is the projected explosion over the next two to four years of customer contacts through the Web and e-mail channels. Some industry pundits are predicting triple-digit annual increases in these channels over the same time frame.

Second is customer expectations concerning multichannel exchanges. It is becoming more common for customers to utilize multiple channels for a single request. A typical scenario has the customer initially requesting information via e-mail to which the company responds with a fax. The customer may then have questions or require further action, so he or she calls the company’s 800 number. “I have a question about the fax you sent me,” says the customer. “What fax?” asks the agent. “The one in response to my e-mail,” says the customer. “What e-mail?” asks the agent.

No Silver Bullet
Systems that are architected and built today need to accommodate these increasingly common and complex scenarios. They need to integrate and track customer contact across all channels and systems for every interaction. This approach preserves your company’s investment in technology, saving substantial rework and potential delays in accommodating business change.
Unfortunately, many companies are searching for the “silver bullet” software package that claims to bring it all together. Implementing CTI middleware or a commercial CRM (customer relationship management) system as a “siloed” project without a blueprint of future multichannel architecture is a recipe for disaster.

ECM Architecture
Today’s customer relationship architectures require a broad approach and vision that encompasses strategy, process, operations and technical architecture. Several companies have been successful with a phased approach to implementing cross-channel architectures that support enterprise customer management (ECM). An ECM strategy is grounded in vision, architecture, integration and business benefits.

The approach is to interview corporate business leaders about your customer interaction strategy and work with them to establish a vision. The vision goes beyond how to interact with and service customers to how a company can create relationships with customers. Such a strategy might include one-to-one customization of call routing, VRU scripts, Web pages and e-mail. CTI-based call routing and prescribed action responses are customized in real-time based on a customer’s interaction history, recent events and perceived present and long-term value to the company.

Such a broad vision then guides the ECM architecture to support the future business strategy. ECM architects create a blueprint of multichannel architecture. This supports the business requirements of collecting customer interaction events, business rules, responding to customer requests, preferences and customized cross-sell and defection situations.

The ECM architecture is then compared to the current architecture. A gap analysis is conducted and a business case established to create a series of self-funding projects of six months or less. Each project moves the company closer to the desired architecture with the confidence that the technology investment will meet the company’s future ECM vision. Companies are free to set their own pace based on resources and urgency — most take from 18 to 48 months to reach their objectives. Figure 2 shows an example of a cross-channel ECM architecture that incorporates a “middle tier” to link customer access channels with existing legacy systems and data warehouses. This middle tier becomes the common element between channels and systems, allowing component services to be integrated across all channels and systems.Major components of ECM middle tier systems include:

• CTI middleware for resource tracking and integrating messaging between access channels (VRU, ACD, etc.). CTI can also be used as the universal allocation mechanism to blend media and contact channel based on volume and service level.
• An operational customer data repository to store customer contact events, contact history, preferences, value and current situation across all channels, products and divisions. This provides a single operational view of the customer. Note: this is not a data warehouse or the corporate customer master database, but rather a real-time operational data store used to route calls and allocate contacts based on a customer’s preferences, value, situation and historical interaction activity.
• A soft-data-based rules engine to route contacts across channels and prescribe actions to deploy. Actions might include the script to play, Web page to display, product to cross-sell or pricing plan to offer.
• Data-mining tools to examine the customer data repository for customer segments and trends in buying patterns, script response and behavior after offers and interactions.
• A data-based workflow/CRM package for process execution, case management, follow-up and fulfillment.
• Reporting tools to provide feedback on the success of targeted campaigns, customer segments and customized interaction strategies.
• Communications services to databases, legacy systems and the channels themselves.

The middle tier is the operational level whereby component services such as CTI, workflow, data capture, work allocation and business rules can be applied across all systems, contact channels and data stores. In addition, today’s architectures and products provide soft business and routing rules, thus allowing business managers and analysts to meet the specific needs of customers by changing routing and prescribing actions based on the value and complexity of the situation. This ability to make real-time business rule changes across all channels without IS intervention will open a new era of competitive advantage in the way that companies do business with their customers.

Figure 2

Expanded Benefits
The exciting thing about this approach is that the cost of the ECM infrastructure itself can be justified on its own based on operational efficiencies — often paying back in less than one year. The real icing on the cake is the follow-on stage in which the business begins to strategize and try out targeted business rules, actions and scripts. Recent studies have shown that upselling targeted to a customer’s needs can increase sales by 5 to 15 percent. Of even greater impact is a recent study indicating that just a 5 percent increase in the retention of high-value customers can generate revenue increases of 25 percent or higher. An ECM architecture serves as the foundation of an infrastructure that can dramatically improve profitability and transform the way your company does business with its customers.

How can the ECM infrastructure be used to achieve these benefits? The transformation often takes place in four stages. The first stage is the construction of the ECM architecture with its cross-channel data capture, customer data repository and soft rules engines. The next phase is using the customer profile and contact history data to segment customers, provide customized routing of contacts, customized scripts and specific actions to deploy based on customer profile, history and current situation.

In the third phase, the floodgates open as the business becomes familiar with ECM capabilities. Product managers and marketers begin to experiment with new customer target segments, new scripts, Web pages and e-mail responses. The ability to quickly change business actions and scripts to targeted customer segments coupled with a short reporting cycle create an unprecedented environment in which to respond to and interact with customers. ECM enables targeted cross-selling based on a customer’s need — not the product or script “du jour.” Once the power of the ECM architecture is realized by the business, customer interaction and, indeed, customer relationships become core strategies for management.

In the final stage, the focus turns to customer loyalty, as the business adopts customer relationships as a corporate strategy. The goal is to create unbreakable lifetime relationships with high-value customers. As previously noted, this can increase total revenues by 25 percent or more based on retained and increased sales. Studies have shown it costs 5 to 10 times more to replace a high-value customer than to retain one.

The ECM architecture provides the data and tools to create strategies and actions that promote loyalty and retention. For example, data-mining tools can be used to identify the events that precipitate a customer’s defection. The business can now create rules and take action to promote loyalty whenever such a defection event occurs. Detection and actions are now executed across all channels, allowing the business to fine-tune defection events, actions to take and offers to extend.

In summary, CTI today is an important component of a strategic ECM architecture. It provides the basis for the creation of relationships and fostering of customer loyalty. ECM architectures are a journey requiring a business vision and staged deployment over all customer access channels and legacy business systems. Once in place, the ECM architecture provides a component base in which to add services, data collection and rules engines that can be applied across the entire enterprise. Siloed deployment of packages or channels outside of the ECM blueprint will cost 30 percent more to maintain and will create a business disadvantage in the time required implementing business changes. Once deployed, the ECM architecture creates a new business environment in which companies can transform the way they conduct business with and retain their valuable customers.

Greg Stack is a senior vice president and co-founder of TSC’s Enterprise Customer Management practice. His 20+ year career includes work as chief architect and project manager across numerous industries and large complex integration environments. His work has resulted in major “industry first” deployments in telecommunications, Web, CTI, client server and customer relationship management.

Technology Solutions Company (TSC)   delivers business and technology consulting services that help clients transform customer relationships and improve operations. TSC partners with clients in a wide range of industries and has earned recognition as a leader in solutions for call center and enterprise customer relationship management, supply chain management, electronic commerce, financial services and packaged software integration. The company has headquarters in Chicago with major offices throughout the U.S., Canada, Latin America, Australia and Europe.

BY GARY HILL AND BILL DURR, ROCKWELL ELECTRONIC COMMERCE

Computer-telephony integration (CTI) is capable of producing phenomenally positive changes in most call centers. Paul Anderson, in his book The Digital Call Center, reports that the American Automobile Association realized an improvement in average speed of answer from 45 seconds to 17 seconds and a reduction in abandoned calls from 5,800 to 542 (measured over six months) by implementing a simple screen pop. Yet, a recent GartnerGroup report referred to CTI as an area more discussed than implemented. GartnerGroup estimated that just 20 percent of enterprise-level, formal call centers had implemented any CTI. It makes one wonder why there is such a low uptake of apparently beneficial technology.

There are many reasons offered for the low penetration of CTI in call centers. In the most general sense, CTI implementations have been expensive, difficult, result in overruns in both cost and schedule, and frequently fail to live up to user expectations. GartnerGroup provides a deeper level of analysis into the failure of CTI in the larger call center marketplace. They point to immature CTI standards, the failure of vendors to properly assess the complexity of CTI projects and the difficulty associated with quantifying the mostly soft benefits that pure customer service call centers realize with successful CTI implementations.

Nevertheless, CTI vendors can cite their experience with numerous complex CTI projects that have been successful. Obviously, there is a way to weave through the landmine-strewn landscape that represents the CTI marketplace today.
There is a great deal of naivet� associated with CTI. It is not unusual for call center users to call a CTI vendor asking how much a “CTI card” costs. Of course, there usually is some hardware involved in implementing a CTI project, but as most people realize, CTI is much more about software. And the wild card is that the newly implemented CTI software has to link to other, existing software systems. These other, existing software systems include multiple legacy databases running on all manners of computer platforms, application software used by agents, networking operating systems, computer operating systems, communication protocols and back-office databases and applications. The sheer variability and virtual unknowns of all these elements constitute the principal areas of risk in CTI implementations.

Rockwell Electronic Commerce has learned through years of experience that the only successful approach involves rigor. In fact, it is difficult to even generate a quote for a CTI proj-ect without a fair amount of rigor.

One suggested approach involves the creation of a “functional requirement document” and a “statement of work.” The first document, the functional requirement document or FRD, is the master document. It begins with an overview of what the project is expected to accomplish. Specifying the goal is, ironically, one of the frequent pitfalls that plague CTI projects. For example, most call center users have, unfortunately, become convinced that a simple screen pop is what separates successful from struggling call centers. The familiar mantra is that the call center can save up to 15 seconds per call by painting a screen full of information about the caller to the agent about to receive the call. But it pays to ask (and frequently) a more perceptive question: What are we really trying to accomplish? What are the business goals of the screen presentation? Thus, what should be on that screen in the first place?

Most call center applications began their lives as mainframe applications serving dumb terminals. System analysts of that era tended to worry about response time. To minimize data communications overhead, these analysts tended to throw large amounts of data onto the screen with each fetch. The typical dumb terminal was capable of displaying nearly 2,000 characters. It is no accident that most call center screens are still packed with nearly 2,000 characters. Even when the IT organizations upgraded systems with desktop personal computers, the same old dense screen layout was typically converted into a few colors and tucked into a window.

By forcing a firm to confront its data infrastructure and asking seemingly simple questions about the real goal of the project, the FRD turns out to be a powerful tool for focusing everyone involved with the project upon the actual desired outcome. More often than not, what is desired and even necessary is not to simply pop a 2,000-character screen, but to think about the transaction flow in detail. Increasingly, this focus upon the transaction is termed “workflow,” and it is what business process re-engineering was really all about in the first place. The vendor, the IT organization and the call center users employ the FRD to think about and decide what data needs to be presented to the agent, not only to begin the transaction, but also as the communications progress through the call. We have learned that being relentless about minimalism brings huge payoffs. What we mean by minimalism is the notion that what should be on the agent’s screen at any particular point in the transaction is the fewest characters, the least amount of data and the fewest number of choices that are capable of moving the transaction to the next step.

The FRD is also the perfect vehicle to describe the total environment. What data exist upon which platform? What links exist or may be needed that permit access to that data? What are the protocols of those links? What other systems are related to that data? Who owns the platforms? What back-end systems utilize the same data? The questions sometimes seem endless. All require answers before embarking upon the project because holes in understanding and surprises about the infrastructure add significant risk to the projects, and thus are responsible for most of the cost overruns and disappointments in outcomes surrounding CTI implementations.

The FRD also should be used to force the involvement from the actual end users or IT organizations that seem to be frequently missing or incomplete. So, we are often told that the project is about a screen pop. But the users are never tasked with deciding what the screen should look like. Sometimes the screen design is never discussed; it is assumed by the IT organization to be what currently exists. While that may benefit the IT organization, it is the source of much ill will in the call center. Frequently, the project is looked at as a telecommunications endeavor with minimal involvement from the IT resources until things go astray. The creation of the FRD forces up-front involvement from the IT resources, ensuring there are no network infrastructure surprises during project implementation.

After the FRD is complete, we are in a much better and more confident position to quote project development costs and schedules. The final result is a statement of work or SOW. This document specifies in detail which party is responsible for what piece of the project. The SOW, properly developed, leaves no wiggle room for any of the parties. The telecommunications and IT organizations are clear about their responsibilities. The primary vendor’s role is equally clear, and supporting subcontractors are clear about their contributions. A master timeline is developed. Pilot implementations are planned. Go/no go checkpoints are established. All these elements are required to alleviate risk and circumnavigate the numerous pitfalls associated with complex software projects that CTI implementations actually are.

Someday there may actually be a “CTI card” that one can simply plug into a server slot. Up pops a wizard that will painlessly guide even the novice call center user through the steps that ultimately produce a CTI-enabled call center application. Until that time arrives, call center managers and leading enterprise executives should insist upon the rigor of the FRD and the SOW. If there is a bit of uncertainty as to your chosen CTI product solution, one recommended approach is to invest in the creation of a FRD and associated SOW to clearly define the anticipated functionality and associated risks of the solution. Only upon conclusion of this activity would you then order the required CTI products and services. Remember the lessons of literature: for want of a nail, the kingdom was lost. In call centers, the case frequently is: for want of proper preplanning, the project was lost.

Gary Hill is senior manager of Call Center Consulting and Integration Services at Rockwell Electronic Commerce. He is responsible for managing activities related to Rockwell Electronic Commerce's CTI and third-party partner CTI and VRU products. A CTI and VRU veteran, Gary also leads Rockwell's CTI Application Integration Services and Systems Architecture and Integration Services groups.

Bill Durr is the director of Field Marketing at Rockwell Electronic Commerce where he provides operations analysis, helps call center users determine requirements, provides sales support on key accounts and provides best practices consulting to prospects and clients.