April 2002

CRM Across The Enterprise: Integrating The Channels

By Eli Borodow, Telephony@Work

'Integrating the channels' is an infrastructure objective that demands nothing less than the re-definition of 'the call' itself to include the many different ways customers can interact with a contact center. This encompasses communications originating on the phone, fax and Internet, including e-mail, voice mail, chat sessions, on-the-fly Web-collaboration, voice-over-Web calls and Web callback requests. Of course, this integrated infrastructure must also include quality recording, supervisor monitoring and 'barge-in' capabilities that extend across all channels.

So why bother? Anyone who has ever worked in sales knows that live communication is often necessary to reassure potential customers, answer their questions, close the sale and upsell customers. Experts agree that live service on the Web more than pays for itself in increased business and fewer abandoned shopping carts. As a result, implementing and integrating the various channels of customer communication has become an obvious cost of doing business on the Web. The less obvious issue companies must address, and the more difficult one, is what the integrated infrastructure should look like from a software architecture point of view.

System Paradigms: Formulas For Success Or Failure
Why is this issue so critically important? It's simple. The architectural paradigm in which multichannel infrastructure is deployed can have far-reaching and often unintended implications. These will impact on initial deployment costs and on enduring re-integration requirements and service costs (as changes are required or as vendors release updates and new versions). They also impact go-forward training costs, employee productivity and the resulting manpower requirements, reporting quality and system reliability, scalability and extensibility. Perhaps most important, they will determine a company's ability over time to provide superior or even comparable service to that of its competitors.

A framework for paradigm differentiation exists in the vendor and consultant communities that can help buyers understand core differences. This framework suggests that contact center solutions can essentially be divided into three camps, with each representing a differentiated approach to the problem. Understanding the distinction between these paradigms provides a lens through which companies can assess proposals under consideration.

The Multisystem Custom-Programming/Systems Integration Paradigm
The first of these paradigms is represented by 'multisystem solution vendors' that offer various point solutions that are, in fact, separate, non-integrated systems that are usually provided by different technology vendors; or by a single technology vendor that has acquired separate, non-integrated systems through mergers or acquisitions. In this paradigm, each point solution consists of programming tools that require professional programming services in order to deploy each technology. Professional services are also required to 'glue together' the different systems that provide those capabilities, but the result is an infrastructure without an overriding software architecture or a common administration interface. The inability of many integrators to provide cross-media, historical customer interaction information on the agent desktop (or even transfer data along with calls) has created significant customer frustration. In addition, the absence of integration-by-design often results in having to dedicate agent seats to different technologies. This requires foregoing the manpower efficiencies associated with a common agent pool and deploying technology-specific agents. Cross-media licensing is also unavailable since all the vendors involved must be paid. As a result, you are not licensing based on overall communications capacity, but must instead license each capability separately ' and ultimately 'overbuy' licenses to address constantly shifting traffic patterns between media types.

This paradigm requires large-scale systems integration and involves many consultants, integrators and programmers. As a result, implementations in this paradigm often take more than a year to complete. The familiar argument against this paradigm is that its solutions are expensive to deploy and expensive to own. Changes are expensive and time-consuming to implement. In addition, every time one technology solution provider issues a product upgrade release, it must be re-integrated with the other point technologies in the 'integrated' solution. Because every vendor issues product upgrades on different release cycles, each new technology increases maintenance complexity and costs exponentially. There is also the element of danger: who hasn't heard of systemwide crashes resulting from simple upgrades?

Fault tolerance is another area of concern. Each subsystem in this paradigm represents a separate point of failure. Instead of 'hot back-up,' this paradigm relies on 'fail-over' or 'warm back-up.' This is an important distinction. 'Hot back-up' ensures that if any software process crashes, another server on the network can instantly take over without the loss of any information or the disconnection of calls ' even on calls in progress. 'Fail-over' is an older technology that works simply by disconnecting all communications in progress and switching over to a back-up system that takes over after 10 to 30 seconds of downtime. 

Despite its shortcomings, this paradigm can make sense for companies that have out-of-the-ordinary requirements or those that have already purchased most technology components and simply want to layer new capabilities onto existing infrastructure; particularly if those components are early in their lifecycles and management is unlikely to authorize a forklift. Of course, the more point solutions already deployed, the more sense this paradigm makes. While these vendors typically play in the very large contact center space and tout their scalability, the irony is that this is also their weakness: because their solutions are usually too complex and cost too much to scale down effectively for small and mid-sized contact centers.

The Unified, Single-System/ Custom-Programming Paradigm
The unified, single-system has attracted a lot of attention over the last eight years as an alternative to multivendor systems integration. What many don't realize is that most of these vendors don't sell shrink-wrapped software, but instead market a unified set of programming tools that must be implemented by systems integrators. As a result, their solutions involve many of the same disadvantages as those in the multisystem paradigm. Most do not even leverage being a single source to provide cross-media licensing, choosing instead to bill separately for licenses of each media type.

This paradigm has advantages and disadvantages that potential buyers must consider. Since there is only one set of programming tools involved, there's less finger-pointing. Also, because the programming tools are unified, these systems take less time to deploy and cost less to configure and/or reconfigure than in the multisystem paradigm. Cost of ownership is also decreased because updates come from only one vendor ' but some additional re-integration services may be required for implementation.

Since all installations involve custom programming, the quality of deliverables is inconsistent. In addition, since custom programming is required by individual programmers who may not work for the vendor several months down the road, clients must ensure their code is extremely well documented. Reliability is also an issue here because these vendors rely on fail-over rather than 'hot-back-up.' There's another important caveat to keep in mind: a single vendor does not equal a single, unified system. In fact, most single-source solutions are deployed in the multisystem paradigm; because their suites were the result of mergers and acquisitions or separate team development rather than integration-by-design. 

Most single-system vendors deploy their technologies on communications server platforms, which replace traditional PBXs with server-based switching (to reduce costs and fully integrate communications infrastructure). The common concern about comm-servers regarding scalability is often justified but is not universally true. Those who support ATM backplane networking between servers (which can link servers together to work as one), do not suffer from these limitations ' particularly if their software is designed with a network-based architecture. Many vendors claim to be network-based, but what they often mean is that their technology is distributed across multiple servers that perform specific tasks. True network-based software architectures can eliminate traditional scalability limitations entirely ' by re-defining scalability as a flexible barrier limited only by the processing resources of the network. Here the network becomes the computer. Need more processing resources? Plug in another server. No limits. This is where the industry is headed. For the next paradigm, this vision has already been realized.

The Single-System, Menu-Driven Customization Paradigm
The questions all customers inevitably ask are, 'Why haven't vendors matured their technology into commercial, out-of-the-box technology that is fully customizable through drop-down menus and parameter selections instead of custom programming? Why is it still necessary to examine dozens of technologies and vendors in order to make good decisions? Why is it still necessary to retain and manage consultants, system integrators and software developers?'

Those were the questions engineers began asking in the mid-1990s. Why hadn't contact center technology matured such that it could be fully customizable from menu selections rather custom programming? Why, understanding the scope of the issues, hadn't anyone decided to whiteboard the problem and create an architecture integrated-by-design to work seamlessly and flawlessly? The answer, as it turned out, was that anyone who wanted to distribute contact center software through traditional distribution channels had to 'leave margin' for the consultants, system integrators and software developers who have the relationships with the end-user companies ' and the last thing these distribution channels wanted was to take on technology that would eliminate professional services revenue. The vision would have died before it was born except for one thing: the prevailing paradigms couldn't deliver on the ambitions of large telephone companies. What the phone companies wanted was something the enterprises had also wanted but no one was yet willing to provide: technology that deploys quickly without sacrifice in customization capabilities that wouldn't require man-months or man-years of professional services to implement or maintain. Since none of the vendors developing for traditional distribution channels were willing to abandon their old business models for this new approach, a new class of vendor and technology paradigm was born to fill the niche. This paradigm would deliver scalable, comprehensive infrastructure in a true, network-based architecture that could deploy through menu selections and deliver sophisticated customization capabilities at no cost in a browser-based environment ' with cross-media licensing and rock-solid, carrier-grade 'hot-back-up' reliability. 

Funded by telco revenue, this paradigm became an option for enterprises in the last two years only, delivering the unique value proposition of carrier-grade reliability and scalability at enterprise-level pricing. This paradigm offers carrier-class infrastructure that installs faster, cheaper and with greater reliability than enterprise-grade technology. Reflecting the new sensitivity to provisioning costs, customization is implemented through parameter-based configuration menus instead of professional services. This enables low-cost deployment and no-cost changes and updates without sacrificing functionality, algorithm customization or any of the elements associated with custom integration and programming. 

This paradigm can be deployed on 'one-box' communications servers (two or more in a 'hot back-up' configuration), in a distributed network or in incarnations that support legacy PBXs. It also enables multisite centers to become service providers for their regional centers and telecommuters ' with skills-based routing to the best-available person regardless of location. (Signaling System7 or 'SS7,' the traditional method of multisite load balancing and network routing, always routes calls to the site with the most availability and cannot consider agent qualifications at the network level.) This paradigm's overlay capabilities also solves another major problem specific to multisite contact centers making the multichannel leap: load balancing all media-types across locations. (Remember, SS7 only load balances circuit-switched voice communications. Web-enabled multisite operations must also implement multichannel load balancing across locations.)

So what's the downside? Majority rules. While APIs are still provided, this menu-driven paradigm really focuses on the comprehensive needs of the large majority of contact centers. As such, while most would find the technology perfectly suited to their needs, you really can't get under the hood and reprogram capabilities to implement funky, one-off projects that tie technologies together in non-standard, unexpected ways. But unlike other paradigms, new capabilities might arrive in the next release and they can be implemented in the same way you upgrade other shrink-wrapped software ' without expensive professional services.

Responsible decision makers must look beyond the surface level of feature/functionality to find answers to the really big questions about core architectural efficiencies, stability, realistic up-time, future scalability and extensibility. It is system architecture that will ultimately either unleash or severely limit your contact center's operational efficiency for many years to come. 

Eli Borodow is CEO of Telephony@Work (www.telephonyatwork.com) and can be reached at [email protected].

Effectively Integrating The Components Of CRM

By Bipin Paracha And Anupama Bulusu, eConvergent, Inc.

In the CRM arena, the challenge of assembling data and articulating accurately the importance of an individual customer or prospect to the different functional areas of an organization has been widely recognized. Several companies have created solutions to help mitigate this problem. These solutions range from custom, homegrown applications to packaged solutions. Almost all of these products offer a 'comprehensive' solution, but the methodology for extracting the most value out of a system varies with each individual implementation. This article describes the different components of a typical CRM implementation and a simple technique for identifying requirements.

Components
Listed below are the different components of CRM in a typical customer interaction center.

CRM Applications. Front-office applications for performing tasks in areas like service, sales and marketing have now come into the realm of CRM. CRM has come to mean any application used to deal with customers. Traditional CRM applications include trouble ticketing and contact management. Examples of vendors in this area include Siebel, Oracle, Clarify and Remedy.

Voice. Voice contacts are usually handled by an ACD (automatic call distributor) from companies such as Lucent, Nortel, Aspect or Siemens.

E-mail. E-mail received by a customer interaction center can be managed two ways. The first form of an e-mail management system is to use a packaged solution offered by vendors such as Kana or eGain. The second method is to build applications and business processes around an e-mail server, such as Exchange or Lotus Notes. Deciding which method fits a particular company's needs better is a topic in and of itself.

Additional Channels. Customers can choose to get in touch with a company through several contact media. The most popular contact channels are voice and e-mail. In addition to these two, customers may choose to walk in, or use channels like postal mail, Web chat and collaboration, wireless, video, etc.

Other Interaction Center Applications. Other applications in a contact center, such as reporting (real-time and historical), self-service applications (IVR, Web self-service), etc., do not 'neatly' fall into the classifications described above. However, these applications do need to be considered, since they are highly specific to each contact center implementation.

Web CRM. For the purposes of this article, the corporate Web site and any Web-related efforts, like personalization, etc., are also components of CRM. These are technologies that can be used both internally (agent-facing) and externally (customer-facing) so that they qualify as CRM as well as 'Internet' initiatives.

Business-To-Business Value-Chain Perspective
The value-chain perspective of business-to-business (B2B) has led to investments in exchange portals and enterprise integration. Typically, these technologies, which promote organizational efficiencies by utilizing information spread across applications in the enterprise, have been focused on domains associated with ERP, such as supply chain management, order processing and fulfillment. These investments can be utilized for optimizing the CRM implementation. For example, an 'enterprise application integration framework' can be used to integrate point solutions in the CRM area. Integration of these 'value-chain' applications into CRM will lead to highly knowledgeable agents and present a single company view to the customer. This can have tangible benefits like first-call resolution of issues leading to a reduction of the cost of support. However, such integration leads to the real benefits of CRM in customer retention and loyalty leading to 'cheap growth.'

Implementation Exercise
Even if the CRM hype is pretty recent (past few years), all companies have investments in technologies that dealt with customer relationships, although they might not have been labeled as CRM products. For instance, trouble-tracking systems, which have been used for a long time, are now glorified as CRM applications. Of course, there is extensive added functionality in most cases, but the basic stratagem is the same. Removing the 'CRM' tag from applications before the requirements phase might greatly assist in cutting through the hype to come up with 'value drivers' for the CRM implementations.

Consider the following exercise: If an interaction center were to be built from scratch, what functionalities would be needed? There is usually a great temptation to take the current implementation and 'fix' it. However, this might not prove to be a wise choice. The emphasis should be on 'functionalities required.' In the first round of requirements gathering, one should focus on obtaining a reasonable list, instead of a comprehensive one. Trying to achieve 'completeness' might bring on the 'analysis-paralysis' trap.

A reasonable long-term vision should be included. The CRM market is still maturing with pockets of components in the old age (like ACD) and pockets in their infancy (like packaged CRM application suites). The next few years should see a shakeout in the application software area and companies would not want to be left out to dry with the current investments. An extreme position to take would be to make no investment in CRM and be left out in the 'cheap growth' promise of CRM.

Once the list is generated, requirements must be mapped to existing applications along with the 'holes' that the current applications represent. Two or three iterations through this process should provide highly valuable insights into the requirements for the new or replacement system. This step also highlights the places where investments in technologies can be retained and areas where the technologies can be 'accommodated' beyond their life span.

One of the saving graces of 'CRM' is that it is an incremental technology ' components can be implemented in phases based on immediate pain points and funds available. Even large suite vendors have their offerings broken out into specific applications for each area.

Individual organizations should map out the requirements and decide whether to implement a suite solution or try to leverage existing investments with integrations.

Bipin Paracha is a senior software architect and Anupama Bulusu is a data architect at eConvergent.