an executive's guide to crm - free

Pat

rici

a S

eybo

ld G

roup

’s E

xecu

tive

Ser

ies

Patricia Seybold Group Trus ted Adv iso rs to Cus tomer -Cent r i c Execu t i ves

An Executive’s Guide to CRM How to Evaluate CRM Alternatives by Functionality, Architecture, & Analytics

By the Patricia Seybold Group

210 Commercial Street, Bo .1028 • www.psgroup.com

Direct link: http://dx.doi.org/10.1571/crm-execguide

ston, MA 02109 • Phone 617.742.5200 • Fax 617.742

http://dx.doi.org/10.1571/crm-execguide

TABLE OF CONTENTS

What Is CRM? Where Are We? Where Are We Going? .....................................................................................4

What’s Important in CRM Architecture? A Framework for Evaluation and Comparison........................................................................12

What Are Customer-Centric Analytic Applications? A Framework for Evaluation and Comparison........................................................................23

What Comes After CRM? Customer-Led Business Transformation..................................................................................35

Framework for Evaluating Cross-Channel, Cross-Lifecycle Customer Service Products How to Evaluate Solutions that Support a Great End-to End Customer Experience ..............45

Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix A Blank Matrix to Facilitate Your Evaluation Process for Customer Support Offerings........58

What’s Next? If you find this report valuable, then: Print It – YES, you are free to print and freely distribute this report as long as its contents are not changed.

Spread the Word – Send a friend or colleague to http://dx.doi.org/10.1571/crm-execguide so they can download their own copy.

Stay Informed – Subscribe to our free email newsletter at http://www.psgroup.com/signup.aspx to stay up-to-date on this and other important research topics.

Learn More – Contact us at [email protected] to find out how our additional research and consulting services can help your organization sort through its CRM strategy.

© 2005 Patricia Seybold Group

http://dx.doi.org/10.1571/crm-execguide

http://www.psgroup.com/signup.aspx

mailto:[email protected]

An Executive’s Guide to CRM

What Is CRM? Where Are We? Where Are We Going?

By Mitchell I. Kramer, Sr. VP and Sr. Consultant, Patricia Seybold Group

WHAT IS CRM?

Multiple choice: CRM (customer relationship management) is:

a) Sales force automation applications

b) A marketing buzz word

c) A corporate philosophy

d) Software that implements marketing, sales, and service business processes

e) Implemented by a wide range of applications

f) A way to improve customer satisfaction and in-crease business

g) The next wave in information technology

h) Very difficult to implement

i) All of the above

j) None of the above

Unfortunately, the correct answer is i), all of the above. We say “unfortunately” because h) is too fre-quently true, because b) and g) carry too much nega-tive connotation and because a), while correct, is too narrow and, perhaps, even vendor-centric in its cor-rectness. The best correct answers are c), d), e), and f). Here’s why.

CRM IS A CORPORATE PHILOSOPHY

CRM is a corporate philosophy because it is a fundamental approach to doing business. That ap-proach is to be customer-focused and customer-

driven, running all aspects of your business to satisfy your customers by addressing their requirements for products and by providing high-quality, responsive service. The philosophy extends to support customer managed relationships (CMR) where the customer is in the driver’s seat, determining the rules of the rela-tionship. Companies that adopt this customer-focused and customer-driven approach are, thus, customer-centric.

The inverse of customer-centric is product-centric. Can you think of any products that your company could never effectively sell? Innovative though these products may have been, they probably didn’t solve any customer problems or address any customer requirements.

CRM Objectives

The objectives of CRM are straightforward:

• Acquire new customers • Retain the right existing customers • Grow the relationships with existing customers

No surprise here. These are probably your corpo-rate business objectives, too, or at least your corpo-rate marketing objectives; but the way that you state them and your strategies to achieve them may not be sufficiently customer-focused. As a philosophy, cus-tomer-centricity drives you to view your entire busi-ness from the perspective of your customers.

CRM IMPLEMENTS MARKETING, SALES, AND SERVICE BUSINESS PROCESSES

CRM implements the marketing, sales, and ser-vice business processes—the customer-facing and customer-touching business processes through which you interact with your customers.

Customer Scenario and Customers.com are registered trademarks and Customer Flight Deck and Quality of Customer Experience (QCE) are service marks of the Patricia Seybold Group Inc. • 210 Commercial Street, Boston, MA 02109 USA • www.psgroup.com • Unauthorized redistribution of this report is a violation of copyright law.

What Is CRM? • 3

All Business Processes Support CRM

Note this important point. While these are the CRM business processes, all of your business proc-esses, and many business processes of your suppliers and partners, provide critical support for them. That support is achieved through business process auto-mation and application integration. For example, your fulfillment system (or your supplier’s fulfill-ment system) must be integrated with your CRM system so your customers can find out when you’re going to ship their orders.

CRM Must Support All Touchpoints

That brings up another important point. Your customers interact with your direct sales reps, con-tact center reps, and Web applications. These inter-actions occur through a variety of touchpoints—the phone, face-to-face, a Web site, etc. Your CRM business processes have to support all these touch-points, supporting a single and consistent view of your customers as well as a single and consistent view of your company.

A single and consistent view of customers is achieved by using the same customer information across all your business processes. This 360-degree view of your customers can be accomplished by de-fining a single customer data model and customer data implementation or, more practically, by inte-grating and synchronizing that customer data model across every business process that touches, faces, or supports CRM. Implementing a single and consistent customer view is a critical success factor for becom-ing customer centric. This implementation is never easy.

A single and consistent view of your company is achieved by providing the same marketing, sales, product, support, and order information to your cus-tomers across all the touchpoints through which they interact with you. This consistent “customer experi-ence” can be accomplished in the same manner as single and consistent customer information. It’s also a critical success factor for customer-centricity and difficult to achieve. Illustration 1 shows visually the business processes and touchpoints of CRM, the business processes that support CRM, and the single view of customers.

MANY CRM APPLICATIONS

CRM is implemented by a wide range of applica-tions that implement the three direct CRM proc-esses—sales, marketing, and service—and the many business processes that support them. The applica-tions that implement these business processes are considered “operational” applications. They’re the applications that “do” your business, delivering of-fers, generating orders, and responding to customer requests. CRM also has an analytic or decision sup-port dimension. We call these applications customer-centric intelligence applications. Illustration 2 shows these applications and how customers interact with them.

Customer-Facing Applications

The key, customer-facing CRM applications are contact center, sales force automation, and field ser-vice, described briefly in Table A. We call these “customer facing” because your sales, fields service, and contact center representatives actually interact with your customers. Customer-facing CRM appli-cations support those staff members.

Customer-facing applications have been around for many years. You probably had sales force and field service automation applications before you even thought about CRM; maybe you even built them before commercial products were available. Those products that do implement these applications also predate CRM, but have now been repositioned to take advantage of the CRM trend. For example, many of the products that implement teleservice were developed as help desk products, dating back to the late 1980s. SFA applications, originally known as contact management applications, have been around even longer.

Because the implementation of these applications predates CRM, they may need to be upgraded to re-flect a customer focus. These upgrades should give them that single and consistent view of your cus-tomers and your company and integrate them with the business processes that support their marketing, sales, and service functions.

© 2005 Patricia Seybold Group A Customers.com® Research Service

4 • An Executive’s Guide to CRM

CRM Business Processes, Touchpoints, and Customer Information

E-mailContactCenter

DirectSales POSWeb

CRM Applications

Customer Systems

Customers

Touchpoints

Supplier Applications

Back Office Applications

Contact Center Contact CenterContact Center

Business Processes

Applications

Customer Data

© 2005 Patricia Seybold Group Inc.

Illustration 1. This illustration shows the business processes and touchpoints of CRM, the business processes that support CRM, and the single view of customers.

Customer-Touching Applications

The key customer-touching CRM applications are campaign management, ecommerce, and self-service customer support, described briefly in Table B. We say “customer touching” because your cus-tomers interact directly with the applications rather than through a company representative.

Customer-touching applications are relatively new—certainly much newer than customer-facing applications. Most date from the mid to late 1990s. It’s not inconceivable that your company has not implemented any or all of these applications. Cam-paign management was the first attempt to automate the marketing business process, allowing companies to deliver offers to more markets more (cost) effi-

A Customers.com® Research Service © 2005 Patricia Seybold Group

What Is CRM? • 5

CRM Applications

Suppliers

Seller

Seller

Customers

E-Commerce

ContactCenter

FieldService

Automation

SalesForce

Automation

CampaignManagement

Self-serviceCustomerSupport

Back Office Systems

Customer Facing Systems

Custom

er Intellig enceCustomer Systems

Customers

Users

The Customer Experience

Supplier Systems

Integration

Integration

Customer Touching Systems


Illustration 2. This illustration shows customer-facing, customer-touching, and customer-centric intelligence applications and how customers interact with them.

ciently, more effectively, and more frequently. Elec-tronic commerce was a breakthrough application. It gave companies a new touchpoint and a way to ex-pand their market reach and presence, automating completely the online marketing, sales, and service processes. Electronic commerce also gave us auto-mated personalization, a customer-centric approach to treating each customer as a market of one. Self-service customer support was the next step for cus-tomer service. While contact center applications brought help desk capabilities to customers, self-

service customer support applications put this func-tionality online, enabling customers to access it 24 by 7.

All customer-touching applications let customers help themselves—one of the basic principles of our Customers.com philosophy. Your customers may prefer to interact in this self-service way. You can increase your throughput through self service. You can also improve the quality of the experience that you provide by balancing functions between touch-ing and facing touchpoints, allocating skilled mar-



keting, sales, and service staff to perform the highest payback tasks or to support your best customers,

supporting basic tasks and less than best customers through customer self-service interactions.

Customer-Facing CRM Applications Application Description

Contact Center Contact center applications are telephony applications that support marketing, sales, and service—all the CRM business processes. These applications implement telemarketing, telesales, and teleservice functions. Telemarketing is usually an outbound activity—your telemarketing reps contact your customers. Teleservice is typically an inbound activity—your customers contact your support center and speak with your customer support reps. Telesales may be either an inbound or outbound activity. Telemarketing presents offers to leads, prospects, and customers using predefined scripts. Telesales presents product information and quotes to prospects and customers or responds to customer requests with product information and quotes. Teleservice responds to requests with service in-structions found in a knowledge base or with incidents that represents requests for ser-vice that can’t be handled through the contact center.

Sales Force Automation

Sales force automation (SFA) applications support the selling efforts of your sales force, managing leads, prospects, and customers through the sales pipeline or sales funnel metaphors.

Field Service Automation

Field service automation applications support the customer service efforts of field service reps and service managers. These applications manage customer service requests, ser-vice orders, service contracts, service schedules, and service calls. They provide plan-ning, scheduling, dispatching, and reporting of field service reps for service calls.

Table A. The three key customer-facing CRM applications are described in this table.

Customer-Touching CRM Applications

Application Description

Campaign Management

Campaign management applications automate marketing campaigns. They present of-fers to targeted leads, prospects, and customers on demand, on a schedule, or in re-sponse to business events through direct mail, email, contact center, field sales, and Web touchpoints. Ideally, these applications should be able to record responses to of-fers.

Electronic Commerce

Electronic commerce applications implement marketing, sales, and service functions through online touchpoints, most typically the Web. These applications let sellers market products through online catalogs and associated Web content. They let customers shop for products through a virtual shopping cart metaphor and purchase the products in their shopping carts through a virtual check-out metaphor. Customers may also perform self-service support tasks such as order status and history inquiry, returns processing, and customer information management.

Self-Service Customer Support

Self-service customer support applications let customers help themselves to product support information, create service requests, manage information about themselves, and manage their orders.

Table B. The three key customer-touching CRM applications are described in this table.


What Is CRM? • 7

However, customer-touching applications must have excellent performance and provide a great cus-tomer experience. This isn’t as vital for customer-facing CRM applications because your great reps can insulate customers from not-so-great applica-tions.

Customer-Centric Intelligence Applications

Customer-centric intelligence applications are analytic applications that analyze the results of op-erational processing. Their results can be used to improve the efficiency and effectiveness of opera-tional CRM applications. Customer-centric intelli-

gence (what we have, in the past, called Customer Intelligence) is the term we use to describe cus-tomer-focused analytic functions, but you might be calling these same applications business intelligence, decision support systems (DSS), or analytic CRM applications. The name is less important than their capabilities. These capabilities, described in Table C, should include these high-level functions:

• Data warehousing • Reporting • Analytic applications

Customer-Centric Intelligence CRM Applications


Data Warehousing Data warehouses provide the input to customer-centric intelligence applications. Data warehouses that support these applications must contain:

• Customer information used by all operational CRM applications

• Customer information used by analytic applications such as customer values and customer scores

• Information about your products and services

• Information about the channels and touchpoints through which you offer prod-ucts and services

• Information about your marketing, sales, and service initiatives

• Information about customer behavior in response to those initiatives

• Information about customer requests

• Information about your responses to customer requests

• Information about customer transactions.

Reporting Reporting presents the information that you have loaded into the data warehouse in order for managers and analysts to view and analyze it. Reports provide a range of tabular and graphical presentation formats and optionally allow analysts to interact with the report presentation, changing its visual format, drilling up into summary information and/or drilling down into detail. Reports support manual analysis.



Customer-Centric Intelligence CRM Applications (continued)


Analytic Applications Analytic applications automate both the analyses that managers and analysts perform manually on reports and analyses based on statistical and pattern recog-nition algorithms. Analytic applications process data warehouse data, whereas reports merely present that information. Analytic applications are your tools for analyzing the performance, efficiency, and effectiveness of your operational CRM applications. Their output should enable you to improve the operational applica-tions that deliver your customer experience in order to achieve the CRM objec-tives of acquisition, retention, and growth. For example, analytic applications may be designed to provide insight into customer behavior, requests, and transactions as well as into customer responses to your marketing, sales, and service initia-tives. Analytic applications also create statistical models of customer behavior, values of customer relationships over time, and forecasts of customer acquisition, retention, and desertion.

Table C. The three key components of customer-centric intelligence CRM applications are described in this table.

DATA WAREHOUSING. Customer-centric intelli-gence applications depend on a data warehouse for input. The data model required for customer-centric intelligence applications is likely to differ from your existing data warehouse schemas in the areas of cus-tomer information, customer behavior information, and information about your marketing, sales, and service initiatives.

REPORTING. Reporting is the tried-and-true ap-proach for understanding your customers. You probably have your favorite reports and your favor-ite formats. Your colleagues or your counterparts in other business areas have their favorites. These dif-ferences and different approaches to analysis may no longer work when you become a customer-centric company. You must have a single view of your cus-tomers and provide a consistent experience to all of them. Thus, you must be generating and reviewing reports on a consistent set of information throughout the organizations.

ANALYTIC APPLICATIONS. Analytic applications should reflect the way that your organization ap-proaches analysis. Some organizations rely on statis-tical analysis and disdain data mining approaches such as clustering or neural networks. Other organi-zations distrust everything except the empirical in-formation in the data warehouse. Look at analytical applications as your tool set for understanding your customers. It should contain a wealth of tools, some of which you may never use.

THE CRM PLAYERS

Implementing CRM applications with the goal of becoming a customer-centric company will likely involve purchasing application software packages. Building your own applications is not a viable nor practical option given the breadth, depth, and quality of available packages. There are three types of CRM software suppliers:

• CRM suite suppliers • CRM point solution suppliers • Ecommerce suppliers

CRM Suite Suppliers

CRM suite suppliers offer a suite of CRM prod-ucts that implements all the key customer-facing, customer-touching, and customer-centric intelli-gence applications. While application functionality varies across the suite, some products offering richer functionality than others. Suites usually have the advantages of providing a single and consistent view of the customer, integration across touchpoints, a single architecture, and support from a single ven-dor. The leading CRM suite suppliers are (alphabeti-cally) Oracle, PeopleSoft, Siebel, and SAP. E.piphany also provides a CRM suite that imple-ments all the CRM applications except ecommerce as do a number of smaller players such as Talisma. Oracle, PeopleSoft, and SAP have the additional advantage of tight integration between CRM appli-


What Is CRM? • 9

cations and their ERP and supply chain applications, facilitating the automation of the business processes that support marketing, sales, and service.

CRM Point Solution Suppliers

CRM point solution suppliers offer products that implement one or two CRM applications. The ad-vantages of a point solution approach are the ability to implement best-in-breed functionality and the ease of adding incremental applications to existing CRM environments. There are dozens of CRM point solution suppliers. For example, NCR and Unica offer products that implement customer-centric intel-ligence applications. MarketFirst and Revenio spe-cialize in marketing automation solutions, and com-panies such as SalesLogix focus on SFA tools.

E-Commerce Suppliers

Ecommerce suppliers provide, obviously, the customer-touching ecommerce application, and their offerings are far richer in ecommerce functionality than the ecommerce offerings of CRM suite vendors. In addition, the latest versions of their products package campaign management, contact center, and customer-centric intelligence capabilities—everything except sales force and field service auto-mation, and the product support aspects of contact center. They also all do an excellent job of integrat-ing external applications and automating supporting business processes. We’ve been following ecom-merce since 1996. The leading suppliers and prod-ucts are (alphabetically) ATG Dynamo, Blue Martini 4, BroadVision Business Commerce and Retail Commerce, IBM WebSphere Commerce Suite, and Microsoft Commerce Server.

Selecting CRM Products

Given the array of supplier types, the very large number of available products, and the strategic na-ture of the applications that they implement, your selection of CRM products is a critical and poten-tially complex decision. These are the critical deci-sion factors to consider when making your product choices:

• FUNCTIONALITY. What the products do should closely reflect the way that you do busi-ness.

• SINGLE AND CONSISTENT CUSTOMER VIEW. The products should minimize your ef-forts to integrate and synchronize customer in-formation.

• INTEGRATION ACROSS TOUCHPOINTS. You’ve got to provide a consistent customer ex-perience. You don’t want to code it yourself.

• AUTOMATION OF SUPPORTING BUSINESS PROCESSES. The tighter the integration with back office and supply chain systems, the better the customer experience. This integration is about the most complex task in CRM implemen-tation. The more that’s “in the box,” the better.

HOW TO SUCCEED WITH CRM

Implementing the CRM products that you select, and becoming customer centric through their inte-gration and usage, are complex and strategic efforts that should touch every aspect of your organization. CRM projects require careful planning and meticu-lous execution. Here are a few key points to remem-ber:

• Adopting a customer-centric philosophy and implementing CRM products will involve major cultural and organization change. You will meet a lot of resistance.

• CRM products automate business processes and tasks that you might never before have auto-mated. They introduce additional organizational change and, perhaps, technological change.

• CRM should be enterprise-wide in scale and scope. Few organizations have the staff, skill, and budget to do it all at once. Take an incre-mental approach, one CRM application at a time, following a CRM pilot that you know will succeed.

• Many CRM products are new. You might be a pioneer for technology, products, and/or suppli-



ers. There are significant rewards for pioneering, but there are significant risks, too.

• Supplier claims and user expectations for CRM can be unreasonable. Be skeptical of vendor claims. Have vendors prove their claims with references. Take small steps toward customer-centricity and have reasonable and demonstrable expectations for those steps.

CONCLUSION

Improved Satisfaction, Increased Business

And finally, here’s the bottom line reason for “doing” CRM (answer “f” in our multiple choice quiz). CRM truly is a way to improve customer sat-isfaction and increase business. If you offer products and services that customers need (at a fair price), then they’ll do business with you. If you make doing business with you an easy, efficient, responsive, and quality experience, then those customers do business with you over and over again. They become loyal customers, and you have profitable relationships with them. Remember that you must continuously earn their loyalty, never taking these customer rela-tionships for granted. The continuous effort to earn loyalty will help maintain your customer focus and will grow those relationships. That’s CRM.



What’s Important in CRM Architecture? A Framework for Evaluation and Comparison


NETTING IT OUT While you should select a CRM product primar-ily on its functionality, its architecture should be a key consideration in your decision. Why? Be-cause a CRM product’s architecture will signifi-cantly influence the quality of the customer ex-perience that your CRM systems provide. It will determine how easily a new CRM application fits into your existing operational and analytic application environments. And it will be a major factor regarding the time and cost to implement a CRM application.

We’ve created a framework to help you evalu-ate the architecture of individual CRM and/or e-CRM products and to facilitate their comparison with the other CRM products on your short list. Our framework has six evaluation criteria: envi-ronments, organization, infrastructure, struc-ture, customization, and integration.

This report describes and discusses the evalua-tion criteria of our framework for CRM architec-ture.

WHAT IS ARCHITECTURE?

Architecture examines how products are built, how they’re deployed, how they can be customized, and how they can be integrated with external appli-cations. You should select a CRM product primarily on its functionality, but its architecture should be a significant influence on your decision. For example, the examination of architecture will let you under-stand: how well a CRM product will fit easily into your existing environment, whether it uses well-

proven and widely-used technologies, how easy it is to customize, and what it takes to integrate with your existing business systems and the business systems of your customers and suppliers.

We’ve been examining architecture for a long time. Over the years of evaluating many types of software products, we’ve created and refined an ap-proach that considers six areas of architecture. The approach has demonstrated the ability to identify differences among products, and those differences are the key to helping selection decisions. The six areas are:

• Environments, which are the Web servers, server platforms, and databases that a CRM product supports.

• Organization, which identifies a product’s ma-jor components and the interfaces between them. Interfaces are always between two components)

• Infrastructure, which is the set of runtime ser-vices that support request handling, application processing, and database access.

• Structure, which is what’s inside the product’s major components, particularly the Web pages, application logic, and database.

• Customization, which is the adaptation of the components to address site-specific require-ments.

• Integration, which complements and completes processing with the functionality of external ap-plications.

Customer Scenario and Customers.com are registered trademarks and Customer Flight Deck and Quality of Customer Experience (QCE) are service marks of the Patricia Seybold Group, Inc. • 210 Commercial Street, Boston, MA 02109 USA • www.psgroup.com


In this report, we’ll examine each of these areas, describing them in more detail, and presenting, in general terms, how CRM products should implement them.

Customer Data Model Key for CRM Architectures

For CRM products, one of the most important aspects of architecture is their customer data model. Customer data models are the key element of a product’s structure. They will determine, to a large extent, the customer-centricity of the product, the ease or difficulty you’ll have in integrating a new CRM product with your existing applications, and the quality of the customer experience that you’ll be able to provide.

ENVIRONMENTS

Environments are the simplest architectural crite-ria to evaluate in your CRM product selection deci-sion process and can be the easiest differentiator. Environments are the Web servers, server platforms, and databases supported by a CRM product. You shouldn’t change server platforms and database standards to accommodate a new CRM product. You’ve likely made too large an investment in par-ticular products to even justify a change. So a CRM product must support the environments that are al-ready supported by your organization. Table A lists the leading suppliers for CRM environments. Illus-tration 1 shows them visually.

ORGANIZATION

A product’s organization is the set of its major, components, the interfaces between them, and the protocols they use to communicate. It’s also the way to describe or characterize an architecture. For ex-ample, to characterize the architecture of a fictitious “product A,” we would say that product A is built on a three-tier, Web-based architecture.

You can get a feel for a product’s availability, scalability, and manageability by examining the number and types of components and how they communicate with each other. Look for products that are coarsely granular with several components from both organization and structure perspectives, not so few components as to make the product monolithic, nor so many of them as to make difficult to imple-ment and maintain. Look for interfaces that are stan-dards-based and that support replication and distri-bution, characteristics that promote reliability and scalability.

Most operational and analytic CRM products fol-low the example of fictitious “product A.” They’re built on three-tier, Web-based architectures. Ana-lytical CRM products follow three-tier client/server architectures as well as Web architectures. With fewer concurrent users and more intensive process-ing and database access, client/server architectures are not necessarily a disadvantage for the deep analysis functionality of these products, but they are a disadvantage when it comes to displaying the re-sults of analytics or in using these to drive dashboards.

CRM Architecture Environments

Environment Leading Suppliers

Web Servers • Apache • IPlanet (Sun) • Microsoft

Server Platforms • Microsoft Windows NT/2000 • IBM AIX • Hewlett-Packard HP-UX

• Sun Solaris • Compaq Tru64 Unix

Databases • IBM DB2 UDB • Microsoft SQL/Server 2000 • Oracle 8i, 9i

Table A. The leading suppliers of the key environments for CRM product are listed in this table.


What’s Important in CRM Architecture? • 13

CRM Environments

IBMMicrosoft

Oracle

ApacheMiscrosoft

iPlanet

Compaq Tru64Hewlett-Packard HP-UX

IBM AIXMicrosodt WindowsNT/2000

Sun Solaris

Web Servers

Server Platforms

Databases


Illustration 1. This illustration shows the environments criterion of CRM architecture and the leading suppliers for Web servers, server platforms, and databases.

In general terms, CRM products have the follow-ing types of components in their three tier organiza-tions:

• Clients • Application server • Database

In all the products that we’ve seen, CRM clients are always thin clients, either Windows desktops or Web browsers. We describe them as thin because they handle only the presentation of CRM applica-tions. All processing is handled in the application server. Among the Web-browser clients, there’s re-

cently been a lot of noise by CRM suppliers about exactly how thin their clients are. Oracle claims it has 100 percent Internet clients. PeopleSoft touts its “pure Internet” clients. Siebel has begun pushing the “smart Web clients” of Siebel7.

What’s the difference? Not really that much. The clients in the PeopleSoft Internet Architecture are just HTML—no client applets or components, no client-side script. They have the advantages of maximum portability, the lowest bandwidth utiliza-tion, and the minimum client processing. Siebel7 clients are DHTML, D for dynamic. They’re richer and more interactive than HTML clients at the cost of some client-side processing.



The clients in Oracle E-Business Suite 11i are made up of HTML, JavaScript, and Java applets. They’re visually richer than PeopleSoft and Siebel clients, and they also provide more interactivity. However, the addition of Java applets can increase latency and client overhead.

Clients should provide a visually rich and inter-active environment. These characteristics make for a superior customer experience. However, they can also be the cause of slow response and a less–than-intuitive user interface, which can ruin that superior customer experience. On balance, we prefer clients that offer the potential for visual richness and high interactivity, but that can be configured to optimize latency and response.

Application servers are the most complex com-ponent in organization because they perform all ap-plication and system processing. They manage user requests, providing appropriate security, routing, and dispatching. They control the execution of applica-tion logic and database access that represents the response to user requests. And they return these re-sponses to the user. Application servers most typi-cally perform a broad range of functions: the transfer requests and responses with users, application proc-essing, security, request management, dispatching, memory management, process management, data-base access, access to external systems, load balanc-ing, failover, and many others.

Application Servers handle the transfer of re-quests and responses. The application, itself, does application processing and database access. Web application servers handle the processing for all the system functions. We’ll discuss application servers in more detail in the section, “Infrastructure,” below.

Recently, we’ve seen a trend toward handling re-quests and responses and security through portals that are implemented between Web servers and the application. Portals provide infrastructure through which users can access a range of applications and data. They offer an advantage for CRM applications because users typically access multiple CRM appli-cations, view a range of reports, or examine business performance across many dimensions through a dashboard. They don’t invoke just one application and work within its UI; doing their jobs requires them to bounce in and out of multiple applications and to access a range of information. Portals provide application and data integration at the UI-level. All

of the CRM suite suppliers, as well as the ecom-merce suppliers, offer portal-based UIs.

CRM databases have three dimensions. The first supports operational applications. The second sup-ports data warehousing-based analysis. The separa-tion between operations and analysis is as important for CRM as it has been for ERP and supply chain applications. The third database dimension supports design and development for configuring and custom-izing CRM applications as well as for integrating them with external applications.

Illustration 2 shows this general CRM product organization.

INFRASTRUCTURE

Infrastructure provides system-level, application-independent services for multiuser, shared resource systems like CRM applications. The services include basic request handling, queuing, routing and dis-patching, process and thread management, memory management, database connection management, and transaction management as well as the more sophis-ticated recovery/restart, failover, and load balancing. All of these (and more) are required for the proper operation of CRM and other applications.

CRM products should leverage the services of commercial infrastructure products, such as J2EE Web application servers or the Microsoft .NET in-frastructure for Internet applications. We hope that the days of product-specific, proprietary infrastruc-tures are over. We feel strongly that CRM vendors, especially the smaller ones, should focus on CRM functionality and leave infrastructure to vendors in the infrastructure business. Illustration 3 shows CRM infrastructure visually.

Handling Product Legacies

While J2EE and .NET provide excellent infra-structures for the middle tier application server com-ponent of CRM applications, both are relatively new technology. Many CRM suppliers have been offer-ing their CRM and other application products for many years longer than J2EE and .NET infrastruc-tures have been available and viable. Major modifi-cations to organization and application logic would be required for these suppliers to deploy their appli-cations on modern infrastructures. Such a move



CRM Organization

Application Server

Server Platforms

Database

Client

Web Browser


Illustration 2. Most CRM products follow a similar organization of clients, application servers, and databases. That organization is shown in this illustration.

would be extremely disruptive to their customers, not to mention being a significant R&D investment. For example, PeopleSoft CRM applications are writ-ten in C++ and deploy on a BEA Tuxedo infrastruc-ture. mySAP CRM applications are written in SAP’s ABAP 4GL and deploy on a proprietary infrastruc-ture. (With 17,000 customers, this infrastructure might be described as an industry standard.)

Rather than redeveloping their applications on new technologies, the CRM suppliers with long legacies and large customer bases are implementing the new technologies around the edges of their ap-plications. PeopleSoft uses J2EE to handle the UI of its applications and provides the mechanisms to cus-tomize application functionality through Java com-ponents and to integrate external applications through XML interfaces. In addition, and very im-portantly, the major CRM suppliers have all an-nounced that they will expose the functionality of

their CRM (and ERP and supply chain) applications as Web services and will support the key standards of WSDL, UDDI, SOAP, and XML to enable their discovery, access, and integration.

Many suppliers of analytic CRM products also have product legacies. There’s a lot of C++ and cli-ent/server among their offerings. They’re also mov-ing to the modern Web infrastructures at the edges, UI first.

This legacy preservation approach is a good one. Take care, though, to make sure that the implemen-tation of the new, hybrid infrastructures insulates you from complexity and cost. Look for products that bundle the old and the new application function-ality and infrastructure in a single, integrated pack-age at a single price, and avoid products that require you to purchase, implement, and support separate, infrastructure-specific components.



CRM Infrastructure

Server Platform

Database

Web Browser

Client

Web Application Server

ProgramLogic

Data Model

SystemServices

DatabaseAccess Portal

Application Server


Illustration 3. This illustration shows CRM infrastructure.

Note that, on the other hand, most of the leading ecommerce suppliers offer J2EE or .NET based products. Those suppliers with legacies, such as BroadVision, have taken an at-the-edges approach to new technology.

STRUCTURE

By structure, we refer to what’s inside the major components of a CRM product’s organization, how they’re built and what they’re made of. CRM prod-ucts with three-tier, Web-based organizations, have three types of components that define and describe its structure:

• Web pages

• Program logic (for both application functionality and application services functionality)

• Data Model

Knowing a product’s structure can give you an idea of the skills, effort, and additional resources that you will require to implement, customize (everyone does some customization, especially with CRM products), support, and maintain the product as well as to integrate it with external applications. When the structure of a product’s Web pages, program logic, and data model is based on standard and popu-lar technologies, and when its program logic is im-plemented as coarsely-grained components, your work is simplified.



Web Pages

There are standards for the structure of Web pages. Within J2EE infrastructures, Web pages are built on the Java Server Page (JSP) specification that combines HTML, JavaScript, and Java applets. Within .NET infrastructures, Web pages are built on the Active Server Page (ASP) structure that com-bines HTML, VBScript or JavaScript, and COM components. JSPs and ASPs are quite similar. They support dynamic, visually-rich, and highly-interactive Web pages.

The CRM product that you select should support either of these industry standards. Both are mature, well-proven, and widely-used. Avoid products that combine HTML with proprietary tags. Note that some CRM products imple-ment JSPs but, in order to simplify administration and to maximize performance, do not include applets within Web page structure. (ASP-based products would analogously not include COM compo-nents.) We’ve discussed these approaches within the section, “Organization,” above. Note also that DHTML is not as widely used as JSP or ASP.

Program Logic

The structure of a CRM product’s program logic should be coarsely-grained components. Compo-nents are object-oriented structures that have inter-faces and implementations. A product should not have so many components as to make finding an individual component hard to do in order to facilitate configuration, customization, and integration. There should not be so few as to make a product mono-lithic. The supplier should publish the interfaces of all a product’s components. That’s essential for cus-tomization and integration. Also, to maximize scal-ability and performance, components should be or-ganized into stateless components that provide the e-CRM services and stateful components that store and manage the information that changes as a result of performing the services.

JAVA? Components are implemented in a program-ming language such as Java, C++, or a 4GL. Java

has become something of an industry-standard lan-guage for the program logic of Web applications.

Java has significant advantages, but it’s not a re-quirement for CRM program logic. It’s a low-level language. For example, Visual Basic is easier to learn and easier to use, and it supports component-based development. Second, as with their infrastruc-tures, many CRM products have non-Java legacies for the structure of their program logic. Suppliers and customers are frequently better off leveraging their investments in legacy technologies. Third, many suppliers, including many with non-Java lega-cies, such as PeopleSoft and SAP, generate compo-nent-based program logic from metadata specifica-tions. Developers almost never touch code, working instead with easier-to-understand metadata code de-

scriptions.

BUSINESS RULES. Business rules represent an organiza-tion’s policies and business practices. They qualify an op-erational CRM application’s program logic at runtime at key points during processing.

Like application logic, business rules should also be implemented as coarsely-grained components that integrate seamlessly with the components that im-plement application logic. However, the components that implement business rules are developed and de-ployed separately from program logic so that they can be modified independently. Their development environment should be visual and easy to use so that business managers, not developers, may specify them. Their tools should provide easy-to-use de-ployment mechanisms because you’ll change them frequently.

The deployment approach is not ideal because business rules

and program logic are not in separate modules, but it works.

In practice, we’ve seen among the large CRM suite suppliers that business rules are specified and implemented within the metadata of CRM applica-tions. The metadata is then used to generate applica-tion modules or components which combine pro-gram logic and business rules. As a result, changing business rules requires regenerating the entire appli-cation module. Metadata development environments are quite visual, and it’s usually quite clear how to make business rules changes. The deployment ap-proach is not ideal because business rules and pro-gram logic are not in separate modules, but it works.



ANALYTIC APPLICATIONS. It’s critical that op-erational CRM applications have component-based program logic. You will be customizing them and integrating them with external applications. It’s far less important that analytic applications have these same structural characteristics for program logic, mostly because they’re not typically customized or integrated.

Data Model

A data model is an application’s logical represen-tation of the information that it processes. Data models for CRM, ERP, and supply chain applica-tions represent the business entities involved in the processing that they perform. For example, a supply chain application’s data model will typically repre-sent catalogs, products, purchase orders, invoices, advanced shipping notices, and the like. Most sig-nificantly, the data models for all these applications represent customers. Their customer data model is their architectural key to customer-centricity.

Customer Data Model

CRM products should help you become a more customer-centric organization. From the perspective of architecture, a CRM product’s or product suite’s customer data model is a critical element in evaluat-ing the customer-centricity of that CRM offering. Remember that being customer-centric enables your business to be driven primarily by your customers, not by your internal processes and requirements. Your goal is to provide the best possible experiences for your customers whenever and wherever they in-teract with you (directly, through the contact center, through the Web, or through email). The best ex-periences result in the most satisfied and loyal cus-tomers, and the most satisfied and loyal customers are willing to do more business with you.

So how does a customer data model enable cus-tomer-centricity? It’s absolutely true that the better you know your customers, the better the relation-ships that you can create with them, the more satis-fying those relationships can be for your customers, and the more profitable those relationships can be for you. It follows that the better the customer data model of your CRM systems, the better your CRM systems will embody your knowledge of your cus-

tomers. But what makes a “better” customer data model? We believe that there are four factors:

• Richness • Openness • Flexibility • Consistency

The customer data model is actually the metadata that describes your customers and their relationships with you. The model is implemented within opera-tional CRM systems in a manner that maximizes responsiveness for concurrent, shared access and supports online transactions. The model should also be implemented in customer-centric intelligence sys-tems in a manner that both facilitates the execution of analytics and maximizes complex query perform-ance.

RICHNESS. Richness is the key factor. By richness, we mean the amount of information in the customer data model and the breadth and depth of that infor-mation in representing every possible aspect of your customers’ identities, their business relationships with you, the transactions between them and you, and the marketing, sales, and service interactions among you. This information will differ slightly for B2B and B2C customers. Table B lists and describes through examples the important characteristics of customer data model richness.

Customer data model richness is mirrored by equivalently rich functionality, and functional rich-ness is one of the major reasons that you select a particular CRM product or suite. Also, the more that’s predefined, the less that has to be modified or extended, and the easier it may be to integrate and synchronize customer information with existing ap-plications.

Customer data is the most private and sensitive information that you manage. Access to it should be very carefully controlled. We like schemes that pro-vide role-based access with privilege levels that con-trol the operations that can be performed within roles. Customers should have the appropriate roles and privileges to access the data that you manage about them. They should even be able to update and delete some of it. On the other hand, most marketing information should be protected from customer ac-cess.



Richness of Customer Data Models Richness Characteristic Description

Identification Identification information should include name (salutation, first, last, title, qualifier, nickname), address (sold-to, bill-to, ship-to addresses), company, company or-ganization, company organization relationships (regions belong to divisions, for example), and company organization person contact for B2B, household and household relationships for B2C, preferences, demographics for B2C.

Relationship Relationship information represents the terms and conditions of any ongoing busi-ness between you and your customers. For B2B relationships, this information represents the contracts between you and your customers. Contracts have prod-uct, price, quality of service, and payment terms. They are associated with a cus-tomer’s organizational entity, and they have identification, role, and authority infor-mation for contacts and administrators (different than identification contacts). For B2C relationships, this information might represent warranties or service contracts that include product, price, and quality-of-service terms, as well as contact identifi-cation information.

Marketing Marketing information should include customer value, customer profitability, the segments to which a customer belongs, and scores and indicators for loyalty, satis-faction, recency, frequency, and wallet share, It should also include a history of all the campaign offers that you’ve made to the customer and the customer’s re-sponses to those offers.

Sales Sales information should include the quotes and proposals that you’ve made to customers and the orders that your customers have placed with you. It should in-clude complete quote, proposal, and order histories, all quote, proposal, and order details (as you represent them), and an indication of the touchpoint with relevant touchpoint information such as sales rep through which each quote, proposal, and order was placed.

Service Service information represents your customers’ requests and your responses for product support and service, order management actions such as returns and com-plaints, and customer management actions such as identification information changes. This information should include outstanding requests and their priority, the histories and details of these interactions, the touchpoints through which they occurred, and identification information of relevant personnel.

Table B. Key characteristics of customer data model richness.

OPENNESS. The customer data model should be made available to you. You and your developers can study its design in order to facilitate customization and integration. Your customers are being repre-sented within this data. You should understand that representation in detail.

FLEXIBILITY. You should be able to modify and extend the customer data model in order to address your business requirements. You should reflect the customer data models of your other operational ap-

plications as they are integrated with new CRM products in order to provide a consistent customer experience across all touchpoints and business proc-esses. You must, of course, provide the functionality to reflect these modifications and extensions.

CONSISTENCY. For operational CRM applications, the customer data model and the values of its attrib-utes must be accessible consistently across all the touchpoints through which you interact with your customers and across all your CRM applications.



You want to be able to treat your customers the same way no matter how they decide to interact with you. For analytic CRM applications, the customer data model and the values of its attributes must be consis-tent across all data warehouses and data marts. The conclusions that you draw about historical customer behavior, the predictions that you make about future customer behavior, must have a common and consis-tent foundation.

CUSTOMIZATION

All CRM applications get customized. In fact, all operation applications get customized to reflect the characteristics and nuances of implementing a com-pany’s business processes and information struc-tures. We’ve heard you say it. “We’re from (name of your company), and our requirements are unique.” You customize application software packages in or-der to address those unique requirements. What gets customized are the elements of an application’s structure, its Web pages, program logic, and data model.

We differentiate customization from configura-tion. CRM products are designed to be configurable. Configuration changes application processing from the outside in, typically through the specification of predefined parameters. Customization changes the way those parameters are handled from the inside out or even specifies new parameters to be specified.

ANALYTIC APPLICATIONS. While operational CRM applications are almost always customized, generally, analytic applications are not. You don’t change their program logic (which is frequently pro-prietary intellectual property), and their user inter-face and data models are designed to be configured to address your requirements.

Customization Tools

Customization tools are development tools. The same tools that you use to create Web pages, code application logic, and implement a data model in a database are used to customize CRM products. For example, customizing a JSP requires an HTML edi-tor, script editor, and, if the JSP includes applets, a Java coding tool or development environment. When the CRM product’s structure is built on standard or popular technologies, there’s a wide range of tools for its customization.

When a CRM product is built on proprietary structures, you’re forced to use the supplier’s tools for customization. That’s not a disadvantage if you’ve already invested in other products from that supplier. It can be a significant disadvantage if you haven’t. When structure is metadata driven, such as it is for PeopleSoft, SAP, and Siebel CRM products, that disadvantage is mitigated to some extent.

INTEGRATION

CRM systems provide a business with a wide range of customer-touching and customer-facing functionality. CRM products must be customized to reflect the look and feel, business processes, and information structures of the companies that imple-ment them. The products also require integration with both internal and external business systems in order to automate business processes.

By internal business systems, we mean your other operational CRM applications and your back-office systems, as well as your data warehousing and analytic applications. By external business systems, we mean the CRM systems of your sales and mar-keting business partners and the back-office systems of your suppliers. For example, an ecommerce ap-plication should provide integration with inventory systems in order to present availability and lead times to online shoppers and customers. A contact center system should provide integration with order management systems so that customer service repre-sentatives can answer customer questions about cur-rent order status or historical order details. In addi-tion, it is becoming increasingly important to inte-grate with the external business systems of custom-ers and suppliers—a seller should be able to receive and process purchase orders from its customers, sending back a purchase-order acknowledgement; similarly, a seller should be able to have the same exchange with its suppliers.

Most significantly, CRM products should provide an integrated view of your customers, collecting cus-tomer information from its numerous and heteroge-neous sources and providing consistent access across all applications. CRM suites can address this re-quirement more easily than point products that im-plement individual applications because suites “own” more of the customer experience and likely have roots in ERP and supply chain applications which own even more. While integration of cus-



tomer data is a key requirement, it is your hard data integration and synchronization work that will ad-dress it.

• Packaging of integration technologies and prod-ucts that minimize development.

Selecting a CRM product from one of the leading suppliers can have significant advantages in integra-tion. The market influence of these suppliers has resulted in many other CRM suppliers and all the integration suppliers offering integration with their offerings. Integration with PeopleSoft, SAP, and Siebel is provided in this manner.

Integration Is a Critical but Complex Task

Integration is one of the most difficult tasks that you’ll face in implementing CRM products. To ad-dress this issue (and the business opportunity that it represents), the industry has spawned an integration market. There are many integration technologies and products available. There are emerging standards in messaging protocols and business process specifica-tions. Integration is becoming easier as more com-panies recognize the business benefits of responsive customer service and supply chain management, but don’t underestimate its complexity and the time and effort needed to do it effectively.

ANALYTIC APPLICATIONS. For analytic applica-tions, integration is not as important an evaluation criterion. Analytic applications are typically not linked into automated business processes. Rather, most of them execute in separate, offline data ware-housing environments. However, we are seeing the use of analytics in line with operational applications to implement realtime analysis is areas such as cross-sell, up–sell, and retention. Realtime analytics are only effective if they can be integrated with op-erational applications and integration approaches, requirements, and issues are those discussed above.

Look for integration capabilities in CRM prod-ucts that implement operational applications that simplify integration tasks through:

• A range of integration approaches—synchronous, realtime program-to-program inte-gration, asynchronous, message-based integra-tion.

CONCLUSION

Architecture should be a significant factor in your selection decision for CRM products, both op-erational products that implement customer-touching and customer-facing applications and analytic appli-cations that help you understand your operations and improve their efficiency and effectiveness. Using the six criteria of our framework for evaluating the ar-chitecture of CRM products can optimize and shorten your selection process.

• Integration of both internal business systems and external customer and supplier systems.

• Support of integration standards such as XML and, minimally, plans to implement functionality as Web services. (We’re still early in the imple-mentation and adoption of Web services.)



What Are Customer-Centric Analytic Applications? A Framework for Evaluation and Comparison


NETTING IT OUT Customer-centricity is an approach to doing business that ensures that you retain and grow your best customers. Customer-centric analytic applications are tools that can help you become more customer-centric. They can help you un-derstand your customers and improve the effec-tiveness of your customer experience to make your customer relationships stronger and more profitable.

Selecting the customer-centric analytic applica-tions that are best for your company can be a complex and risky process. There are dozens of technologies and products that are described as analytic applications, and all of them promise to deliver the benefits of customer-centricity faster, cheaper, and simpler than the next.

This report documents a framework of criteria that you should use to evaluate customer-centric analytic applications and to compare those evaluations in order to make optimal product selections. Our evaluation framework looks at four dimensions of customer-centric analytic applications:

• Functionality • Architecture • Product marketing • Company viability

ANALYTIC APPLICATIONS AND CUSTOMER-CENTRICTY

Customer Centricity Is the Best Strategy in These Tough Economic Times

Times are tough. In today’s economic climate, budgets—especially IT budgets—are extremely tight (and, many think, getting tighter), and ROI on new strategic systems must be achieved in six months or less or those systems are not acquired. Competition is brutal. Prices are being slashed and margins are disappearing as sellers fight for every deal. For so many companies, cost reduction has become a key strategy because it’s so hard to improve the top line.

Customer-centricity, a customer-focused ap-proach to doing business, can be a better strategy for today’s tough times. Why? Customer-centricity en-sures that you retain and grow your best customers. Thus, it’s a way to reduce costs; it’s far more costly to acquire new customers than to deepen business relationships with the ones you already have. Cus-tomer-centricity can reduce competition. Satisfied customers are loyal customers. They might even pay a little more for your products because they know that the service you provide is so good and creates value above simple price differences (and that im-proves your bottom line). Customer-centricity can even drive revenue, improving your top line. By knowing your customers and by streamlining your business processes from a customer perspective, you can offer the right customers the products and ser-vices that they need when they need them (and that results in more sales).


What Are Customer-Centric Analytic Applications? • 23

Customer-Centric Analytic Applications Are Tools to Help You Become More Customer-Focused

Customer-centric analytic applications are tools that can help you become more customer-focused. Their implementation and usage in your business can help you:

• Understand the behavior of your customers and how they prefer to do business.

• Understand the products and services that your customer need and the ones that they buy.

• Identify your best customers.

• Identify your most loyal customers.

• Understand how efficient and effective your marketing, sales, and service business processes, and the applications that implement them, are in addressing your customers’ needs.

• Tune your marketing, sales, and service business processes and the applications that implement them to better serve your customers.

• Understand what aspects of your back-end busi-ness processes and applications affect the Qual-ity of the Customer Experience (QCESM) your company delivers to customers.

• Improve and monitor the aspects of your back-end processes and applications that may ad-versely affect the QCE you deliver.

By helping make you more customer-centric, customer-centric analytic applications can become the mechanisms for understanding, strengthening, and growing the relationships that you have with the customers.

Yes, customer-centric analytic applications are those tough-to-justify strategic systems, but their benefits are significant and can be achieved rapidly, enabling you to justify the cost of their acquisition and implementation and to demonstrate ROI quickly. You should think of them as tools for creat-ing customer centricity.

Many Customer-Centric Analytic Applications, Many Claims

So, now that we have your interest in customer-centric analytic applications, here’s the catch. There are dozens of technologies and products that are de-scribed as analytic applications, and all of them promise to deliver the benefits of customer-centricity faster, cheaper, and simpler than the next. Identify-ing which ones of the dozens really are customer-centric analytic applications and, then, selecting the one that’s best for you can be a difficult, time-consuming, and risky process. We’d like to give you some help.

As we’ve done for so many other types of strate-gic software—visual application development tools, relational, object, and object/relational databases, electronic commerce servers, and Web-based query and reporting tools—we’ve created a framework-based approach to help you evaluate and compare customer-centric analytic applications. The objective of the approach is to shorten the time and reduce the risk for you by narrowing your section decision to a short list of two or three products. The approach is, itself, a framework of evaluation criteria to apply against customer-centric analytic applications prod-ucts. Our continuing research and analysis of tech-nologies and products, our work with the suppliers of these technologies and products, and, most sig-nificantly, our work with companies that can and have benefited by the implementation of customer-centric analytic applications are the foundations for specifying the criteria. Your use of the evaluation framework is reinforced by our evaluation of the leading and the innovative customer-centric analytic applications against the framework.

WHAT ARE CUSTOMER-CENTRIC ANALYTIC APPLICATIONS?

Types of Analytic Applications

In terms of classification, customer-centric ana-lytic applications belong to the business intelligence (BI) or decision support (DSS) domain (we use these terms synonymously). They’re not software that you use to do business. Rather, they’re software that you use to analyze business. Further, within BI or DSS, there are many types of analytic applications—



Customer-Centric Intelligence

Business Intelligence/Decision Support

Customer-CentricAnalytic Apps

Customer-CentricIntelligence

FinancialIntelligence

Reporting Data Warehousing

OperationalIntelligence


Illustration 1. Customer-centric analytic applications are one category of customer-centric intelligence tools. Customer-centric intelligence is a subset of business intelligence which focuses on customer-specific information.

customer-centric or CRM analytics, business opera-tions analytics, financial analytics, and supply chain analytics, just to name a few.

Because our interest, really our corporate focus, is on the customer, we consider the domain to be customer-centric intelligence, and we’re most inter-ested in customer-centric analytic applications, also commonly called CRM analytics or analytical CRM (see Illustration 1). Customer-centric analytic appli-cations are tools that help make you more customer-focused. Their usage can help you understand the performance, efficiency, and effectiveness of your operational CRM applications and of the other op-erational applications that impact your customers’ quality of experience. Their usage can also help you understand you Quality of Customer Experience (QCE). QCE is our approach to measuring and monitoring how your business processes and the sys-tems that implement them contribute to the service that your provide to your customers and with the level of satisfaction your customers have with that service.

Processing Sets them Apart

Processing is what makes analytic applications what they are. That is, they include program logic; they do computing. Processing differentiates analytic applications from reports. Beware of reports. They’re quite commonly positioned and marketed as analytic applications, but they’re not. Reports simply present information as it exists in a data source and allow users to interact with this presentation. Report-ing is a very important analytical tool, and, in fact, reports are commonly the output of analytic applica-tions, but reports themselves do no processing.

Processing defines analytic applications and gives them significant advantages. Processing in analytic applications, as in any applications, creates automation. Automation gives you speed, efficiency, and consistency in the analysis of operational sys-tems and in the decision-making that improves their efficiency and effectiveness Processing also im-proves the breadth, depth, scope, and scale of analy-sis.



The Operational/Analysis Cycle

Closed Loop

Operations Analytic Applications

ETL

Initial• Configuration• Attribute values• Processing parameters Refined from analytical

applications processing• Configuration• Attribute values• Processing parameters


Illustration 2. This illustration shows the operational/analysis processing cycle.

While we’re on the topic of processing, let’s dis-cuss OLAP. OLAP is a very useful analysis tech-nique. It’s the interactive, visual navigation of hier-archies of de-normalized information—drill and pivot, slice and dice. Many feel that OLAP is an ana-lytic application. Its operations are certainly analytic in intent. Many others feel that OLAP is a form of reporting. It simply presents information that exists in a data warehouse or data mart. We side with OLAP as a form of reporting. OLAP can’t provide the consistency of analysis possible with analytic applications because the decision-making of which path of analysis to follow is left to the user, not de-termined by program logic. But we’re not too un-comfortable calling OLAP a form of analytic appli-cation, although the lowest, simplest form. Analytic applications should do so much more than OLAP in terms of automation and depth of analysis, and, of course, consistency.

The Operations/Analysis Cycle

Customer-centric analytic applications are cus-tomer-centric intelligence applications they analyze the results of the operational CRM applications that you use to do business with your customers. Cus-tomer-centric intelligence applications work in a two-phased, closed-loop cycle with operational ap-plications. The two phases are operations and analy-sis. The loop between them is closed because, after an initial operational phase, the result of operations becomes the input to analysis, and the output of analysis is used to improve operations. Illustration 2 shows the operations/analysis cycle, its phases, and the flow of control and data between the phases to create the cycle.

Operational systems and analysis systems are separate. While they work together in a closed-loop cycle, they have separate execution platforms, proc-essing characteristics, data sources, data access char-acteristics, and types of users. Their purposes and



processing are most significantly different. For ex-ample, operational systems are designed to provide fast response to many concurrent users. They access and update small amounts of data and do short bursts of processing. That processing is often transactional in nature. On the other hand, analytic systems are designed to perform complex and long-running processing to a few concurrent users. During the processing, large amounts of data may be accessed, usually in read-only mode, with complex queries. Processing and database technology has yet to be developed that can balance between these two types of processing without compromising operational responsiveness or analytic performance. As a result, each should run in its own environment.

Real-Time Analysis?

Historically, it has always taken a long time to run analytic applications due to their complex proc-essing and access of large amounts of data. With new emphasis on customer-touching applications such as campaign management, ecommerce, and self-service customer support, as well the capability to interact directly with customers through these ap-plications or through contact center dialogs the con-cept of real-time analysis has cropped up. The idea behind real-time analysis is to provide optimized responses to customer requests as those requests are being made. Analytic applications do the processing to optimize those responses, and, because the re-quests made within an interactive dialog, the re-sponses must be made in real time.

In theory, real-time analysis is a great concept. It lets you take advantage of the precious time that your customers are in contact with you and makes the experience that you deliver to your customers the best that it can be. For example, you’re probably familiar with real-time analysis for cross-sell rec-ommendations within ecommerce applications. Based on what you have previously purchased, based on your customer profile, based on what oth-ers similar to your profile have purchased, or based on similar purchases, an ecommerce system auto-matically and in real time recommends cross-sells to you while you’re shopping or at the time of pur-chase.

In practice, real-time analysis can have signifi-cant disadvantages. Some analyses involve the exe-

cution of sophisticated algorithms that consume sig-nificant CPU resources. Other analyses involve the execution of complex queries requiring significant database processing and the retrieval of large vol-umes of data. Other analyses combine the two. Clearly, real-time use of these types of analyses would compromise a system’s responsiveness and result in a poor customer experience. On the other hand, there are analyses that are simple enough to be performed in real time. Our question about these analyses is whether they really add value to the cus-tomer experience. They might be so trivial that they add little value. You should try to seek a balance—understand the resources required to perform the analyses that really add value. If you can execute them in real time with a minimal impact on respon-siveness, then go for it. If not, execute them offline, and use their results in real time.

Another disadvantage of real-time analysis, espe-cially real-time analysis that results in the supposed improvement of operational systems, is that it may also change your marketing, sales, and service pro-grams and campaigns in real time. Take care not to change programs and campaigns before you’ve had a chance to measure and understand their effective-ness. Make sure that they run long enough so that you know whether they’ve succeeded or failed be-fore you change them.

Bottom line—take care in using real-time analy-sis.

Closed Loop?

We described the operational/analysis cycle as a closed-loop cycle. We don’t mean to imply that the cycle is automated. It may not always be possible to actually change operational systems with the results of analysis or the output of predictive modeling. It’s no easier to integrate an analysis system with an op-erational system than it is to integrate two opera-tional systems. More significantly, the potential to improve operational effectiveness should never compromise your change-management practices. Improvements must always be tested, promoted, and staged into production systems.



A FRAMEWORK FOR EVALUATING CUSTOMER-CENTRIC ANALYTIC APPLICATIONS

A Hierarchy of Dimensions and Evaluation Criteria

We have identified four dimensions for evaluat-ing customer-centric analytic applications. By di-mensions, we mean broad evaluation areas that serve to organize specific evaluation criteria. The evalua-tion framework is a hierarchy of dimensions and evaluation criteria within each dimension. The framework hierarchy is shown visually in Illustra-tion 3. The four dimensions of the customer-centric analytic applications framework are:

• Functionality

• Architecture

• Product marketing: product viability (customer base, length of usage), price, plans

• Company viability: customers, financials

FUNCTIONALITY

By functionality, we mean what customer-centric analytic applications do, the capabilities that they provide. Functionality is the most important evalua-tion dimension. How well a product provides the capabilities that you need should be your primary selection factor. Also, many customer-centric ana-lytic applications products will offer functionality beyond your requirements. This functionality makes products more attractive. While running your busi-ness on the basis of a product’s functionality is not a good idea, expanding your current analyses with these additional capabilities may help you become more customer-centric and more effective at being so.

There are five evaluation criteria within the func-tionality dimension:

• Analysis • Prediction • Business performance measurement • Business performance monitoring

• Output

Analysis

Analysis is the most important evaluation crite-rion with functionality. After all, analytic applica-tions do analysis. At a minimum, analysis capabili-ties should include:

• Segmentation and profiling

• Analysis of proactive customer behavior in mar-keting, sales, and service

• Analysis of reactive behavior in response to marketing and sales

• Analysis of transaction processing

These analyses should be supported for both B2B and B2C, and their functionality should support all touchpoints and all of your business systems. They should be customer-focused, enabling you to better understand your customers and the relationships that they have with you.

How these analyses are implemented and how many and what types of analyses are packaged within these general types can’t be specified as an evaluation criteria. There are just too many imple-mentations and too many analysis types that can ad-dress your requirements. As a result, look for prod-ucts that provide a broad range of analyses. At a minimum, the product should have the analyses that you currently use. The analyses include algorithmic processing such as statistics and data mining in order to uncover hidden or unsuspected aspects of your customers and to help you analyze large amounts of data.

With a broad range of analyses, it’s critical that products provide some guidance into what analysis to use for what purpose and how to interpret its out-put. Samples are a great aid for demonstrating these points to users.

Prediction

Where analysis is an approach to gaining insight from the historical results of operational processing, prediction uses both the output of historical opera-tional processing and the output of historical analy-sis to control key aspects of future operational proc-



Patricia Seybold Group Evaluation Framework for Customer-Centric Analytic Applications

ArchitectureFunctionality ProductMarketing

AnalyticApplications

CompanyViability

Customers

Finances

Price

Product Plans

ProductBackground

Installed Base

BusinessPerformanceMonitoring

BusinessPerformanceMeasurement

Analysis

Prediction

Infrastructure

Environments

Organization

Output Product Viability

Competition

Structure


Illustration 3. The Patricia Seybold Group evaluation framework for customer-centric analytic applications is shown in this illustration.

essing. For example, prediction is commonly used to estimate lifetime customer value, identify customers likely to desert, or identify customer most likely to respond to an email campaign offer. Prediction is another key evaluation criterion, although not as im-

portant as analysis and not as commonly found in analytic application products.

Prediction is implemented by several types of al-gorithms. Evaluating which type is best for a par-ticular customer-oriented purpose is beyond the



scope of this framework. Look for customer-centric analytic application products that support the types algorithms that you already use or that support a range of types.

Business Performance Measurement

Customer-centric analytic application products measure the business performance of your customer experience. Because their input represents all your customers, all your systems, and all your touch-points, they provide a 360-degree view of the entire experience. This type of performance measurement is based on metrics, which are sometimes also called key performance indicators (KPIs). KPIs include average order size, average time between orders, number of complaints, frequency of complaints, and so on. You should determine the metrics for the unique customer experience that you provide, but customer-centric analytic applications will typically package most of those metrics because they apply universally to any customer experience.

Performance measurement involves the specifica-tion of metrics, the automated recording and updat-ing of their values over time, and the presentation of them within a report or an executive dashboard.

Analytic applications should package a large number of metrics and should support the specifica-tion of company-specific custom metrics. The prod-ucts should track values for packaged and custom metrics and should include the mechanisms to pre-sent metrics in automatically generated and distrib-uted reports or emails.

Business Performance Monitoring

Business performance measurement is good, but business performance monitoring is better. Monitor-ing adds automated decision making to measure-ment. Rather than simply tracking the values of met-rics, monitoring compares those values to configur-able threshold values and, if the threshold values are crossed, a business event is triggered. The business event may generate notifications that invoke pro-grams or send notifications. Further, the notification processing may be qualified by the execution of business rules.

Performance monitoring is a nice bonus in ana-lytic applications. Most don’t offer this functional-ity. Minimally, look for capabilities that build on

performance measurement packaged and custom metrics and flexible presentation. Expect little or no automation.

Output

There should be a range of output types for cus-tomer-centric analytic applications. The range should include:

• Reports • Dashboards • Notifications

Notifications are the output of business perform-ance monitoring functionality. They should include emails, telephone pages, changes to dashboard dis-plays, and, ideally, the execution of programs that automate the response to events rather than ask a user to respond.

Dashboards, cockpits, or, as we prefer, flight decks are the output of business performance meas-urement functionality. They are typically continu-ous, customizable, visual displays of the information most important to a particular user—all the customer service metrics for the customer service executive, for example. Dashboards can add a minimum level of performance monitoring by changing display characteristics when metrics cross thresholds.

Reports are the output of analysis and prediction. Customer-centric analytic application products should package reports that reflect the insight pro-duced by each of its analyses and predictions. The reports should be visual, provide several formats, and support good interactivity. Reports should be created with the popular reporting tools and these tools should be usable to customize packaged reports and create new ones.

DISTRIBUTION. The output of analytic applications is important to many users, not just the analysts who run them. For example, dashboards are a terrific management tool. In addition, personnel in market-ing, sales, and service organizations will want to understand their contributions to your customer ex-perience. Also, you might want your customers to see your analysis of their behavior. Similarly, your suppliers play an important role in your customer experience. As a result, the reporting functionality within customer-centric analytic applications should



include report distribution outside the enterprise. There are several attractive distribution approaches including email and Web portals.

ACCESS CONTROL. While many users of many types will be interested in the output of customer-centric analytic applications, not all of them should be able to see all the reports. After all, some of them contain very sensitive information. Access control is required in order to enable broad access to analytic application output while, at the same time, protect-ing sensitive information. Access control capabilities should include user authentication, role-based au-thorization, and privilege-based access to individual reports. Access to the customer-centric analytic ap-plications, themselves, could be included in this ap-proach, although most of these users should not be able to execute the applications.

GLOBALIZATION/LOCALIZATION. If you run a global business, then the users of customer-centric analytic application output, especially when they’re your customers, partners, and suppliers, will like to see that output localized to the language and cur-rency that they use. Globalization is the support of a range of languages, language implementations, and currencies. Localization is the ability to deliver a specific language implementation and currency to a particular user.

Overall, globalization/localization is a nice-to-have capability for customer-centric analytic appli-cations, although it might be a mandatory require-ment for you. We don’t feel that it’s as important to be able to localize the implementation, execution, and support of the customer-centric analytic applica-tion itself.

Level of Functionality

The level of functionality can be an important evaluation criterion. By this, we mean the skills needed to use the products. Some analytic applica-tions are quite sophisticated and complex. Their use requires skills and experience in the algorithms that the products use. Other analytic applications abstract this complexity in an effort to make their capabilities more accessible. Complexity is not necessarily a disadvantage. Complex analytics that require high levels of skill may be your ideal; abstracted analytics

might not generate the insight that your business needs.

ARCHITECTURE

Architecture defines how products perform ana-lytic application functionality. Architecture is not as important for customer-centric analytic applications as it is for operational systems or analysis systems with large user communities. We have six architec-ture evaluation criteria:

• ENVIRONMENTS. Environments are the Web servers, server platforms, and data warehouses required by the analytic application.

• ORGANIZATION. Organization is the product’s major components and the interfaces between them. For example, a customer-centric analytic application might have a client/server organiza-tion or a three-tiered Web organization.

• INFRASTRUCTURE. Infrastructure is the set of services that supports the deployment and exe-cution of a customer-centric analytic application. For example, an analytic application might de-ploy on a J2EE Web application server or on Microsoft .NET.

• STRUCTURE. Structure examines what’s inside the major components—how are they built and what was used to build them. For example, an analytic application might be built of coarsely grained components that are specified in Java.

• CUSTOMIZATION. Customization examines whether and how you can change the internal structure of an analytic application to address your requirements. You likely won’t be custom-izing customer-centric analytic applications.

• INTEGRATION. Integration examines how a customer-centric analytic application can be adapted to work with external systems.

For analytic applications, the key architecture evaluation criteria are environments, organization, infrastructure, and structure. For environments—the platforms and databases required by an analytic ap-plication product—it’s important that a customer-



centric analytic application fit into your existing analysis environment. For example, you won’t be too willing to implement a new data warehouse da-tabase just to run a customer-centric analytic appli-cation. For organization—the product’s major com-ponents and the interfaces between them—again, a match with your existing environment is important. If you’ve standardized on thin-client Web applica-tions, you won’t find a client/server analytic applica-tion product very attractive. Customer-centric ana-lytic applications must also support your specific deployment infrastructure, such as IBM WebSphere or Microsoft .NET.

If you’re going to do real-time analysis, then structure and customization come into play along with integration. In real-time analysis environments, the analytic applications must integrate loosely with operational systems. Implementation of that integra-tion might require customization, and customization gets into structure. Ideally, the customer-centric ana-lytic application supplier has packaged this integra-tion with it product, and the packaging supports the operational systems that you use, such as contact centers and ecommerce systems. If not, integration can be a complex and costly effort.

DATA. Data is the most important aspect of organi-zation and infrastructure of a customer-centric ana-lytic application. Data is the analytic application’s input. It determines the product’s breadth of analysis (functionality determines depth of analysis). For complete analysis, data must represent all touch-points, all operational applications, and all custom-ers. Data is also the only component for which struc-ture really matters. Structure is what’s inside a com-ponent. For customer-centric analytic applications, structure is the data model, the richer the better.

The data that is the input into customer-centric analytic applications is the output of customer fo-cused operational applications. However, the input is not taken directly from the operational applications’ online databases. Rather, the information relevant to analytic processing is extracted from operational databases, transformed into a uniform structure and format (every operational system likely has its own characteristic representations of the same informa-tion), cleansed to eliminate duplicate and inconsis-tent data, and loaded into a data warehouse. In other

words, a data warehouse provides the input to cus-tomer-centric analytic applications.

Customer-centric analytic applications don’t have to package their own data warehouses, but they should define a data model for a data warehouse, provide the mechanisms for implementing that data model in one or more database servers that imple-ment the data warehouse, and provide connection and access to the data warehouses.

We really mean a data warehouse, not a data mart. Customer-centric analytic applications must have input that represents all customers, all cus-tomer-facing and customer-touching systems across all touchpoints, and all supporting back-end and supply chain systems. Those systems create your customer experience. Its analysis must be compre-hensive. Data marts that reflect a single touchpoint or fewer than all you customer-facing and -touching applications will not support the analysis that you need to do.

PRODUCT MARKETING

Within the product marketing dimension, we consider the business aspects of customer-centric analytic application. Product marketing evaluation criteria are much easier to evaluate than functional-ity criteria, but they can be deal breakers. There are six product marketing evaluation criteria to consider:

• Product background • Installed base • Product plans • Price • Product viability • Competition

Product Background

When we perform an evaluation, we consider the history of the analytic application product in terms of the timing of its major versions and, if applicable, its acquisition history. These are factors that contrib-ute to product viability.

Installed Base

The installed base of a customer-centric analytic application product provides an idea of its success and acceptance in the market and contributes signifi-



cantly to our assessment of product viability. In this section of an evaluation, we present the number of customers and customer references for the product.

Product Plans

Customer-centric analytic applications are a new and rapidly evolving class of products. Many prod-ucts are in their initial versions. As with any strate-gic software, don’t buy just on the features of the current release. Get an idea where the vendor hopes to take the product in the future. Make sure the ven-dor’s view of the future is same the same as your. Look for planned improvements in areas where the product is currently weak.

Price

Customer-centric analytic applications are expen-sive. Figure on spending a few hundred thousand dollars on software. For your money, make sure you get the functionality that you need. Don’t pay for abstraction if you don’t need it. Don’t buy complex-ity if you won’t use it. Beware of indirect charges such as add-on products for extraction, loading, and transformation (ETL), data warehousing, or report-ing. They can cost as much, if not more, than the analytic application products themselves.

Product Viability

Product viability is our assessment of the overall risk in implementing customer-centric analytic ap-plication product. In making this assessment, we take into consideration such factors as installed base, product version, track record for performance, scal-ability, reliability, and technology. For example, new products built of new technologies are quite risky, whereas products in their fourth version with large installed bases have little risk and raise no viability issues.

Competition

Understanding the products that compete with a particular customer-centric analytic application product can really accelerate the section process. In our evaluations, we present an analysis of competing suppliers and competing products, highlighting ma-jor advantages and disadvantages.

COMPANY VIABILITY

A company’s viability can be assessed by exam-ining two criteria: customers and financials. As with product marketing criteria, company viability criteria are relatively easy to evaluate, but they too can be deal breakers. Issues in these areas create risks that should affect your acquisition decision. These risks have typically come into play only when the com-pany that offers a product is so small or so unstable as to introduce a business risk when buying its prod-ucts, but, in today’s economic climate, even large, successful companies have had problems. Decision-makers must weigh functional and architectural ad-vantages of products from newer and smaller com-panies versus the risk of doing business with com-panies that might not have staying power.

WHO OFFERS CUSTOMER-CENTRIC ANALYTIC APPLICATIONS?

Three Types of ISVs

Customer-centric analytic application products are offered by three types of ISVs:

• CRM suite suppliers, such as E.piphany, Oracle, PeopleSoft, SAP, and Siebel. For example, the SAP Business Warehouse packages a range of general-purpose data mining algorithms and tools as well as several types of analytic applica-tions.

• Ecommerce server suppliers, such as Blue Mar-tini and Microsoft. For example, Microsoft Commerce Server 2000 uses the decision trees algorithm packaged within the SQL Server 2000 database to make real-time product recommen-dations to online shoppers.

• Point solutions providers, such as Business Ob-jects, Teradata, and Unica. (Teradata and Unica also offer campaign management capabilities.) For example, Teradata CRM packages six ana-lytic applications, and the Teradata Warehouse Miner complements this offering with general-purpose data mining algorithms and tools.



We plan to document our evaluations of many of these offerings against the framework that is detailed in this report.

CONCLUSION

Customer-centric analytic applications can help your company become more customer-focused. These are tools that can help you better understand your customers’ behavior so that you can improve your knowledge of them. Improved knowledge can

improve the customer experience that you provide. And, with better experiences, come higher satisfac-tion, greater loyalty, and more profitability.

There are many customer-centric analytic appli-cation products from which to choose. The frame-work documented in this report has been designed to help you select the analytic application that is best for you, minimizing the time and risk of that selec-tion.



What Comes After CRM? Customer-Led Business Transformation

By Patricia B. Seybold, Sr. VP and Sr. Consultant, Patricia Seybold Group

NETTING IT OUT In today’s tough global economy, businesses are focused more than ever before on retaining their existing customers and on lowering their operating costs. Customer Relationship Man-agement (CRM) strategies and systems, once thought to be the silver bullet that would cata-pult companies to higher profits, are now com-ing under increasing management scrutiny. The “problem” with CRM, if there is one, which we doubt, is that capturing customer information and acting upon it is only one piece of a much larger challenge confronting today’s busi-nesses. Customers don’t just want to be mar-keted to, they want to be well-served. Our com-panies are notoriously ill-prepared to meet the challenges posed by today’s increasingly de-manding business and consumer customers.

What do we need to do beyond installing CRM systems to help us better understand our cus-tomers and to better market products to cus-tomers, sell them to customers, and support customers? Actually, there’s a lot beyond CRM that we need to do. Despite our investments in customer-facing Web sites, customer portals, and CRM systems, our businesses are still de-signed from the inside out as product-centric and functional fiefdoms. This drives our cus-tomers nuts! Until we actually begin redesigning our entire businesses to be customer-driven and customer-led, we won’t be able to meet the needs of 21st century customers.

IT’S A RECESSION: DO YOU KNOW WHERE YOUR FOCUS SHOULD BE?

You’ve already got a customer-facing Web site or portal. No doubt, your company is also in the midst of a major CRM initiative to pull together and to mine much of your customer information so that you’ll be better able to target your most profitable customers with relevant offers and to aim your mar-keting campaigns at more likely acquisition targets.

But customers aren’t buying right now. And your sales cycles have gotten longer and longer for smaller and smaller returns. You’ve trimmed staff, lowered prices, gotten rid of excess inventory, and your management is looking for the next place to cut costs. You’re looking for the best opportunity to bring in revenues and profits without increasing costs-to-serve. You’re both looking for improved results. What’s the answer?

Go Beyond CRM

Guess what? CRM isn’t the silver bullet that will yield more effective sales, greater wallet share, and faster profitability. There’s only one thing that will really do that. You’re going to have to let your cus-tomers drive your business—all the way through.

Pulling together customer information and mounting better marketing campaigns won’t make it easier or more enticing for customers to do business with you.

Let Your Customers Transform Your Business

Face it. Your business is broken (from your cus-tomer’s point of view.) Your customers can’t get consistent information across your Web site, your contact centers, your retailers, and your channel


What Comes After CRM? • 35

partners. They can’t easily locate the products they need. They have to make several attempts to resolve problems and to get questions answered. Your busi-ness, like any business, is designed inside out. It’s designed for you to develop, build, and sell stuff. It’s not designed to help customers buy stuff from you. The problem is as simple as that. And as hard.

So what SHOULD you be doing? Where SHOULD you be investing your scarce resources? How do you transform your business from a collec-tion of product line silos and functional fiefdoms to a streamlined, efficient customer-driven pipeline—one where customers’ needs and requests appear at one end, and product development, delivery, and service take place in a transparent and dynamic Value Web?

The good news is that there IS a proven way to transform your company to be lean, clean, and customer-centric. And you can do it one step at a time. This transforma-tion starts with the Web and with your other customer-facing in-teraction touchpoints. Then it ripples through your entire or-ganization, your partner chain, and your supply chain—in fact, your entire Value Web. (At some point in the past five years, sup-ply chains became supply Webs; the same thing happened to demand chains. Instead of a series of one-to-one causal relationships, we now realize that each customer request or need fans out through an entire Web of organizations, each of which may par-ticipate in providing the solution.)

Clearing the Way

But, in order for this customer-centric transfor-mation to take place, you need to remove barriers, solicit high-level support, and seize tactical opportu-nities. Once customer information and requirements begin to drive your business in real-time, the path forward becomes clearer and clearer and more and more compelling.

WHO SHOULD LEAD THE CHARGE? The people who are leading the customer-transformation of their companies tend to be the same people who have spearheaded their companies’ ebusiness initiatives.

Usually, they’re strongly backed by the CEO, aligned with their company’s IT visionary and with the global marketing executive, and have a strong business P&L sponsor—usually in an organization that is already organized around a major customer segment.

Occasionally, as at Delta airlines, the major transformational trigger comes out of the need to streamline operations. (Delta began the revamping of its internal systems in order to gain a better real-time view of its fuel needs. Then the company was able to use its business events-based “digital nervous system” to proactively improve customers’ experi-ences when the inevitable travel disruptions oc-curred1.

Learn the Survival Skills from Customer-

Centric Organizations

The people who are leading the customer-transformation of their companies tend to be

the same people who have spearheaded their companies’

ebusiness initiatives.

If you look at the evolution of the customer-driven transfor-mations that have rippled through the today’s most suc-cessful companies, you’ll see some interesting similarities. Here are some of the patterns that I’ve noticed.

• Focus on a Key Customer Segment. At Wells Fargo, Dudley Nigg, who led that company’s transformation, was initially responsible for the bank’s high net worth cus-tomers. At American Airlines, John Samuel fo-cused on frequent business travelers. At Boeing, Bill Barker began his odyssey with customers who purchased replacement parts. At General Motors, Chet Huber at OnStar and Paul Comfrey at Vauxhall both targeted customers who valued convenience. At Fidelity, Steve Elterich focused first on his retail customers. At Hewlett-Packard, Leslye Louie focused on consumers who are multi-touchpoint shoppers (research on the Web/purchase in the store; shop in the store; buy online; get pre-sales and post-sales help on the phone and on the Web). Phil Gibson at National

1 See John Mann’s “Customers Experience Your In-

ternal Operations,” July 19, 2001, http://dx.doi.org/10.1571/cs7-19-01cc.


http://dx.doi.org/10.1571/cs7-19-01cc


Semiconductor began by focusing on design en-gineers. Scott Eckert at Dell focused first on large business customers. Sue Steel and Marc Tennessee at Cisco Systems targeted their larg-est resellers first. Brad Lewis at Snap-On tar-geted consumer customers—a market that Snap-On wasn’t serving at the time.

• Offer Web Self-Service for the Key Scenarios Customers Care About. For Boeing, this was, “give me my company’s negotiated price, your time-to-delivery, and the current location of the part I might need.” For Cisco, this was, “let me configure a system and get an accurate quote,” and “show me the status of all my orders, and let me change the ones you ha-ven’t shipped yet.” For Fi-delity, it was, “let me roll over my IRA easily” and “show me my combined re-tail holdings and those in my company-sponsored Fidelity retirement account.” For HP, it was, “let me download a printer driver for my new printer,” and “how do I order supplies?” and “it’s not working, how do I get this fixed?” For Dell, it was, “help me manage the computers I’ve bought from you” and “send me 2,000 com-puters with the following software configura-tions to these 18 offices in 10 different countries over the next 6 months and let me time the shipments and re-allocate deliveries.” For Na-tional Semiconductor, it was, “let me design and simulate my new designs online, now show me a bill of materials with your parts and your com-petitors’ parts, and let me order that bill of mate-rials from a distributor that has them in inven-tory with prices I can afford.” With Delta, it was “re-route me and my luggage so that I’ll arrive at my destination as close as possible to my origi-nal plan.”

Notice that all of these customer scenarios2 aren’t Web-only scenarios. They link directly into the company’s (or in some cases, their channel partners’) operational systems: inven-tory, pricing, order entry. And, in many cases,

2 Customer ScenarioSM Design is a Service Mark of

the Patricia Seybold Group.

these scenarios also span functional boundaries (sales and manufacturing; retail vs. institutional; customer service and order-entry, and so on).

• Combine Contact Center and Web Infra-structures and Organizations. Wells Fargo built its Web customer self-service infrastructure on top of the application integration infrastruc-ture it had already designed for the customer service reps (CSRs). These CSRs needed to ac-cess operational applications across business units and product lines on the customers’ behalf. Once CSRs could access the information cus-tomers’ needed, Wells Fargo enabled customers to help themselves to the same information.

• Deliver Customer Portals First; Then Turn Them into Employee Portals. At Boeing, Bill Barker is using the same infrastructure and architecture he developed to give Boeing’s customers ac-

cess to 100 of Boeing’s core operational applica-tions. Now, he’s enabling Boeing’s own em-ployees to see the same information to which customers already have access, along with addi-tional “employee-only” information.

Today’s leading companies are redesigning themselves

from the outside in.

• Give Customers a Seamless Experience with Your Channel Partners. Cisco Systems has done a great job of integrating channel partners and customers. Cisco bucked the conventional wisdom that tells us that channel partners need to “own” the customer and “add value.” Cisco redesigned its systems from the customers’ point of view. Customers configure their systems di-rectly on Cisco’s Web site. They then get pricing and delivery commitments from their preferred dealer (without leaving Cisco’s site). Cisco con-figures the system and ships it to the dealer pre-configured to the customer’s specs. The cus-tomer has visibility into the entire process. The Dealer installs and integrates the systems at the customer’s premises. Deliveries are fast. Con-figurations are accurate. Everyone wins. On the consumer side of the equation, watch HP and Best Buy. This manufacturer and retailer combi-nation are tightly integrating their supply chains


What Comes After CRM? • 37

• Measure and Reward Based On What Mat-ters to Customers. As you’re undergoing this infrastructure transformation, you’ll also find that you need to put new customer metrics in place. In addition to measuring revenues and profits by product line, you now need to measure profitability by customer segment. That means knowing your costs-to-serve and your costs-to-deliver for each customer segment, each interac-tion touchpoint, and for most of the activities that impact customers. At the same time, you’ll want to monitor very carefully the “moments of truth” in your dealings with customers. For each key customer scenario, there are usually two to three key business events that will make or break the quality of the customer experience. These are the points you want to instrument and monitor very carefully. Finally, you need to reset your corporate compensation structure so that you’re rewarding employees based on the qual-ity of the customer experience and its link to customer profitability.

and their key customer scenarios (e.g., service, supplies, and handling returns).

• Let Customers Drive Cross-Product Line In-tegration. At Fidelity, there had been a Chinese Wall between the giant retail division and the in-stitutional division. One sold to and serviced in-dividuals and their households; the other sup-ported corporate HR and benefits’ buyers. How-ever, often, the end-customer is the same. A per-son who had a Fidelity 401K plan through his company was also likely to have a retail account with Fidelity. In fact, employees have been de-manding better self-service and tighter integra-tion. The result for Fidelity is a now-seamless Web environment for both retail and corporate accounts. Customers gain because they have the same user interface, log-ins, and a complete pic-ture of their accounts. Fidelity gains because it is leveraging much of the same Web infrastructure across both divisions.

• Let Customers Custom-Configure Their Own Products and Services. We all know that the migration of “build-to-order” is rolling from the computer industry to the apparel industry all the way to consumer packaged goods. We can al-ready design our own custom breakfast cereal online. The ramifications of custom-configured products are enormous. However, to enable this build-to-order capability your firm has to move to lean manufacturing practices. That impacts your in-house and outsourced product design, manufacturing, and supply chain.

Let Customer-Driven Business Processes Re-Focus Your Organization

You can see that customer-driven business proc-esses are already rippling through many businesses and transforming them dramatically from the inside out. This is a not “just CRM.” It’s far more profound and impactful. Today’s leading companies are redes-igning themselves from the outside in. While many of these initiatives I’ve described started with the Web and with customer self-service, the customer ripple effect has actually impacted these companies’ entire business structures. You may be able to move more quickly on the Web side of the business, but in order for true customer-driven transformation to take hold, what you learn from your ebusiness needs to be used to transform and streamline your entire business.



Multi-Channel CRM A Framework for Evaluating Multi-Channel CRM Solutions


NETTING IT OUT We define multi-channel CRM as the delivery of customer-facing, customer-touching, and cus-tomer-impacting marketing, sales, and service business processes across multiple interaction touchpoints and delivery channels. These touchpoints and channels include point-of-sale, email, contact center, and Web, as well as di-rect and indirect sales channels. The goal of multi-channel CRM is to provide a consistent and coherent customer experience.

We believe strongly that multi-channel CRM is the best way to acquire new customers and the best way to grow customer relationships that are profitable.

However, implementing multi-channel CRM is difficult. Today’s CRM products don’t package comprehensive support for all the combinations of touchpoints, channels, and applications you’ll need. As a result, your multi-channel CRM im-plementation will need significant customization and integration.

To simplify the selection of products that can contribute to your multi-channel CRM imple-mentation, we’ve adapted our framework for evaluating CRM products and architectures. The framework describes evaluation criteria in the areas of functionality, administration, and architecture.

As you approach multi-channel CRM, we offer these recommendations:

• Use our Customer Scenario® Mapping technique to understand your customers’

multi-channel CRM requirements and to identify the services that customers need to complete their tasks.

• Don’t attempt to do it all at once. Begin with the scenarios that impact your customers the most (these are often customer service and/or pre-sales) and with the interaction touchpoints that are relevant for those sce-narios.

• To minimize customization and integration, select a channel/application combination that can be addressed by packaged soft-ware, ideally from a supplier from whom you’ve acquired other CRM applications.

Over the next few months, we plan to evaluate CRM products and product suites against the requirements for multi-channel CRM described in this report. We also plan to do case studies of successful multi-channel CRM implementa-tions. In addition, we’ve planned workshops for you that use Customer Scenario® Mapping to understand your requirements and the services that can implement them. Watch our Web site for the schedule.

WHAT IS MULTI-CHANNEL CRM?

A Definition

Multi-channel CRM is the delivery of customer-facing, customer-touching, and customer-impacting marketing, sales, and service business processes across multiple interaction touchpoints and delivery channels. These touchpoints and channels include point-of-sale, email, contact center, and Web, as


Multi-Channel CRM • 39

The Challenge of Multi-Channel CRM Deliver a Great Quality of Customer ExperienceSM

CatalogCatalogCall Center

WebE-Mail

Partners

RFQ/RFP

E-Markets

Brand Personality

Innovation

Core Driving Idea

Differentiation

DedicatedRetail Store

Store

DedicatedRetail Store

Store

Multi-Supplier Retailers/B-Tailers

Customer’s Self-Concept

Customer Relationship

Brand Identity

IntegrityValue

Trust

Efficient Use of My Time Ease of

Doing BusinessEase of

InteractionsReliable Fulfillment,

Delivery, and Support Ease of Decision-Making

Mobile/Wireless


Illustration 1. The challenge of multi-channel CRM is in delivering a consistent experience with your brand across interaction touchpoints and distribution channels. Customers expect you to provide them with a seamless experience. If you can’t meet their needs for any of the conditions of satisfaction (e.g., value, ease of decision-making, ease of interactions) across all of these different channels, you’ll lose their trust and their loyalty.

well as direct and indirect sales channels. The goal of multi-channel CRM is to provide a consistent and coherent customer experience across channels and touchpoints.

We believe strongly that this has become the best way to acquire new customers and the best way to grow customer relationships that are profitable. Why? Because today’s customers expect you to de-liver a consistent experience across channels and touchpoints. (See Illustration 1.) In addition, and almost as significantly, CRM technology and the application software that implements it have evolved

and matured to the point where multi-channel CRM support is feasible and viable.

The Customer Perspective

Your customers want to interact with you in many ways. Some have found a channel that you support particularly well and want to conduct all their interactions with you on that channel. For ex-ample, if you’ve long been selling your products through a direct sales force to an established cus-tomer base, then we’re sure you can think of a few customer executives who want to deal only with the



account exec that you’ve assigned to them. At the other end of the multi-channel CRM spectrum, you probably also have customers that take advantage of multiple channels. They may like the convenience of the 24 X 7 availability of your Web self-service and point-of-sale channels and use your direct channels only for exception conditions. For example, many of us do most of our banking through ATMs and online bill-payment facilities. We only go into a branch when one of these channels is down or when we have to complete tasks that our banks won’t let us do online.

Your customers have a range of channel prefer-ences for doing business with you. Each customer has individual preferences. For the best customer relationships, you must recognize these preferences and take a multi-channel CRM approach that sup-ports them.

Your Business Perspective

While you want to support the channels through which your customers want to do business with you, you are running a business. Loyal customers are not necessarily profitable customers. And the costs to implement and support customer interactions across multiple channels can be prohibitively high. In addi-tion, it has not always been technologically feasible to offer multi-channel CRM.

Each CRM channel has characteristic implemen-tation costs and ongoing costs-to-serve for your business. You should consider a channel mix that optimizes customer profitability, customer satisfac-tion, and the quality of the customer experience against implementation costs for new channels and aggregate costs-to-serve. That’s easy to say, but quite difficult to do. For example, customer self-service through online channels has the lowest ongo-ing costs-to-serve, but might have a very high im-plementation cost, especially if you’re new to online channels and your value-add is in personalized ser-vice. More likely, you’ve already implemented mul-tiple channels, but you don’t yet provide marketing, sales, and service across all of them. If implementa-tion costs are already sunk costs, then your approach to optimal multi-channel CRM is much simpler.

The Software Perspective

In practice, most CRM approaches we’ve seen have been taken through packaged software. You buy rather than build your marketing, sales, and ser-vice systems. It should be a straightforward process to extend your packaged CRM systems to multiple channels. It’s not. Packaged software support for multi-channel CRM is surprisingly spotty. For ex-ample, neither PeopleSoft nor Siebel offer viable online selling (ecommerce) capabilities. Most con-tact center products, products from E.piphany and SAP, for example, are designed for inbound service, not for inbound sales. In fact, we’re just beginning to see support for sales order processing in any contact centers. And virtually none of the popular CRM packages and suites supports the point-of-sale chan-nel, e.g., the cash register or kiosk.

If you’ve implemented a sell-side ecommerce system, then you’ve got self-service sales well cov-ered, but you’ll have channel holes in marketing and service. For example, ATG6 provides very good self-service customer support but nothing for the contact center. Blue Martini has very good online, contact center, and even point-of-sale coverage for marketing and sales, but is not so strong for non-sales service.

All this is to say that multi-channel CRM is only partially a buy. Its implementation will require con-siderable customization and integration, perhaps even custom development. However, we feel that the complexity and costs can be justified by increased profitability, lower costs to serve, and stronger cus-tomer relationships.

REQUIREMENTS FOR MULTI-CHANNEL CRM

Capturing the Benefits

In order to capture the profitability, cost, and loy-alty benefits of multi-channel CRM, these systems should address requirements in three key areas:

• Functionality • Administration and management • Architecture

These are the same types of requirements that we’ve identified through our research in the separate



CRM areas of analytic applications and campaign management as well as in architecture. Let’s take a closer look at how they’re applied to multi-channel.

Functionality

As with all CRM, there are two dimensions to multi-channel CRM functionality:

• Operational functionality • Analytic functionality

Operational functionality is implemented by the applications that do marketing, sales, and service, as well as those that support and/or integrate with the rest of your “back-end” applications (e.g., inventory, billing, fulfillment). They’re applications with which your customers, contact center agents, and field sales and service people interact.

Analytic functionality is implemented by the ap-plications that analyze the results of operational ap-plication processing. Analysis results in improve-ments and refinements to operational functionality that improve the customer experience and improve customer relationships and profitability. Operational and analytic functionality work together continu-ously in a closed loop.

Operational Functionality

There are three evaluation criteria in the opera-tional functionality of multi-channel CRM:

• Multi-channel functionality • Channel-dependent functionality • Channel-independent functionality

MULTI-CHANNEL FUNCTIONALITY. Multi-channel CRM doesn’t change the functional re-quirements for individual CRM applications. Rather, it distributes functional requirements by requiring them to work consistently and appropriately across channels and touchpoints for both direct and indirect (dealer, distributor, agent, OEM) sales, marketing, and support. Those channels are:

• Face-to-Face • Phone • Email • Snail Mail or Direct Mail • Point-of-sale

• Contact Center (Inbound/Outbound) • Web • PDA or other Wireless Handheld

For example, campaign management products require similar planning, design and development, delivery, and measurement and analysis functional-ity to deliver campaigns through multiple channels as they do for single channels. In fact, our campaign management evaluation framework considers multi- channel support in several areas. However, for multi-channel CRM, the ability to execute cam-paigns across channels becomes a much more im-portant requirement. Campaigns should be deliver-able through every one of these channels. In turn, sales applications should provide selling functional-ity through all of these channels, and service appli-cations should do the same.

CHANNEL-DEPENDENT FUNCTIONALITY. You will not deliver the same CRM functionality through every channel. Rather, functionality should be tai-lored to the channel. Continuing our campaign man-agement example, while campaigns should be deliv-erable through every channel, their offers should be tailored to and consistent with the business charac-teristics of each channel. For example, the Web channel has a lower cost-to-serve than the contact center. Therefore, you might offer deeper discounts for Web campaigns than contact center campaigns.

Channel-dependent functionality is a key factor for the evaluation of multi-channel CRM functional-ity. You can’t deliver identical experiences and pro-vide identical functionality through every channel. For example, in the product support area of customer service, self-service product support can’t encapsu-late the expertise and adaptability of your best con-tact center tech reps, and tech reps can’t use all of the diagnostic tools through the contact center that they could if they were onsite. On the other hand, your self-service product support systems should have a wide range of problem determination aids and should give your customers the mechanisms to open, track, and escalate product incidents. Your contact center should have all the capabilities of the self-service system and should add tools and access in-formation dependent for contact center tech reps. Your dealers’ product support systems should in-clude at least the functionality the customer would encounter if he dealt with you directly, plus what-



ever additional services your dealer provides. Your field service systems (these are mobile CRM sys-tems) should encapsulate self-service and contact center capabilities and should add diagnostic tools and reporting capabilities unique to and tailored to onsite service through the direct channel.

CHANNEL-INDEPENDENT FUNCTIONALITY. While some functionality is channel dependent, as we discussed above, other functionality is channel independent. Channel independent functionality in-cludes customer, product, and order related func-tionality. For example, you must recognize each of your customers independently of the channel through which they choose to interact with you. Every aspect of their identity, behavior, and relation-ship must be delivered consistently to every channel. You must treat them consistently, although channel appropriately. And you should be able to see any interactions they’ve already made with you through another channel.

Analytic Functionality

Requirements for analytic functionality in multi-channel CRM are straightforward. Analytic applica-tions should provide the capabilities to analyze cus-tomer behavior and customer transactions across all channels and on each, individual channel. In other words, they must provide a view of the entire cus-tomer experience that you offer as well as a view of channel-specific customer experiences. Analyses of channel-specific customer experiences must present metrics and information appropriate to that channel.

Administration and Management

There are a few aspects of administration and management that have heightened importance in multi-channel CRM:

• Security • Internationalization • Content management

Requirements for security, internationalization, and content management address a range of CRM application user types including, most significantly, customers, dealers or agents, direct sales or sales associates, customer service personnel, marketing personnel, and administrators.

Security—including the authentication of users and their authorization to access functionality and data—takes on added significance in multi-channel CRM. On self-service channels, access controls must be finely granular for self-service channels, allowing your customers to perform their tasks while access-ing only the data relevant to themselves.

Self-service also makes internationalization and content management more important. If you’re a global company, then you should provide the capa-bilities for individual customers to localize all their interactions with you. For example, ecommerce sys-tems do a nice job at localizing marketing, sales, and the order management aspects of customer service. Many CRM suites don’t do as good a job.

Architecture

Architecture is a critical criterion for evaluating multi-channel CRM. Why? Because today’s CRM products don’t have great multi-channel support. For example, as we’ve discussed earlier in this report, most of the poplar CRM suites don’t package ecommerce and self-service customer support, and many ecommerce systems don’t support direct or contact center sales. As a result, the architectural evaluation factors of structure, customization, and integration are key to your ability to implement multi-channel CRM.

STRUCTURE. By structure, we mean how the major elements of a multi-channel CRM system are organ-ized, how they’re built, and how they’re accessed. For application logic, structure is modularity, com-ponent implementation, and component interfaces.

• Modularity. Your CRM applications should be organized modularly into services’ components. Each component should implement a granular “chunk” of functionality. Subjectively, compo-nent granularity should not be so fine as to have so many components that you can’t easily asso-ciate any one of them with a particular CRM function nor so coarse that the application be-comes monolithic.

• Component Implementation. They should be built as reusable components specified in a popular programming language and imple-mented on a standards-based component model



such as J2EE or .NET. Alternatively, they might be generated from metadata into this component model.

• Open Interfaces. They should be accessible through rich and open interfaces consistent with their component model. They might also be ac-cessible through the Web services protocols: XML and SOAP.

For data, especially customer data, structure is the data model, an application’s logical representa-tion of the information that it processes. Data models for CRM, ERP, and supply chain applications repre-sent the business entities involved in the processing that they perform. Most significantly, the data mod-els for all these applications represent customers. Customer data models are the most important aspect of data structure to multi-channel CRM. They should be:

• RICH. The customer data model should repre-sent every possible aspect of your customers’ identities, their business relationships with you, the transactions between them, you, and any dis-tribution partners, and the behavior that they manifest in marketing, sales, and service interac-tions.

• OPEN. The customer data model of application software should be made available to you. You and your developers can study its design in order to facilitate customization and integration.

• FLEXIBLE. You should be able to modify and extend the customer data model in order to ad-dress your business requirements.

• CONSISTENT. The customer data model and the values of its attributes must be accessible consistently across all the channels through which you interact with your customers and across all your CRM applications.

CUSTOMIZATION. No packaged application com-pletely addresses your functionality requirements. As a result, you must customize these applications by modifying or extending the internals of their components and then reflecting those modifications and extensions in component interfaces. Multi-

channel CRM will require additional modifications. Not only will you implement your unique, company-specific functionality, you’ll also implement chan-nel-dependent functionality. For example, an “open an incident” component of a service application will perform customer lookup and customer authoriza-tion processing when deployed on the Web channel for customer self-service environments, but not for contact center environments.

INTEGRATION. Multi-channel CRM systems, like all CRM implementations, require integration with both internal and external business systems in order to automate business processes. By internal business systems, we mean your other operational CRM ap-plications and your back-office systems, as well as your data warehousing and analytic applications. By external business systems, we mean the CRM sys-tems of your sales and marketing business partners and the back-office systems of your suppliers. For example, an ecommerce application should provide integration with inventory systems in order to pre-sent availability and lead times to online shoppers and customers. A contact center system should pro-vide integration with order management systems so that customer service representatives can answer customer questions about current order status or his-torical order details. In addition, it is becoming in-creasingly important to integrate with the external business systems of customers and suppliers—a seller should be able to receive and process purchase orders from its customers, sending back a purchase-order acknowledgement; similarly, a seller should be able to have the same exchange with its suppliers.

For multi-channel CRM, integration is the most important architectural factor. First, you’re not start-ing from scratch in CRM. You already deliver at least some marketing, sales, or service functionality through some channels. Your implementation of multi-channel CRM will add and/or extend this functionality and will enhance existing channels support and/or add new channels. Adding function-ality and channels means integration. Second, most of the packaged CRM application software products that we’ve considered are missing functionality and/or channel support. You’ll need to purchase more than one product to implement multi-channel CRM, and that means integration must be done be-tween products and between products and your cus-tom-built applications.



SERVICE-ORIENTED ARCHITECTURE. There is an evolving approach to architecture that addresses the combination of our requirements for structure and integration. This approach is service-oriented architecture, and we feel that it’s the ideal approach for multi-channel CRM.

Service-oriented architecture organizes an appli-cation’s components into services. A service may comprise a single component or multiple compo-nents. Individual services typically implement higher-level and broader functionality than individ-ual components. For example, a cross-sell service might combine a customer-value-lookup component, an order-lookup-component, and a cross–sell-recommender component.

Service-oriented architecture facilitates integra-tion through open interfaces. Every service provides an interface to the functionality that it offers. The interface may be the same component model as its constituent components or it may be a higher-level interface such as XML/WSDL. Higher-level inter-faces facilitate integration and interoperability, inde-pendently of the underlying component model that implements the services’ functionality. Services act as producers and consumers of other services. A given service may be both a producer and consumer. Note that the services of services-based architectures may be formal Web Services, although that’s not a requirement. The requirement is for uniformity of interfaces and consistency in the communication between individual services. For example, messag-ing interfaces and communication protocols such as IBM MQSeries or J2EE JMS would serve well, too.

CONCLUSION AND RECOMMENDATION

Use Customer Scenarios®

Our Customer Scenario® Mapping technique provides an ideal approach for understanding your customers’ multi-channel CRM requirements. Re-member that a Customer Scenario is a set of tasks a customer is happy to do to achieve his or her desired outcome. A customer scenario might be: Roll Over an IRA, or make a travel reservation, or get my car fixed. By inviting customers to help you map out how they’d like to interact with your firm, you’ll be better able to determine which channels they’ll pre-fer to use for which tasks. Customer scenarios will

also identify the services that customers need to complete their tasks. Customer Scenario® Mapping can also be applied to understand your outbound multi-channel CRM requirements (e.g., telesales, campaign management) and to identify the services you need to support them.

One Channel and One Application at a Time

Our fundamental recommendation for multi-channel CRM is the same as the recommendation that we’ve made for CRM in general. Don’t attempt to do it all at once. Start with the critical scenarios for your most critical customers. Take a one-channel- and one-application-at-a-time approach. We’d also suggest starting with the chan-nel/application combination that will require the least customization and integration.

You Can’t Buy Multi-Channel CRM

As we indicated in the section, “Architecture,” above, you’ll be buying and/or building and well as customizing and integrating multiple applications to address your requirements for multi-channel CRM. The popular CRM product suites currently don’t package the breadth of channel support and applica-tion functionality to address most requirements.

But don’t let that stop you. You might start by se-lecting a channel/application combination that can be addressed by packaged software, ideally from a supplier from which you’ve acquired other CRM applications.

Our Multi-Channel CRM Plans

Over the next few months, we plan to evaluate CRM products and product suites against the re-quirements for multi-channel CRM described in this report. We also plan to do case studies of successful multi-channel CRM implementations. In addition, we’ve planned workshops for you that use Customer Scenario® Mapping to understand that your require-ments and the services that can implement them. Watch our Web site for the schedule.



Framework for Evaluating Cross-Channel, Cross-Lifecycle Customer Service Products How to Evaluate Solutions That Support a Great End-to-End Customer Experience


NETTING IT OUT Your customers want and need your help on every channel through which they interact with you. They want and need your help for every activity that they want to perform through those interactions for the duration of their relation-ships with you. Think of that help as customer service—cross-channel, cross-lifecycle cus-tomer service.

Channels link your customers to customer ser-vice personnel and to customer service sys-tems. There are two types of channels: partner networks and customer touchpoints. Touch-points are automated and self-service or staffed and assisted service.

Your customers’ activities with you traverse the phases of a lifecycle, from the first step of the first piece of business that they do with you through the time when they stop buying and using your products and services. Between those points, customers have a wide range of activities for which they need your help.

We’ve created a framework to help you evalu-ate products that offer cross-channel, cross-lifecycle capabilities. The framework has the following five top-level criteria:

• Operational capabilities • Analytic capabilities • Architecture • Product viability • Company viability

In this report, we describe these evaluation cri-teria in detail. In future reports, we will evaluate solutions using these evaluation criteria.

CUSTOMERS WANT CROSS-CHANNEL, CROSS-LIFECYCLE HELP

On September 2, 2004, we published a report about cross-channel, cross-lifecycle customer ser-vice. We viewed the topic first from a personal per-spective and then from the perspective of our con-sulting experience.1 From a combination of the two perspectives, there are two critical lessons to re-member:

• Customers want your help on every channel through which they interact with you.

• Customers want and need your help at every phase of their lifecycles, through every interac-tion and iteration within the lifecycle phases of plan, explore, select, buy, use, maintain, and re-new.

Remember also that customer service encom-passes all of your customers’ cross-channel, cross-lifecycle activities (not just break/fix or incident management). You should work hard to make it easy for your customers to do that business with you on every channel for every customer activity. That means you’ll need to implement customer service business processes and applications that support

1 See “May I Help You?”, Mitchell I. Kramer, Sep-

tember 2, 2004, http://dx.doi.org/10.1571/PSGP9-2-04CC.


http://dx.doi.org/10.1571/PSGP9-2-04CC

http://dx.doi.org/10.1571/PSGP9-2-04CC


your channels and your customers’ activities. In this report, we’ll give you a framework to help you evaluate and select the products that help automate those business processes and implement those appli-cations. Before we get into the details of the frame-work, let’s build a common understanding of what we mean by channels and by the customer lifecycle.

CROSS-CHANNEL CUSTOMER SERVICE

What Are Channels?

usiness with you through me

f channels: partner net-wo

yo

CONTROL. Remember that

Your customers do bchanisms that we call channels. Channels link

your customers to customer service personnel and to customer service systems.

There are two types orks and customer touchpoints. Partner networks

are the multitiered structures of distributors and re-sellers that market, sell, and support the products produced by manufacturers and suppliers.

Customer touchpoints are your technologies and ur personnel with which your customers interact

with you. Businesses have many customer touch-points. Their technology touchpoints include the Web, email, kiosks, and contact centers. Their per-sonnel touchpoints include store personnel, field personnel, and call center personnel. Partners also have touchpoints through which they interact with your end customers. They’re the same touchpoints as yours. Partner touchpoints should complement your touchpoints so that customers get a coherent and consistent experience.

CUSTOMERS ARE IN customers are in control. Customers choose their channels. Even if you’ve built a partner-based busi-ness model, customers pick the partners with whom they want to do business. And given that you’ve im-plemented multiple touchpoints, customers use the touchpoints that make it easiest for them to interact with you. Of course, it’s a given that customers do business with multiple partners using multiple touchpoints. It’s that complexity that forms the basis for the requirements to deliver cross-channel cus-tomer service.

Self-Service and Assisted Service

Touchpoints support either self-service or as-sisted-service interactions. Self-service interactions occur when customers interact with your customer service systems. Self-service touchpoints are auto-mated. They may have high implementation costs but very low costs to serve. The Web is a key self-service touchpoint. It can support the broadest range of types of interactions and just about every activity of every phase of your customers’ lifecycle. Interac-tive voice response (IVR) systems are another self-service touchpoint.

Assisted-service interactions occur when custom-ers interact with your customer service personnel, who, in turn, interact with your customer service systems for your customers. Assisted-service touch-points are manual. Contact centers, stores, and per-sonnel are the key assisted-service touchpoints. They have high implementation costs and high costs to serve, although you can implement some of them, such as field sales and support for example, quite quickly.

Because customers are in control and they de-mand cross-channel customer service, you will de-liver that cross-channel customer service across combinations of self-service and assisted-service touchpoints.

Consistent Cross-Channel Customer Service

We’ve discussed the need to deliver a consistent cross-channel customer experience many times. Fundamental requirements are a consistent view of your customers and a consistent context for the business that they want to do with you. Wherever they interact with you, you should know who they are. Whenever they interact with you, you should pick up where they left off in their Customer Sce-nario®, managing that Customer Scenario across channels and across interaction sessions.

CROSS-LIFECYCLE CUSTOMER SERVICE

Your customers’ activities with you traverse the phases of a lifecycle, from the first step of the first piece of business that they do with you through the time when they stop buying and using your products and services. Between those points, customers per-


Framework for Evaluating Cross-Channel, Cross-Lifecycle Customer Service Products • 47

Cross-Lifecycle Customer Service

PLAN

SELECTREPLACE

MAINTAIN BUY

EXPLORE

USE

My Account

Information

SUPPORT


Illustration 1. This illustration shows the phases of the customer service lifecycle around the core of (customer) support and the focus of the customer, represented by the proxy of your customer information.

form various activities that we can associate with phases of a lifecycle. These phases are:

• Renew

Table A lists examples of the activities in each of these phases. Illustration 1 shows these phases around the core of (customer) support and the focus of the customer, represented by the proxy of your customer information.

• Plan • Explore • Select • Buy

• Use • Maintain

Customers Need Your Help to… Phase Activities

Plan • Determine customer, business, and technologies strategies • Determine product requirements

Explore • Learn about products, product applications, and related tools • Get recommendations for products



Customers Need Your Help to… (continued)

Phase Activities

Select • Compare products • Configure products • Get/Negotiate prices for products

Buy/Replace • Buy products • Check order status • Install products • Deploy products as pilots • Renew product entitlements • Replenish exhausted supplies

Use • Consume, use, and apply the product or service

• Deploy products into production environments

• Monitor and measure product performance, availability, efficiency, and effective-ness

• Learn about the availability of patches, fixes, and upgrades

Maintain • Diagnose problems • Get fixes to problems • Create and manage incidents/cases for new problems • Check incident status • Return products • Access and update customer information

© 2005 Patricia Seybold Group Inc. Table A. Customer lifecycle phases and activities are listed in this table.

These phases typically occur in sequence. It’s a

natural order of doing business. But it’s also com-mon that customers’ behavior won’t always follow this order. Customers who need help using your product, for example, may hop back in the lifecycle to select and buy a complementary product. Custom-ers who are exploring possible solutions may test the facilities you offer for product maintenance before they buy. It’s also important for you to try to influ-ence your customers’ behavior. For example, once a customer purchases and deploys one of your prod-ucts, the customer will likely perform the activities of the use and maintain phases for some period of time. You’d like the customer to make additional purchases. So you might make a marketing offer to the customer that will drive the customer back into the select and buy phases.

Whether the phases are followed in sequence or whether customers act less predictably, customers need service for every activity of every phase of

their lifecycles. If you want to build long-term, prof-itable relationships with your customers, then you must create a cross-lifecycle customer experience that delivers excellent service at every phase and every activity of the lifecycle.

AN EVALUATION FRAMEWORK FOR CROSS-LIFECYCLE CUSTOMER SERVICE PRODUCTS

We can help you create and implement a cus-tomer experience that delivers excellent cross-channel, cross-lifecycle customer service by helping you select software products that best address your channels and the phases and activities of your cus-tomers’ lifecycles.

Through our work with you, our work under-standing software solutions, and our ongoing cus-tomer-centric analyses, we’ve identified the re-quirements for cross-channel, cross-lifecycle cus-



Cross-Channel, Cross-Lifecycle Customer Service Evaluation Framework

Operational Functionality

Analytic Functionality Architecture Product

ViabilityCompanyViability

EvaluationFramework

Organization

Environ-ments

Infrastructure

Structure

Customiza-tion

Integration

ProductBackground

InstalledBase

TargetMarket(s)

Pricing

ProductPlans

CompanyBackground

ProductLines

ChannelSupport

LifecycleSupport

Instrumen-tation

Real-TimeAnalysis

Reports

Analytics

Competition

Customer Base

Financials


Illustration 2. This illustration shows the top-level criteria and their factors for our cross-channel, cross-lifecycle customer service evaluation framework.

tomer service products and created a framework that will help you evaluate how well products address those requirements. Like all of our product evalua-tion frameworks, this one delivers the following sig-nificant benefits:

• It shortens your time to market.

• It saves time and reduces your costs in product evaluation, comparison, and selection.

• It reduces your risks in product evaluation, com-parison, and selection.

The framework enables you to make apples-to-apples comparisons on the most important product evaluation factors. Then our product evaluations against the framework speed and simplify your work even more.



Evaluation Framework for Cross-Channel, Cross-Lifecycle Customer Service

The framework for cross-channel, cross-lifecycle customer service has five top-level evaluation crite-ria and sets of factors for each top-level criterion. We show the criteria and their factors in Illustration 2. In the following sections, we examine the criteria and their factors in detail. The top-level criteria are:

• Cross-channel and cross-lifecycle operational support

• Cross-channel and cross-lifecycle analytic sup-port

• Architecture

• Product viability

• Company viability

CROSS-CHANNEL, CROSS-LIFECYCLE OPERATIONAL SUPPORT

In our evaluation of channel and lifecycle sup-port, we’ll describe and analyze the operational ca-

pabilities that a product packages for each key activ-ity of every lifecycle phase and on which channels it delivers those capabilities. For example, an ecom-merce product may implement the activities of the plan, explore, select, and buy lifecycle phases for the Web channel for both suppliers and their partners. Or a customer service product (unfortunate name, but we’ll have to live with it) may implement some of the activities in the buy and maintain phases for assisted channels.

Think of the operational support requirements for your cross-channel, cross-lifecycle customer service experience as a two-dimensional matrix, as follows:

• Each row represents a phase of the customer service lifecycle.

• Each column represents a channel through which your customers and partners interact with you.

So each cell is the intersection of a phase and channel. Your goal is to have applications in every cell—applications that perform and analyze the cus-tomer service experience that you deliver for every combination of phase and channel. Table B shows an empty customer service experience matrix.

Cross-Channel and Cross-Lifecycle Operational Support Customer

Lifecycle Phase Self-Service Assisted

Plan

Explore

Select

Buy

Use

Maintain

Renew

© 2005 Patricia Seybold Group Inc. Table B. This table displays an empty cross-channel, cross-lifecycle customer service experience matrix. Your goal is to select and implement those products that best address your requirements for each channel/phase cell of the matrix. Our evaluation framework will help you make that selection.



Cross-Channel and Cross-Lifecycle Opera-tional Capabilities

Completing Table B for a product is the first of two steps in evaluating a cross-channel, cross-lifecycle customer service product’s operational ca-pabilities. A completed Table B shows the channels and lifecycle phases that a given product supports. The second step looks in detail at how the product’s functionality addresses the activities within the life-cycle phases. We fill in another capabilities table to examine the functionality. In each row we’ll list an activity in one column and we’ll describe the prod-uct’s functionality for that activity in another. Then, we’ll analyze that functionality. Table C shows an empty activity functionality table.

Don’t expect any product or even any product suite to fill up these tables. We’ve yet to see a prod-uct or product suite cover all of the key channels and package the functionality that supports every activity of every phase of the customer lifecycle. The evalua-tion of operational capabilities will show gaps that you’ll have to fill with additional products in order to deliver a complete customer experience.

CROSS-CHANNEL, CROSS-LIFECYCLE ANALYTIC SUPPORT

Cross-channel, cross-lifecycle customer service products implement your operational processing, the applications that do your business. They execute transactions like reserve a seat, process a payment, or renew a subscription. It’s critical to measure, monitor, and analyze how well these applications perform their jobs relative to the customer experi-ence. You use the results of this analysis to refine operational processing, thereby improving the cus-tomer experience that you deliver. Every cross-channel, cross-lifecycle customer service product should support this operations-analysis-refinement loop. For example, with a contact center application, you should measure, among many key metrics, cus-tomer hold time. When its value exceeds a threshold, you should consider any of several remedies includ-ing adding call center staff or improving self-service capabilities in order to deflect calls.

Lifecycle Activity Functionality Table Lifecycle

Phase Capabilities

Plan

Explore

Select

Buy

Use

Maintain

Renew

© 2005 Patricia Seybold Group Inc. Table C. This sample table lists the activities of the cross-channel, cross-lifecycle customer service lifecycle. When we evaluate specific products, we describe the functionality of those products for each lifecycle activity in a table like this one.



The factors that we evaluate for analysis are:

• Instrumentation • Real-time analysis • Reports • Analytics

We describe these further in Table D.

ARCHITECTURE

Architecture defines how cross-channel, cross-lifecycle customer service products are built, how they work, and how they’re deployed. Architecture is a very important factor in evaluating customer self-service products. Why? Two big reasons: First, no product exactly reflects the way that you do busi-ness. So you have to customize its look and feel, its application logic, and its data. Second, no cross-channel, cross-lifecycle products supports all of your

channels and every phase of your customer lifecycle. So you have to integrate it with other products to create a comprehensive and consistent customer ex-perience. Customization and integration are two elements of architecture and are key determinants in how easy, costly, and time-consuming your work in implementing a product will be. The other elements of architecture also contribute to the cost and effort of product implementation.

For evaluating customer service products, we’ll consider the following aspects of architecture:

• Organization • Environments • Infrastructure • Structure • Customization • Integration

Cross-Channel, Cross-Lifecycle Customer Service Analytic Capabilities Factor Description

Instrumentation Information that represents how well a cross-channel, cross-lifecycle product performs in delivering a customer experience should be readily available from the product itself. A product that is instrumented prevents your having to dig into its internals to capture per-formance information. For example, an online product configurator should be instru-mented to record which products are configured and which configured products are placed in customers’ shopping baskets.

Real-Time Analysis

For many operational applications, you need to know how well they’re performing in real time. You’d prefer not to (or you can’t wait to) move performance data to a data ware-house and run queries and analytics against it. For example, you might like to track your highest priority defect incidents for your top customers as they occur and to display them on the dashboards of your customer support management team. If the number of inci-dents crosses a threshold value, or if the time that any incident remains unresolved is greater than a threshold time, then you might automatically trigger an event to make an onsite visit.

Reports Cross-channel, cross-lifecycle customer service products should package reports that present how well they’re performing. These reports should present instrumented informa-tion in easily understood formats.

Analytics Sometimes reports aren’t enough, and analytic processing is required in order to under-stand cross-channel, cross-lifecycle performance. For example, you might use data min-ing analytics to identify the factors that most influence customers to renew your subscrip-tion-based offerings (like product maintenance).

© 2005 Patricia Seybold Group Inc. Table D. The analysis factors of the cross-channel, cross-lifecycle evaluation framework are listed and described in this table.



We describe these further in Table E.

Architecture Factor Description

Organization and Environments

Organization and environments describe high-level aspects of a product’s architecture. Examples of organizations are two-tier and three-tier client/server and three-tier Web-based architectures. Web-based organization is preferred for most applications. It pro-vides the broadest and most flexible access.

In environments, we specify the details of the organizational components. For example, the environments of a three-tier Web organization include the clients, server platforms, and databases it supports. Environments are easy architectural factors to evaluate, yet these factors can be showstoppers. If your installation has standardized on the IBM DB2 database, and a product supports only Oracle10g and Microsoft SQL Server 2000, then that product won’t be a good fit for you.

Infrastructure By infrastructure, we mean the deployment environment for a cross-channel, cross-lifecycle customer service product. A deployment environment provides runtime services like request handling, process and thread management, memory management, and secu-rity. Simply, products should deploy on J2EE and/or Microsoft .NET infrastructures. It’s not uncommon for a product to provide some of its own deployment services. For exam-ple, J2EE doesn’t specify a data access standard. So products must provide their own data access mechanisms.

Structure Structure describes how a product is built. For structure, we examine a product’s user interface, application logic, data, and content. We also look at how a product is configured and whether a product implements a service-oriented architecture (SOA).

By understanding the structure of a product’s user interface, application logic, and data, you can get an idea of the level of skill and level of effort required for customization and integration. You’ll also be able to understand how similar or dissimilar a product is to other products that you’ve already implemented.

For user interfaces, we like to find Web pages built to the JSP (Java Server Pages) or ASP (ActiveX Server Pages) specifications. We also like to find a template-based ap-proach to building the product’s UI.

In application logic, modularity and granularity are the keys. Logic should be segmented into sets of state-less business (logic) objects and state-full business (data) objects. A product should not have so many of each as to make itself impossible to manage, nor so few as to make itself monolithic and difficult to customize, integrate, and tune—on the or-der of a hundred or so for each major business function. Each business object should have published interfaces accessible through a range of language bindings. It’s a plus when the interfaces are encoded in or accessible through XML.

For data, the keys to good structure are richness and flexibility. Predefined data structures like those for customers and products should be rich enough to minimize customization but sufficiently flexible to represent your customers and products.

SOA is an extension of application logic. Support for SOA means that business objects are organized into collections (one or more of them) that implement a modular service and that the service has its own interface. Ideally, but not likely, a product might be pack-aged by services, too. Some products have SOAs that implement Web Services. That’s a plus that will facilitate integration, especially with external, off-site applications.



Architecture (continued)

Factor Description

Customization Structure specifies a product’s internals and interfaces and gives you an idea of the effort required to customize the cross-channel, cross-lifecycle customer service product to the ways that you do business with your customers. But a product should also provide tools to facilitate your customization effort. Web page templates and template samples are quite useful for customizing a product’s look and feel. Configuration files or metadata are handy tools for helping you customize application logic. And configuration files and metadata, as well as user-defined fields and user-defined tables, simplify data customization.

In addition, products should be internationalized. You should be able to purchase versions of a product for the locales in which you’ll implement it (e.g., a French version for your Paris headquarters and a Canadian English version for your contact center site).

Localization is another form of customization. In situations in which internationalized products help your users, localizable products help your customers. For example, you’d like to deliver campaigns that are localized (to the language and currency of their target segments). Or you’d like to implement locale-specific knowledgebases of break/fix infor-mation. Minimally, products can provide localization through Unicode data encoding of text data, currency attributes of pricing information, open and flexible currency conversion rules and routines, and localizable application logic for calculating taxes. Better still, prod-ucts should package tools and samples that minimize your localization efforts and reduce the skill level needed for those efforts.

Integration To deliver a comprehensive customer experience, you’ll be integrating cross-channel, cross-lifecycle customer service products to cover all of the channels through which you do business and all of the phases of your customers’ lifecycles. You’ll also be integrating these customer-facing products with your back office systems in order to automate your business process. A product’s structure will give you an idea of the skill level and effort required for this integration. Products should package or provide integration facilities, too. The facilities should include integration tools and packaged integrations with popular products—the more, the better.

© 2005 Patricia Seybold Group Inc. Table E. Architecture factors are listed and described in this table.

PRODUCT VIABILITY

You want to purchase a cross-channel, cross-lifecycle customer service product that is well proven and widely used for your type of business. You also want a product that you can implement within a budget and schedule and a product that will continue to be able to address your requirements in future versions. In other words, you want a viable product.

We consider the business aspects of customer service products in the product viability section of our framework. A product’s viability is much easier to evaluate than its channel support, lifecycle sup-port, or architecture, but the factors that contribute to product viability can be real deal breakers. For ex-

ample, a product may be targeted for industry seg-ments other than the ones in which you do business. A product may be brand new with no reference cus-tomers in companies similar to yours. Or the prod-uct’s price might break your budget.

We’ve identified six factors in evaluating product viability. They are:

• Product background • Installed base • Target market(s) • Pricing • Product plans • Competition

We describe these further in Table F.



Product Viability

Factor Description

Product Background

In product background, we present the product’s release history, from date of its introduction to the date of its current version. Versions at regular intervals (once a year is good) demonstrate a good development plan and a supplier’s ability to execute the plan to deliver products on a timely basis. More than one new version per year or several years between versions could in-dicate problems. Your organization could be kept very busy doing installations and then re-implementing your customizations and integrations when a supplier introduces new versions frequently. On the other hand, there might be significant problems when a supplier is slow to introduce new versions. For example, its R&D organization might have been reduced in staff as a result of poor company performance resulting from economic conditions or mergers and ac-quisitions.

Sometimes, the lack of a long release history is not a negative. New products may be risky for those of you who like to stay off the leading edge, but new products can be functionally innova-tive, incorporating the latest technology standards and/or addressing a new business area.

We also examine the supplier’s recent merger and acquisition history from the perspective of how that activity has contributed to the cross-channel, cross-lifecycle product’s capabilities. Sometimes, M&A activity can result in a product that’s not seamless, causing you extra work in customization and integration.

Installed Base

Installed base is the number of customers who have purchased and implemented a product. A large installed base is a sign that a product really does address business requirements. But large is a relative term—again, the more, the better. We like to see at least fifty.

Target Market(s)

A product’s target market identifies the types of companies that a supplier views as the best fit for its product. Target markets typically have two dimensions: company size and industry seg-ment. If your company doesn’t fit either or both dimensions, then stop considering the product.

A product’s target market should be supported by both the product’s technology and the sup-plier’s marketing initiatives. Technology support is more important. Company-size-specific and/or industry-specific features and functions make your implementation of a product faster and reduce the scope of customization and integration.

Pricing For pricing, we try to provide a product’s implementation costs—the license fees and consulting services costs necessary to get a product up and running in your installation. Suppliers are not always willing to share their pricing, usually because their fees are negotiable. When we can provide pricing details, we will. Minimally, we’ll describe the pricing model, an entry price, and a typical price, as well as give an indication of a percentage of those prices that other companies have spent on consulting services.

Plans You don’t just buy the current version of a product. Your purchase is also an investment in the future versions of a product. It’s essential to know the product’s direction. Plans present the details of the next product version and are an indication of the longer-term direction in which the supplier wants to take its product.

Competition In competition, we’ll identify alternative products and highlight key differentiators. Understand-ing a product’s competition can reduce the risk in selecting a particular product and provide ammunition for its justification.

© 2005 Patricia Seybold Group Inc. Table F. Product viability factors are listed and described in this table.



COMPANY VIABILITY

You want to purchase a viable product from a vi-able company. A viable company is a going concern with increasing revenue, profits, numbers of custom-ers, and numbers of products.

We consider the business aspects of the supplier company of cross-channel, cross-lifecycle customer service products in the company viability section. Company viability is a little more difficult to exam-ine than product viability because it’s more subjec-tive and it’s more difficult to obtain source informa-tion. For example, what is the effect of a company’s age on its viability? Also, because private companies are not required to disclose their financials, it’s vir-tually impossible to assess financial health.

We’ve identified four factors for examining company viability. They are:

• Company background and status

• Products and product lines outside customer ser-

vice

• Total customer base

• Financials

We describe these further in Table G.

THE BOTTOM LINE

A cross-channel, cross-lifecycle perspective makes every type of product that touches or faces your customers a customer-service product. We plan to evaluate several types of products against this framework, including: • Campaign management products

• Ecommerce products

• Contact center products

• CRM products and product suites

Company Viability

Factor Description

Company Background and Status

For company background and status, we present the high-level details that characterize a com-pany—its founding, ownership, and number of employees. We also examine recent changes in these details and the causes for those changes.

Products Within the products factor, we list and describe a supplier’s other offerings. The existence of other products makes a company more viable, especially if its cross-channel, cross-lifecycle customer service product is new. Other products demonstrate a supplier’s ability to develop, market, sell, and support products. On the other hand, if a supplier’s other offerings are widely different from cross-channel, cross-lifecycle customer service, then its other products might not add to its viabil-ity.

Customer Base

For the installed base factor of product viability, we presented the number of customers who have implemented the product. For the customer base factor of company viability, we add the number of customers who have implemented a company’s other products, if it has any. Customer base indicates a supplier’s ability to acquire and retain customers. If the cross-channel, cross-lifecycle product is new, then a large customer base mitigates your risk in its selection.

Financials For the financials factor, we present recent financial metrics—revenue, license revenue, and net income. When all these metrics are increasing, it’s a minimal indication that a supplier is a going concern. When they’re not, then we try to explain why. For example, we’re concerned when li-cense revenues are small relative to total revenues, when a company has incurred frequent and growing losses, and when revenue is declining in a growing economy.

© 2005 Patricia Seybold Group Inc. Table G. Company viability factors are listed and described in this table.



• Partner relationship management products

The result of our evaluations will let you under-stand which channels and which lifecycle phases and activities product types and particular implementa-tions of those types support.

• “Customer service” products (products that offer problem diagnosis, problem resolution, and inci-dent/case management capabilities)

• Customer analytics products



Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix A Blank Matrix to Facilitate Your Evaluation Process for Customer Support Offerings


FACILITATING YOUR EVALUATION PROCESS

Evaluation Framework

In our “Framework for Evaluating Cross-Channel, Cross-Lifecycle Customer Service Prod-ucts,”1 we presented the criteria that we believe are important when evaluating how well any given of-fering will support an organization’s needs. In the framework, we emphasize repeatedly that each or-ganization is different, with different skills and re-quirements, and, as such, you should evaluate which features are important to your situation and which may be traded off without harm.

Customer Support

First, let’s look at what we mean by “cross-lifecycle” in “cross-channel, cross-lifecycle cus-tomer service.” Your customers’ activities with you run from the first step of the first piece of business that they do with you through the time when they stop buying and using your products and services. Between those points, customers perform various activities that we can associate with phases of a life-cycle. These phases are: plan, explore, select, buy, use, maintain, and renew/replace.

Whether these phases are followed in sequence or whether customers act less predictably, customers need service and support for every activity of every phase of their lifecycles. If you want to build long-

1 See “Framework for Evaluating Cross-Channel,

Cross-Lifecycle Customer Service Products”, Mitchell I. Kramer, September 9, 2004, http://dx.doi.org/10.1571/fw9-9-04cc.

term, profitable relationships with your customers, then you must create a cross-lifecycle customer ex-perience that delivers excellent service at every phase and for every activity of the customer lifecy-cle.

Of course, no single product or product suite can address every phase and every channel of the cus-tomer service experience. You’ll be selecting, pur-chasing, and implementing multiple products to de-liver a complete customer experience.

For the past few months, we’ve been evaluating products and product suites that have been designed especially to support activities in the use lifecycle phase, helping your customers diagnose, report, and resolve problems that they’re having with your products.

You might know these offerings as customer support or, even, customer service products. Those that we’ve evaluated against our cross-channel, cross-lifecycle customer service product evaluation framework are:

• ATG Adaptive Customer Assistance • ATG KnowledgeCenter • eGain Service • Kana Service Solutions • Kanisa Application Suite • RightNow CRM • ServiceWare Enterprise

Many of these offerings are also useful for sup-porting activities in the plan and explore lifecycle phases, helping you customers learn about your products and answer questions about them.

All of the offerings take a similar approach to supporting your customers’ activities. They don’t


http://dx.doi.org/10.1571/fw9-9-04cc

Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix • 59

actually package hard-coded customer service func-tionality in the manner, say, of an ecommerce sys-tem that has packaged product exploration function-ality; product selection (shopping cart) functionality; and order capture, processing, and management functionality. Instead, these products provide frameworks of content, metadata, search, navigation, and process management capabilities that you cus-tomize in order to implement the products and ad-dress your customer service requirements. We’ve added an evaluation criterion specifically to help you evaluate and compare these frameworks. We call this criterion “knowledge management framework.” Knowledge management is the term that these prod-uct offerings use for their content, metadata, search, navigation, and process management capabilities. (See Table A.)

Our Evaluation Framework in Matrix Format

To assist you in your evaluation efforts of prod-ucts designed specifically to support your custom-ers’ problem diagnosis, reporting, and resolution activities, we are presenting the criteria and their explanations in matrix form. There’s a separate table for each of the major evaluation criteria. The first (leftmost) column of each table presents the evalua-tion sub-criteria. The second column presents an explanation of a sub-criterion when appropriate.

We’ve also inserted a few extra, blank columns. You can use them to notate the capabilities of the products that have made it on your short list. Feel free to delete features that you don’t require and highlight those capabilities that are of highest prior-ity in your environment.

We hope you find this matrix useful for prioritiz-ing capabilities as well as for collecting and organiz-ing information about cross-channel, cross-lifecycle customer service alternatives.



Knowledge Management Framework Evaluation

Evaluation Criterion Cross-Channel, Cross-Lifecycle Offering Capabilities

Product: Product: Product:

Content What are the organization, structure, and components of the offering’s content model? Are tools provided to help you create and maintain the content that customers and agents search and navigate to perform cus-tomer support activities?

External Content How does the offering leverage and/or reuse your existing external content?

What types of external content are sup-ported?

Metadata

Taxonomy Does the offering have a taxonomy inde-pendent of its content?

If so, then what is the organization and struc-ture of that taxonomy?

Findability What metadata does the offering have to help your users find content?

Management What metadata does the offering have to help you manage content?

Search What are the offering’s search capabilities?

Navigation What are the offering’s navigation capabili-ties?



Knowledge Management Framework Evaluation (continued)



Process Management

Does the offering package customer-touching process management capabilities? If so, then how do those capabilities help implement your customers’ Customer Sce-narios®?

Samples Does the offering package samples or ex-amples of taxonomies, content components, processes, or Web pages?


Table A. In this table we list and describe the sub-criteria of the knowledge management framework criterion of our evaluation framework for cross-channel, cross-lifecycle customer service offerings.

Cross-Lifecycle Operational Capabilities Evaluation

Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities


Plan Phase

Determine technical and budget require-ments for new or additional products or services.

Learn about products that address re-quirements.



Cross-Lifecycle Operational Capabilities Evaluation (continued)




Plan Phase (continued)

Determine whether currently installed products address those requirements.

Determine what ad-ditional product types and products ad-dress those require-ments.

Be aware of new products or product upgrades that ad-dress new or addi-tional requirements.

Understand best practices in the use of products that ad-dress requirements.

Explore Phase

Find products that address require-ments.

Compare products that address re-quirements by fea-tures, functions, and price.







Explore Phase (continued)

Be aware of mer-chandising offers on the products or product alternatives that address re-quirements.

Select Phase

Select products that address require-ments.

Request and receive quotes (RFQ proc-ess) for products that address require-ments and request and receive propos-als (RFP process) for products that ad-dress requirements.

Negotiate prices, terms, and condi-tions for RFQ and RFP responses.

Be aware of ordering incentives on se-lected products.







Select Phase (continued)

Configure products that address re-quirements.

Buy and Renew/Replace Phases

Order selected prod-ucts via credit card or on account.

Deliver ordered products.

Expedite delivery of ordered products.

Install and deploy selected products within a pilot project.

Use Phase

Install, configure, and deploy pur-chased products in production.







Use Phase (continued)

Diagnose (installa-tion, functionality, performance, avail-ability, integrity, se-curity, etc.) problems with deployed prod-ucts.

Report problems with deployed products.

Be aware of the availability of fixes that apply to prod-ucts that are de-ployed.

Fix problems with deployed products.

Maintain Phase

View and modify customer informa-tion, including identi-fication information, account information, contact information, security information, role information, and preference informa-tion.







Maintain Phase

View order status, order details, and order history.

Modify orders.

Initiate returns.

View incident status, incident details, and incident history.


Table B. In this table, we list and describe the sub-criteria of the cross-lifecycle operational capabilities criterion of our evaluation framework for cross-channel, cross-lifecycle customer service offerings.

Analysis Evaluation



Instrumentation What information does the product collect as customers interact with the cross-channel, cross-lifecycle customer experience that you deliver by implementing the product?

Real-Time Analysis What real-time analyses of the cross-channel, cross-lifecycle customer experi-ence that you deliver with the offering are packaged with it? Can you configure those analyses? Can you trigger their processing? Are events and notifications included?



Analysis Evaluation (continued)



Reports What are the packaged reports for gaining insight into the customer experience that you deliver with the offering? What tools are in-cluded to customize packaged reports or create new ones?

Analytics What analytics are packaged in the offering? (Analytics perform more complex processing than required for reports and provide deeper insight than data manipulation and arithmetic processing.)


Table C. In this table we list and describe the sub-criteria of the analysis criterion of our evaluation framework for cross-channel, cross-lifecycle customer service offerings.

Architecture Evaluation



Organization and Environments

Organization describes high-level aspects of a product’s architecture—for example, two-tier client/server, three-tier client/server, or three-tier Web-based architectures.

Environments specify the details of an offer-ing’s organizational components. For exam-ple, the environments of a three-tier Web organization include the clients, server plat-forms, and databases it supports.



Architecture Evaluation (continued)



Infrastructure By infrastructure, we mean the offering’s deployment environment—most commonly J2EE or .NET.

Structure Structure describes how a product is built.

User Interfaces For user interfaces, are the offering’s Web pages built to the JSP (Java Server Pages) or ASP (ActiveX Server Pages) specifica-tions? Does the offering package a template-based approach to build the product’s UI?

Application Logic Is the offering’s application logic segmented into sets of modular, coarsely granular state-less business (logic) objects/components and stateful business (data) ob-jects/components? Does each business ob-ject/component have published interfaces accessible through a range of language bindings?

Data Are the offering’s data rich and flexible? Are its predefined data structures (like those for customers and products) rich enough to minimize customization but sufficiently flexi-ble to represent your customers and prod-ucts?

Customer Data Does the packaged customer data model represent all of your customers? If not, can it be easily customized?






Product Data Does the packaged product data model rep-resent all aspects of your products? If not, can it be easily customized?

Content What content management capabilities are packaged with the offering? Are they suffi-cient to enable you to create and maintain the content that customers and agents navi-gate and search to perform customer ser-vice/support activities?

Internationalization Does the offering package facilities to help you create locale-specific implementations of content and customer and agent interfaces? Can you buy a language-specific version of the offering?

SOA Within the structure of application logic, are business objects/components organized as services—or chunks of functionality—thereby implementing a service-oriented ar-chitecture (SOA)?

Customization Which resources can be customized? What tools and facilities are packaged to perform customization? What level of technical skills are required for using these tools and facili-ties?






Integration What facilities does the offering package to help you integrate it with external systems and data? For what particular application products does the offering package integra-tion? What level of technical skills are needed to use integration facilities and packaged integrations?


Table D. In this table we list and describe the sub-criteria of the architecture criterion of our evaluation framework for cross-channel, cross-lifecycle customer service offerings.

Product Viability Evaluation



Product Background

Current Version

Current Version Date

Introduction Date When was the first version of the offering introduced?

Development Approach

Does the offering’s vendor develop the offer-ing in house, or is development outsourced?

Key Acquisitions What are the acquisitions that have resulted in significant improvements to the offering?



Product Viability Evaluation (continued)



Installed Base

Number of Customers

How many companies have purchased the offering and are currently using it?

Reference Customers

What companies are the vendor’s reference customers?

Target Market(s) What size companies, what geographies, and what industry segments does the ven-dor target for marketing and selling the offer-ing? Does the offering package technology for these target markets?

Pricing What are the pricing models for the product? What are the entry price and a typical instal-lation price? How much consulting service (as a percentage of price) is typically re-quired to implement the offering?

Product Plans What are the short-term improvements that the vendor plans for the offering? When will they be delivered? What is the vendor’s long-term product strategy?


Table E. In this table we list and describe the sub-criteria of the product viability criterion of our evaluation framework for cross-channel, cross-lifecycle customer service offerings.



Company Viability Evaluation




Company Background

Founding

Ownership

Headquarters

Employees

Product Lines What other product lines does the vendor supply?

Customer Base What is the vendor’s total customer base?

Financials

Total Revenue for the Four Most Recent Quarters

License Revenue for the Four Most Recent Quarters

Net Income for the Four Most Recent Quarters



Company Viability Evaluation (continued)




Financials (continued)

Current Assets for the Four Most Recent Quarters


Table F. In this table we list and describe the sub-criteria of the company viability criterion of our evaluation framework for cross-channel, cross-lifecycle customer service offerings.


an executive's guide to crm - free

Documents