Patricia Seybold Group

Patricia Seybold Group’s Executive Series

Trusted Advisors to Customer-Centric Executives

An Executive’s Guide to CRM How to Evaluate CRM Alternatives by Functionality, Architecture, & Analytics By the Patricia Seybold Group

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

210 Commercial Street, Boston, MA 02109 • Phone 617.742.5200 • Fax 617.742.1028 • www.psgroup.com

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

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 increase business

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 relationship. Companies that adopt this customerfocused and customer-driven approach are, thus, customer-centric. The inverse of customer-centric is productcentric. 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

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 frequently true, because b) and g) carry too much negative connotation and because a), while correct, is too narrow and, perhaps, even vendor-centric in its correctness. 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 approach is to be customer-focused and customer-

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 corporate business objectives, too, or at least your corporate marketing objectives; but the way that you state them and your strategies to achieve them may not be sufficiently customer-focused. As a philosophy, customer-centricity drives you to view your entire business from the perspective of your customers. CRM IMPLEMENTS MARKETING, SALES, AND SERVICE BUSINESS PROCESSES CRM implements the marketing, sales, and service 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

MANY CRM APPLICATIONS

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

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

CRM Must Support All Touchpoints That brings up another important point. Your customers interact with your direct sales reps, contact center reps, and Web applications. These interactions occur through a variety of touchpoints—the phone, face-to-face, a Web site, etc. Your CRM business processes have to support all these touchpoints, 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 defining a single customer data model and customer data implementation or, more practically, by integrating 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 becoming 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 customers across all the touchpoints through which they interact with you. This consistent “customer experience” 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.

© 2005 Patricia Seybold Group

Customer-Facing Applications The key, customer-facing CRM applications are contact center, sales force automation, and field service, 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 applications 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 reflect a customer focus. These upgrades should give them that single and consistent view of your customers and your company and integrate them with the business processes that support their marketing, sales, and service functions.

A Customers.com® Research Service

4 • An Executive’s Guide to CRM

CRM Business Processes, Touchpoints, and Customer Information

Customer Systems Customers

Touchpoints Direct Sales

Contact Center

Web

E-mail

POS

Business Processes Contact Center

Contact Center

Contact Center

Applications CRM Applications

Back Office Applications

Supplier 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 selfservice customer support, described briefly in Table B. We say “customer touching” because your customers interact directly with the applications rather than through a company representative.

A Customers.com® Research Service

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. Campaign management was the first attempt to automate the marketing business process, allowing companies to deliver offers to more markets more (cost) effi-

© 2005 Patricia Seybold Group

What Is CRM? • 5

CRM Applications Customer Systems

Customers

The Customer Experience

Customers Seller

Customer Touching Systems Self-service Customer Support

Field Service Automation

Integration Back Office Systems

Customer Intelligence

Sales Force Automation

Campaign Management

Integration

Customer Facing Systems Contact Center

ECommerce

Users

Seller Suppliers

Supplier Systems

© 2005 Patricia Seybold Group Inc.

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. Electronic commerce was a breakthrough application. It gave companies a new touchpoint and a way to expand their market reach and presence, automating completely the online marketing, sales, and service processes. Electronic commerce also gave us automated personalization, a customer-centric approach to treating each customer as a market of one. Selfservice customer support was the next step for customer service. While contact center applications brought help desk capabilities to customers, self-

© 2005 Patricia Seybold Group

service customer support applications put this functionality 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 touching and facing touchpoints, allocating skilled mar-

A Customers.com® Research Service

6 • An Executive’s Guide to CRM

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 instructions found in a knowledge base or with incidents that represents requests for service 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, service orders, service contracts, service schedules, and service calls. They provide planning, 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 offers to targeted leads, prospects, and customers on demand, on a schedule, or in response to business events through direct mail, email, contact center, field sales, and Web touchpoints. Ideally, these applications should be able to record responses to offers.

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

A Customers.com® Research Service

© 2005 Patricia Seybold Group

What Is CRM? • 7

However, customer-touching applications must have excellent performance and provide a great customer experience. This isn’t as vital for customerfacing CRM applications because your great reps can insulate customers from not-so-great applications. Customer-Centric Intelligence Applications Customer-centric intelligence applications are analytic applications that analyze the results of operational processing. Their results can be used to improve the efficiency and effectiveness of operational CRM applications. Customer-centric intelli-

gence (what we have, in the past, called Customer Intelligence) is the term we use to describe customer-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 Application

Description

Data Warehousing

Reporting

© 2005 Patricia Seybold Group

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

A Customers.com® Research Service

8 • An Executive’s Guide to CRM

Customer-Centric Intelligence CRM Applications (continued) Application Analytic Applications

Description Analytic applications automate both the analyses that managers and analysts perform manually on reports and analyses based on statistical and pattern recognition 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 applications that deliver your customer experience in order to achieve the CRM objectives 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 initiatives. 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 customer 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 favorite formats. Your colleagues or your counterparts in other business areas have their favorites. These differences and different approaches to analysis may no longer work when you become a customer-centric company. You must have a single view of your customers 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 approaches analysis. Some organizations rely on statistical analysis and disdain data mining approaches such as clustering or neural networks. Other organizations distrust everything except the empirical information 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.

A Customers.com® Research Service

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 products that implements all the key customer-facing, customer-touching, and customer-centric intelligence 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 vendor. The leading CRM suite suppliers are (alphabetically) Oracle, PeopleSoft, Siebel, and SAP. E.piphany also provides a CRM suite that implements 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-

© 2005 Patricia Seybold Group

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.

•

FUNCTIONALITY. What the products do should closely reflect the way that you do business.

CRM Point Solution Suppliers

•

SINGLE AND CONSISTENT CUSTOMER VIEW. The products should minimize your ef-

CRM point solution suppliers offer products that implement one or two CRM applications. The advantages 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 intelligence applications. MarketFirst and Revenio specialize in marketing automation solutions, and companies such as SalesLogix focus on SFA tools.

forts to integrate and synchronize customer information. •

•

© 2005 Patricia Seybold Group

TOUCHPOINTS.

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 implementation. 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 integration and usage, are complex and strategic efforts that should touch every aspect of your organization. CRM projects require careful planning and meticulous execution. Here are a few key points to remember: •

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 automated. 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 incremental 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-

Selecting CRM Products Given the array of supplier types, the very large number of available products, and the strategic nature of the applications that they implement, your selection of CRM products is a critical and potentially complex decision. These are the critical decision factors to consider when making your product choices:

ACROSS

You’ve got to provide a consistent customer experience. You don’t want to code it yourself.

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 automation, and the product support aspects of contact center. They also all do an excellent job of integrating external applications and automating supporting business processes. We’ve been following ecommerce since 1996. The leading suppliers and products are (alphabetically) ATG Dynamo, Blue Martini 4, BroadVision Business Commerce and Retail Commerce, IBM WebSphere Commerce Suite, and Microsoft Commerce Server.

INTEGRATION

A Customers.com® Research Service

10 • An Executive’s Guide to CRM

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 customercentricity and have reasonable and demonstrable expectations for those steps.

A Customers.com® Research Service

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 satisfaction 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 relationships for granted. The continuous effort to earn loyalty will help maintain your customer focus and will grow those relationships. That’s CRM.

© 2005 Patricia Seybold Group

An Executive’s Guide to CRM

What’s Important in CRM Architecture? A Framework for Evaluation and Comparison By Mitchell I. Kramer, Sr. VP and Sr. Consultant, Patricia Seybold Group

NETTING IT OUT While you should select a CRM product primarily on its functionality, its architecture should be a key consideration in your decision. Why? Because a CRM product’s architecture will significantly influence the quality of the customer experience 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 evaluate the architecture of individual CRM and/or eCRM products and to facilitate their comparison with the other CRM products on your short list. Our framework has six evaluation criteria: environments, organization, infrastructure, structure, customization, and integration. This report describes and discusses the evaluation criteria of our framework for CRM architecture.

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 applications. 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 understand: 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 approach 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 major components and the interfaces between them. Interfaces are always between two components)

•

Infrastructure, which is the set of runtime services 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 requirements.

•

Integration, which complements and completes processing with the functionality of external applications.

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

12 • An Executive’s Guide to CRM

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 criteria to evaluate in your CRM product selection decision 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 particular products to even justify a change. So a CRM product must support the environments that are already supported by your organization. Table A lists the leading suppliers for CRM environments. Illustration 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 example, 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 implement and maintain. Look for interfaces that are standards-based and that support replication and distribution, characteristics that promote reliability and scalability. Most operational and analytic CRM products follow the example of fictitious “product A.” They’re built on three-tier, Web-based architectures. Analytical CRM products follow three-tier client/server architectures as well as Web architectures. With fewer concurrent users and more intensive processing 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 results of analytics or in using these to drive dashboards.

CRM Architecture Environments Environment Web Servers

Leading Suppliers •

Apache

•

IPlanet (Sun)

•

Microsoft

Server Platforms

• • •

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

Databases

• • •

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

• •

Sun Solaris Compaq Tru64 Unix

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

A Customers.com® Research Service

© 2005 Patricia Seybold Group

What’s Important in CRM Architecture? • 13

CRM Environments Web Servers

Apache Miscrosoft iPlanet

Server Platforms

Compaq Tru64 Hewlett-Packard HP-UX IBM AIX Microsodt WindowsNT/2000 Sun Solaris

Databases

IBM Microsoft Oracle

© 2005 Patricia Seybold Group Inc.

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 following types of components in their three tier organizations: • • •

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 applications. All processing is handled in the application server. Among the Web-browser clients, there’s re-

© 2005 Patricia Seybold Group

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 utilization, 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.

A Customers.com® Research Service

14 • An Executive’s Guide to CRM

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 interactive environment. These characteristics make for a superior customer experience. However, they can also be the cause of slow response and a less–thanintuitive 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 component in organization because they perform all application and system processing. They manage user requests, providing appropriate security, routing, and dispatching. They control the execution of application logic and database access that represents the response to user requests. And they return these responses to the user. Application servers most typically perform a broad range of functions: the transfer requests and responses with users, application processing, security, request management, dispatching, memory management, process management, database access, access to external systems, load balancing, failover, and many others. Application Servers handle the transfer of requests 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 requests 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 applications, 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

A Customers.com® Research Service

of the CRM suite suppliers, as well as the ecommerce suppliers, offer portal-based UIs. CRM databases have three dimensions. The first supports operational applications. The second supports data warehousing-based analysis. The separation 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 customizing CRM applications as well as for integrating them with external applications. Illustration 2 shows this general CRM product organization. INFRASTRUCTURE Infrastructure provides system-level, applicationindependent services for multiuser, shared resource systems like CRM applications. The services include basic request handling, queuing, routing and dispatching, process and thread management, memory management, database connection management, and transaction management as well as the more sophisticated 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 infrastructure for Internet applications. We hope that the days of product-specific, proprietary infrastructures 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 infrastructures for the middle tier application server component of CRM applications, both are relatively new technology. Many CRM suppliers have been offering their CRM and other application products for many years longer than J2EE and .NET infrastructures have been available and viable. Major modifications to organization and application logic would be required for these suppliers to deploy their applications on modern infrastructures. Such a move

© 2005 Patricia Seybold Group

What’s Important in CRM Architecture? • 15

CRM Organization Web Browser Client

Server Platforms

Application Server

Database

© 2005 Patricia Seybold Group Inc.

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 written in C++ and deploy on a BEA Tuxedo infrastructure. mySAP CRM applications are written in SAP’s ABAP 4GL and deploy on a proprietary infrastructure. (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 applications. PeopleSoft uses J2EE to handle the UI of its applications and provides the mechanisms to customize application functionality through Java components and to integrate external applications through XML interfaces. In addition, and very importantly, the major CRM suppliers have all announced that they will expose the functionality of

© 2005 Patricia Seybold Group

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 client/server among their offerings. They’re also moving 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 implementation of the new, hybrid infrastructures insulates you from complexity and cost. Look for products that bundle the old and the new application functionality and infrastructure in a single, integrated package at a single price, and avoid products that require you to purchase, implement, and support separate, infrastructure-specific components.

A Customers.com® Research Service

16 • An Executive’s Guide to CRM

CRM Infrastructure Client Web Browser

Server Platform Application Server Web Application Server Program Logic

System Services

Database Access

Portal

Database

Data Model

© 2005 Patricia Seybold Group Inc.

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 products with three-tier, Web-based organizations, have three types of components that define and describe its structure: •

Web pages

A Customers.com® Research Service

•

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 popular technologies, and when its program logic is implemented as coarsely-grained components, your work is simplified.

© 2005 Patricia Seybold Group

What’s Important in CRM Architecture? • 17

Web Pages

has become something of an industry-standard language for the program logic of Web applications. Java has significant advantages, but it’s not a requirement 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 componentbased development. Second, as with their infrastructures, 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 legacies, such as PeopleSoft and SAP, generate component-based program logic from metadata specifications. Developers almost never touch code, working instead with easier-to-understand metadata code descriptions.

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 combines HTML, VBScript or JavaScript, and COM components. JSPs and ASPs are quite similar. They support dynamic, visually-rich, and highlyinteractive 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 implement JSPs but, in order to BUSINESS RULES. Business simplify administration and to The deployment approach rules represent an organizamaximize performance, do not is not ideal because business rules tion’s policies and business include applets within Web and program logic are not practices. They qualify an oppage structure. (ASP-based in separate modules, but it works. erational CRM application’s products would analogously program logic at runtime at not include COM compokey points during processing. nents.) We’ve discussed these Like application logic, business rules should also be approaches within the section, “Organization,” implemented as coarsely-grained components that above. Note also that DHTML is not as widely used integrate seamlessly with the components that imas JSP or ASP. plement application logic. However, the components that implement business rules are developed and deProgram Logic ployed separately from program logic so that they The structure of a CRM product’s program logic can be modified independently. Their development should be coarsely-grained components. Compoenvironment should be visual and easy to use so that nents are object-oriented structures that have interbusiness managers, not developers, may specify faces and implementations. A product should not them. Their tools should provide easy-to-use dehave so many components as to make finding an ployment mechanisms because you’ll change them individual component hard to do in order to facilitate frequently. configuration, customization, and integration. There In practice, we’ve seen among the large CRM should not be so few as to make a product monosuite suppliers that business rules are specified and lithic. The supplier should publish the interfaces of implemented within the metadata of CRM applicaall a product’s components. That’s essential for custions. The metadata is then used to generate applicatomization and integration. Also, to maximize scaltion modules or components which combine proability and performance, components should be orgram logic and business rules. As a result, changing ganized into stateless components that provide the ebusiness rules requires regenerating the entire appliCRM services and stateful components that store cation module. Metadata development environments and manage the information that changes as a result are quite visual, and it’s usually quite clear how to of performing the services. make business rules changes. The deployment approach is not ideal because business rules and proJAVA? Components are implemented in a programgram logic are not in separate modules, but it works. ming language such as Java, C++, or a 4GL. Java

© 2005 Patricia Seybold Group

A Customers.com® Research Service

18 • An Executive’s Guide to CRM

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 representation of the information that it processes. Data models for CRM, ERP, and supply chain applications represent the business entities involved in the processing that they perform. For example, a supply chain application’s data model will typically represent catalogs, products, purchase orders, invoices, advanced shipping notices, and the like. Most significantly, 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 evaluating 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 interact with you (directly, through the contact center, through the Web, or through email). The best experiences result in the most satisfied and loyal customers, and the most satisfied and loyal customers are willing to do more business with you. So how does a customer data model enable customer-centricity? It’s absolutely true that the better you know your customers, the better the relationships that you can create with them, the more satisfying 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-

A Customers.com® Research Service

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 operational 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 systems in a manner that both facilitates the execution of analytics and maximizes complex query performance. 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 information 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 richness 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 applications. Customer data is the most private and sensitive information that you manage. Access to it should be very carefully controlled. We like schemes that provide role-based access with privilege levels that control 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 access.

© 2005 Patricia Seybold Group

What’s Important in CRM Architecture? • 19

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 organization, 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 business between you and your customers. For B2B relationships, this information represents the contracts between you and your customers. Contracts have product, price, quality of service, and payment terms. They are associated with a customer’s organizational entity, and they have identification, role, and authority information 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 identification information.

Marketing

Marketing information should include customer value, customer profitability, the segments to which a customer belongs, and scores and indicators for loyalty, satisfaction, 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 responses 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 include 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 complaints, 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 represented 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-

© 2005 Patricia Seybold Group

plications as they are integrated with new CRM products in order to provide a consistent customer experience across all touchpoints and business processes. 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 attributes must be accessible consistently across all the touchpoints through which you interact with your customers and across all your CRM applications.

A Customers.com® Research Service

20 • An Executive’s Guide to CRM

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 consistent 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 consistent foundation.

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

CUSTOMIZATION All CRM applications get customized. In fact, all operation applications get customized to reflect the characteristics and nuances of implementing a company’s business processes and information structures. We’ve heard you say it. “We’re from (name of your company), and our requirements are unique.” You customize application software packages in order 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 configuration. 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 proprietary intellectual property), and their user interface 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 editor, 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. A Customers.com® Research Service

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 implement 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 backoffice systems, as well as your data warehousing and analytic applications. By external business systems, we mean the CRM systems 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 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 representatives can answer customer questions about current order status or historical order details. In addition, it is becoming increasingly 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. Most significantly, CRM products should provide an integrated view of your customers, collecting customer information from its numerous and heterogeneous sources and providing consistent access across all applications. CRM suites can address this requirement more easily than point products that implement 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© 2005 Patricia Seybold Group

What’s Important in CRM Architecture? • 21

tomer data is a key requirement, it is your hard data integration and synchronization work that will address it. Integration Is a Critical but Complex Task Integration is one of the most difficult tasks that you’ll face in implementing CRM products. To address 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 specifications. Integration is becoming easier as more companies 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. Look for integration capabilities in CRM products that implement operational applications that simplify integration tasks through: •

A range of integration approaches— synchronous, realtime program-to-program integration, asynchronous, message-based integration.

•

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 implementation and adoption of Web services.)

© 2005 Patricia Seybold Group

•

Packaging of integration technologies and products that minimize development.

Selecting a CRM product from one of the leading suppliers can have significant advantages in integration. 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. 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 warehousing 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 operational applications and integration approaches, requirements, and issues are those discussed above. CONCLUSION Architecture should be a significant factor in your selection decision for CRM products, both operational products that implement customer-touching and customer-facing applications and analytic applications that help you understand your operations and improve their efficiency and effectiveness. Using the six criteria of our framework for evaluating the architecture of CRM products can optimize and shorten your selection process.

A Customers.com® Research Service

An Executive’s Guide to CRM

What Are Customer-Centric Analytic Applications? A Framework for Evaluation and Comparison By Mitchell I. Kramer, Sr. VP and Sr. Consultant, Patricia Seybold Group

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 understand your customers and improve the effectiveness of your customer experience to make your customer relationships stronger and more profitable. Selecting the customer-centric analytic applications 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 customercentric 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 approach to doing business, can be a better strategy for today’s tough times. Why? Customer-centricity ensures 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. Customer-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 improves 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 services that they need when they need them (and that results in more sales).

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

What Are Customer-Centric Analytic Applications? • 23

Customer-Centric Analytic Applications Are Tools to Help You Become More CustomerFocused 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 business processes and applications affect the Quality of the Customer Experience (QCESM) your company delivers to customers.

•

Improve and monitor the aspects of your backend processes and applications that may adversely 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 creating customer centricity.

© 2005 Patricia Seybold Group

Many Customer-Centric Analytic Applications, Many Claims So, now that we have your interest in customercentric analytic applications, here’s the catch. 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. Identifying which ones of the dozens really are customercentric analytic applications and, then, selecting the one that’s best for you can be a difficult, timeconsuming, and risky process. We’d like to give you some help. As we’ve done for so many other types of strategic 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 frameworkbased 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 products. Our continuing research and analysis of technologies and products, our work with the suppliers of these technologies and products, and, most significantly, our work with companies that can and have benefited by the implementation of customercentric 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 analytic 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—

A Customers.com® Research Service

24 • An Executive’s Guide to CRM

Customer-Centric Intelligence

Business Intelligence/Decision Support

Customer-Centric Intelligence

Customer-Centric Analytic Apps

Financial Intelligence

Reporting

Operational Intelligence

Data Warehousing

© 2005 Patricia Seybold Group Inc.

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 operations 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 interested in customer-centric analytic applications, also commonly called CRM analytics or analytical CRM (see Illustration 1). Customer-centric analytic applications are tools that help make you more customerfocused. Their usage can help you understand the performance, efficiency, and effectiveness of your operational CRM applications and of the other operational 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 systems 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.

A Customers.com® Research 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. Reporting is a very important analytical tool, and, in fact, reports are commonly the output of analytic applications, 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 systems and in the decision-making that improves their efficiency and effectiveness Processing also improves the breadth, depth, scope, and scale of analysis.

© 2005 Patricia Seybold Group

What Are Customer-Centric Analytic Applications? • 25

The Operational/Analysis Cycle

Operations

Analytic Applications ETL

Closed Loop

Initial • Configuration • Attribute values • Processing parameters

Refined from analytical applications processing • Configuration • Attribute values • Processing parameters © 2005 Patricia Seybold Group Inc.

Illustration 2. This illustration shows the operational/analysis processing cycle. While we’re on the topic of processing, let’s discuss OLAP. OLAP is a very useful analysis technique. It’s the interactive, visual navigation of hierarchies of de-normalized information—drill and pivot, slice and dice. Many feel that OLAP is an analytic 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 determined by program logic. But we’re not too uncomfortable calling OLAP a form of analytic application, 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.

© 2005 Patricia Seybold Group

The Operations/Analysis Cycle Customer-centric analytic applications are customer-centric intelligence applications they analyze the results of the operational CRM applications that you use to do business with your customers. Customer-centric intelligence applications work in a two-phased, closed-loop cycle with operational applications. The two phases are operations and analysis. 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, processing characteristics, data sources, data access characteristics, and types of users. Their purposes and

A Customers.com® Research Service

26 • An Executive’s Guide to CRM

processing are most significantly different. For example, 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 processing 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 applications or through contact center dialogs the concept 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 requests made within an interactive dialog, the responses 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 recommendations within ecommerce applications. Based on what you have previously purchased, based on your customer profile, based on what others similar to your profile have purchased, or based on similar purchases, an ecommerce system automatically and in real time recommends cross-sells to you while you’re shopping or at the time of purchase. In practice, real-time analysis can have significant disadvantages. Some analyses involve the exe-

A Customers.com® Research Service

cution of sophisticated algorithms that consume significant CPU resources. Other analyses involve the execution of complex queries requiring significant database processing and the retrieval of large volumes 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 customer 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 responsiveness, then go for it. If not, execute them offline, and use their results in real time. Another disadvantage of real-time analysis, especially real-time analysis that results in the supposed improvement of operational systems, is that it may also change your marketing, sales, and service programs and campaigns in real time. Take care not to change programs and campaigns before you’ve had a chance to measure and understand their effectiveness. Make sure that they run long enough so that you know whether they’ve succeeded or failed before you change them. Bottom line—take care in using real-time analysis. 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 operational system than it is to integrate two operational 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.

© 2005 Patricia Seybold Group

What Are Customer-Centric Analytic Applications? • 27

A FRAMEWORK FOR EVALUATING CUSTOMER-CENTRIC ANALYTIC APPLICATIONS A Hierarchy of Dimensions and Evaluation Criteria We have identified four dimensions for evaluating customer-centric analytic applications. By dimensions, we mean broad evaluation areas that serve to organize specific evaluation criteria. The evaluation framework is a hierarchy of dimensions and evaluation criteria within each dimension. The framework hierarchy is shown visually in Illustration 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 evaluation dimension. How well a product provides the capabilities that you need should be your primary selection factor. Also, many customer-centric analytic applications products will offer functionality beyond your requirements. This functionality makes products more attractive. While running your business 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 functionality dimension: • • • •

Analysis Prediction Business performance measurement Business performance monitoring

© 2005 Patricia Seybold Group

•

Output

Analysis Analysis is the most important evaluation criterion with functionality. After all, analytic applications do analysis. At a minimum, analysis capabilities should include: •

Segmentation and profiling

•

Analysis of proactive customer behavior in marketing, 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 implementations and too many analysis types that can address your requirements. As a result, look for products 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 output. 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 operational processing and the output of historical analysis to control key aspects of future operational proc-

A Customers.com® Research Service

28 • An Executive’s Guide to CRM

Patricia Seybold Group Evaluation Framework for Customer-Centric Analytic Applications Analytic Applications

Architecture

Product Marketing

Company Viability

Analysis

Environments

Product Background

Customers

Prediction

Organization

Installed Base

Finances

Business Performance Measurement

Infrastructure

Product Plans

Business Performance Monitoring

Structure

Price

Functionality

Output

Product Viability

Competition

© 2005 Patricia Seybold Group Inc.

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-

A Customers.com® Research Service

portant as analysis and not as commonly found in analytic application products. Prediction is implemented by several types of algorithms. Evaluating which type is best for a particular customer-oriented purpose is beyond the

© 2005 Patricia Seybold Group

What Are Customer-Centric Analytic Applications? • 29

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.

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

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 touchpoints, 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 specification of metrics, the automated recording and updating 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 specification of company-specific custom metrics. The products should track values for packaged and custom metrics and should include the mechanisms to present metrics in automatically generated and distributed reports or emails. Business Performance Monitoring Business performance measurement is good, but business performance monitoring is better. Monitoring adds automated decision making to measurement. Rather than simply tracking the values of metrics, monitoring compares those values to configurable threshold values and, if the threshold values are crossed, a business event is triggered. The business event may generate notifications that invoke programs or send notifications. Further, the notification processing may be qualified by the execution of business rules. Performance monitoring is a nice bonus in analytic applications. Most don’t offer this functionality. Minimally, look for capabilities that build on

© 2005 Patricia Seybold Group

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

Reports Dashboards Notifications

Notifications are the output of business performance monitoring functionality. They should include emails, telephone pages, changes to dashboard displays, 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 measurement functionality. They are typically continuous, 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 produced 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 marketing, sales, and service organizations will want to understand their contributions to your customer experience. 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

A Customers.com® Research Service

30 • An Executive’s Guide to CRM

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

might not generate the insight that your business needs.

ACCESS CONTROL. While many users of many types will be interested in the output of customercentric 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, protecting sensitive information. Access control capabilities should include user authentication, role-based authorization, and privilege-based access to individual reports. Access to the customer-centric analytic applications, themselves, could be included in this approach, although most of these users should not be able to execute the applications.

ARCHITECTURE

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 currency 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-tohave capability for customer-centric analytic applications, although it might be a mandatory requirement 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 application itself.

Architecture defines how products perform analytic 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 architecture evaluation criteria: •

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 organization or a three-tiered Web organization.

•

INFRASTRUCTURE. Infrastructure is the set of

services that supports the deployment and execution of a customer-centric analytic application. For example, an analytic application might deploy 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.

•

INTEGRATION. Integration examines how a

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 applications 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

A Customers.com® Research Service

ENVIRONMENTS. Environments are the Web

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

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 application product—it’s important that a customer-

© 2005 Patricia Seybold Group

What Are Customer-Centric Analytic Applications? • 31

centric analytic application fit into your existing analysis environment. For example, you won’t be too willing to implement a new data warehouse database just to run a customer-centric analytic application. For organization—the product’s major components and the interfaces between them—again, a match with your existing environment is important. If you’ve standardized on thin-client Web applications, you won’t find a client/server analytic application product very attractive. Customer-centric analytic 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 integration might require customization, and customization gets into structure. Ideally, the customer-centric analytic application supplier has packaged this integration 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 analytic 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 touchpoints, all operational applications, and all customers. Data is also the only component for which structure really matters. Structure is what’s inside a component. 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 focused 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 information), cleansed to eliminate duplicate and inconsistent data, and loaded into a data warehouse. In other

© 2005 Patricia Seybold Group

words, a data warehouse provides the input to customer-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 implement 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 customer-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 comprehensive. 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 functionality 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 contribute 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-

A Customers.com® Research Service

32 • An Executive’s Guide to CRM

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 products are in their initial versions. As with any strategic 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 vendor’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 expensive. 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 complexity if you won’t use it. Beware of indirect charges such as add-on products for extraction, loading, and transformation (ETL), data warehousing, or reporting. They can cost as much, if not more, than the analytic application products themselves.

COMPANY VIABILITY A company’s viability can be assessed by examining 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 company that offers a product is so small or so unstable as to introduce a business risk when buying its products, but, in today’s economic climate, even large, successful companies have had problems. Decisionmakers must weigh functional and architectural advantages of products from newer and smaller companies versus the risk of doing business with companies 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 applications.

•

Ecommerce server suppliers, such as Blue Martini 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 recommendations to online shoppers.

•

Point solutions providers, such as Business Objects, Teradata, and Unica. (Teradata and Unica also offer campaign management capabilities.) For example, Teradata CRM packages six analytic applications, and the Teradata Warehouse Miner complements this offering with generalpurpose data mining algorithms and tools.

Product Viability Product viability is our assessment of the overall risk in implementing customer-centric analytic application product. In making this assessment, we take into consideration such factors as installed base, product version, track record for performance, scalability, 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 major advantages and disadvantages.

A Customers.com® Research Service

© 2005 Patricia Seybold Group

What Are Customer-Centric Analytic Applications? • 33

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

© 2005 Patricia Seybold Group

improve the customer experience that you provide. And, with better experiences, come higher satisfaction, greater loyalty, and more profitability. There are many customer-centric analytic application products from which to choose. The framework 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 selection.

A Customers.com® Research Service

An Executive’s Guide to CRM

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 Management (CRM) strategies and systems, once thought to be the silver bullet that would catapult companies to higher profits, are now coming 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 businesses. Customers don’t just want to be marketed to, they want to be well-served. Our companies are notoriously ill-prepared to meet the challenges posed by today’s increasingly demanding business and consumer customers. What do we need to do beyond installing CRM systems to help us better understand our customers and to better market products to customers, 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 designed from the inside out as product-centric and functional fiefdoms. This drives our customers 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 marketing 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 customers 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 customer’s point of view.) Your customers can’t get consistent information across your Web site, your contact centers, your retailers, and your channel

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

What Comes After CRM? • 35

partners. They can’t easily locate the products they Usually, they’re strongly backed by the CEO, need. They have to make several attempts to resolve aligned with their company’s IT visionary and with problems and to get questions answered. Your busithe global marketing executive, and have a strong ness, like any business, is designed inside out. It’s business P&L sponsor—usually in an organization designed for you to develop, build, and sell stuff. It’s that is already organized around a major customer not designed to help customers buy stuff from you. segment. The problem is as simple as that. And as hard. Occasionally, as at Delta airlines, the major So what SHOULD you be doing? Where transformational trigger comes out of the need to SHOULD you be investing your scarce resources? streamline operations. (Delta began the revamping How do you transform your business from a collecof its internal systems in order to gain a better realtion of product line silos and functional fiefdoms to time view of its fuel needs. Then the company was a streamlined, efficient customer-driven pipeline— able to use its business events-based “digital nervous one where customers’ needs and requests appear at system” to proactively improve customers’ experione end, and product development, delivery, and ences when the inevitable travel disruptions ocservice take place in a transparent and dynamic curred1. Value Web? The good news is that there IS a proven way to Learn the Survival Skills from Customertransform your company to be Centric Organizations lean, clean, and customerIf you look at the evolution centric. And you can do it one The people who are leading of the customer-driven transforstep at a time. This transformathe customer-transformation mations that have rippled tion starts with the Web and with of their companies tend to be through the today’s most sucyour other customer-facing incessful companies, you’ll see the same people who have teraction touchpoints. Then it ripples through your entire orspearheaded their companies’ some interesting similarities. Here are some of the patterns ganization, your partner chain, ebusiness initiatives. that I’ve noticed. and your supply chain—in fact, your entire Value Web. (At some • Focus on a Key Customer point in the past five years, supSegment. At Wells Fargo, Dudley Nigg, who ply chains became supply Webs; the same thing led that company’s transformation, was initially happened to demand chains. Instead of a series of responsible for the bank’s high net worth cusone-to-one causal relationships, we now realize that tomers. At American Airlines, John Samuel foeach customer request or need fans out through an cused on frequent business travelers. At Boeing, entire Web of organizations, each of which may parBill Barker began his odyssey with customers ticipate in providing the solution.) who purchased replacement parts. At General Motors, Chet Huber at OnStar and Paul Comfrey Clearing the Way at Vauxhall both targeted customers who valued But, in order for this customer-centric transforconvenience. At Fidelity, Steve Elterich focused mation to take place, you need to remove barriers, first on his retail customers. At Hewlett-Packard, solicit high-level support, and seize tactical opportuLeslye Louie focused on consumers who are nities. Once customer information and requirements multi-touchpoint shoppers (research on the begin to drive your business in real-time, the path Web/purchase in the store; shop in the store; buy forward becomes clearer and clearer and more and online; get pre-sales and post-sales help on the more compelling. phone and on the Web). Phil Gibson at National 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.

© 2005 Patricia Seybold Group

1

See John Mann’s “Customers Experience Your Internal Operations,” July 19, 2001, http://dx.doi.org/10.1571/cs7-19-01cc.

A Customers.com® Research Service

36 • An Executive’s Guide to CRM

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

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 Infrastructures and Organizations. Wells Fargo built its Web customer self-service infrastructure on top of the application integration infrastructure it had already designed for the customer service reps (CSRs). These CSRs needed to access operational applications across business units and product lines on the customers’ behalf. Once CSRs could access the information customers’ needed, Wells Fargo enabled customers to help themselves to the same information.

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• Deliver Customer Portals ven’t shipped yet.” For FiFirst; Then Turn Them delity, it was, “let me roll Today’s leading companies into Employee Portals. At over my IRA easily” and are redesigning themselves Boeing, Bill Barker is using “show me my combined refrom the outside in. the same infrastructure and tail holdings and those in my architecture he developed to company-sponsored Fidelity give Boeing’s customers acretirement account.” For HP, cess to 100 of Boeing’s core operational applicait was, “let me download a printer driver for my tions. Now, he’s enabling Boeing’s own emnew printer,” and “how do I order supplies?” ployees to see the same information to which and “it’s not working, how do I get this fixed?” customers already have access, along with addiFor Dell, it was, “help me manage the computers tional “employee-only” information. I’ve bought from you” and “send me 2,000 computers with the following software configura• Give Customers a Seamless Experience with tions to these 18 offices in 10 different countries Your Channel Partners. Cisco Systems has over the next 6 months and let me time the done a great job of integrating channel partners shipments and re-allocate deliveries.” For Naand customers. Cisco bucked the conventional tional Semiconductor, it was, “let me design and wisdom that tells us that channel partners need simulate my new designs online, now show me a to “own” the customer and “add value.” Cisco bill of materials with your parts and your comredesigned its systems from the customers’ point petitors’ parts, and let me order that bill of mateof view. Customers configure their systems dirials from a distributor that has them in invenrectly on Cisco’s Web site. They then get pricing tory with prices I can afford.” With Delta, it was and delivery commitments from their preferred “re-route me and my luggage so that I’ll arrive at dealer (without leaving Cisco’s site). Cisco conmy destination as close as possible to my origifigures the system and ships it to the dealer prenal plan.” 2 configured to the customer’s specs. The cusNotice that all of these customer scenarios tomer has visibility into the entire process. The aren’t Web-only scenarios. They link directly Dealer installs and integrates the systems at the into the company’s (or in some cases, their customer’s premises. Deliveries are fast. Conchannel partners’) operational systems: invenfigurations are accurate. Everyone wins. On the tory, pricing, order entry. And, in many cases, consumer side of the equation, watch HP and Best Buy. This manufacturer and retailer combi2 Customer ScenarioSM Design is a Service Mark of nation are tightly integrating their supply chains

the Patricia Seybold Group.

A Customers.com® Research Service

© 2005 Patricia Seybold Group

What Comes After CRM? • 37

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

Let Customers Drive Cross-Product Line Integration. At Fidelity, there had been a Chinese Wall between the giant retail division and the institutional division. One sold to and serviced individuals and their households; the other supported corporate HR and benefits’ buyers. However, often, the end-customer is the same. A person who had a Fidelity 401K plan through his company was also likely to have a retail account with Fidelity. In fact, employees have been demanding better self-service and tighter integration. 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 picture 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 already 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.

© 2005 Patricia Seybold Group

•

Measure and Reward Based On What Matters 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-todeliver for each customer segment, each interaction 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 quality of the customer experience and its link to customer profitability.

Let Customer-Driven Business Processes Re-Focus Your Organization You can see that customer-driven business processes 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 redesigning 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.

A Customers.com® Research Service

An Executive’s Guide to CRM

Multi-Channel CRM A Framework for Evaluating Multi-Channel CRM Solutions By Mitchell I. Kramer, Sr. VP and Sr. Consultant, Patricia Seybold Group

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

NETTING IT OUT We define multi-channel CRM as 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 well as direct 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 implementation will need significant customization and integration. To simplify the selection of products that can contribute to your multi-channel CRM implementation, 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’

•

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

•

To minimize customization and integration, select a channel/application combination that can be addressed by packaged software, 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 implementations. 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 customerfacing, 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

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

Multi-Channel CRM • 39

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

Web

Dedicated Retail Store Call Center Sto re

E-Mail

Partners

Multi-Supplier Retailers/B-Tailers E-Markets

Catalog

Efficient Use of My Time Integrity

RFQ/ RFP

Ease of Doing Business

Ease of Interactions

Value

Reliable Fulfillment, Delivery, and Support

Ease of Decision-Making

Trust Customer Relationship Customer’s Self-Concept

Innovation

Differentiation

Brand Personality

Core Driving Idea

Brand Identity © 2005 Patricia Seybold Group Inc.

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 decisionmaking, 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 deliver 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

© 2005 Patricia Seybold Group

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 example, if you’ve long been selling your products through a direct sales force to an established customer base, then we’re sure you can think of a few customer executives who want to deal only with the

A Customers.com® Research Service

40 • An Executive’s Guide to CRM

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 preferences 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 supports 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 addition, it has not always been technologically feasible to offer multi-channel CRM. Each CRM channel has characteristic implementation costs and ongoing costs-to-serve for your business. You should consider a channel mix that optimizes customer profitability, customer satisfaction, 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 selfservice through online channels has the lowest ongoing costs-to-serve, but might have a very high implementation cost, especially if you’re new to online channels and your value-add is in personalized service. More likely, you’ve already implemented multiple channels, but you don’t yet provide marketing, sales, and service across all of them. If implementation 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 service 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 example, neither PeopleSoft nor Siebel offer viable online selling (ecommerce) capabilities. Most contact 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 channel, e.g., the cash register or kiosk. If you’ve implemented a sell-side ecommerce system, then you’ve got self-service sales well covered, 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 nonsales service. All this is to say that multi-channel CRM is only partially a buy. Its implementation will require considerable 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 customer relationships. REQUIREMENTS FOR MULTI-CHANNEL CRM Capturing the Benefits In order to capture the profitability, cost, and loyalty 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

A Customers.com® Research Service

© 2005 Patricia Seybold Group

Multi-Channel CRM • 41

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

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

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 applications that analyze the results of operational application processing. Analysis results in improvements and refinements to operational functionality that improve the customer experience and improve customer relationships and profitability. Operational and analytic functionality work together continuously in a closed loop. Operational Functionality There are three evaluation criteria in the operational functionality of multi-channel CRM: • • •

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

MULTI-CHANNEL FUNCTIONALITY. Multichannel CRM doesn’t change the functional requirements 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

© 2005 Patricia Seybold Group

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

CHANNEL-DEPENDENT FUNCTIONALITY. You

will not deliver the same CRM functionality through every channel. Rather, functionality should be tailored to the channel. Continuing our campaign management example, while campaigns should be deliverable through every channel, their offers should be tailored to and consistent with the business characteristics 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 functionality. You can’t deliver identical experiences and provide identical functionality through every channel. For example, in the product support area of customer service, self-service product support can’t encapsulate the expertise and adaptability of your best contact 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 selfservice system and should add tools and access information dependent for contact center tech reps. Your dealers’ product support systems should include at least the functionality the customer would encounter if he dealt with you directly, plus what-

A Customers.com® Research Service

42 • An Executive’s Guide to CRM

ever additional services your dealer provides. Your field service systems (these are mobile CRM systems) 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 includes customer, product, and order related functionality. 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 relationship 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 multichannel CRM are straightforward. Analytic applications should provide the capabilities to analyze customer behavior and customer transactions across all channels and on each, individual channel. In other words, they must provide a view of the entire customer 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—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 accessing 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 capabilities for individual customers to localize all their interactions with you. For example, ecommerce systems 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 organized, how they’re built, and how they’re accessed. For application logic, structure is modularity, component 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, component granularity should not be so fine as to have so many components that you can’t easily associate any one of them with a particular CRM function nor so coarse that the application becomes monolithic.

•

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

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.

A Customers.com® Research Service

© 2005 Patricia Seybold Group

Multi-Channel CRM • 43

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 accessible through the Web services protocols: XML and SOAP.

For data, especially customer data, structure is the data model, an application’s logical representation of the information that it processes. Data models for CRM, ERP, and supply chain applications represent the business entities involved in the processing that they perform. Most significantly, the data models 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 distribution partners, and the behavior that they manifest in marketing, sales, and service interactions. •

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 address 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-

© 2005 Patricia Seybold Group

channel CRM will require additional modifications. Not only will you implement your unique, companyspecific functionality, you’ll also implement channel-dependent functionality. For example, an “open an incident” component of a service application will perform customer lookup and customer authorization 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 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 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 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 representatives can answer customer questions about current order status or historical order details. In addition, it is becoming increasingly 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 purchaseorder 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 starting 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 functionality 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 between products and between products and your custom-built applications.

A Customers.com® Research Service

44 • An Executive’s Guide to CRM

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 application’s components into services. A service may comprise a single component or multiple components. Individual services typically implement higher-level and broader functionality than individual components. For example, a cross-sell service might combine a customer-value-lookup component, an order-lookup-component, and a cross–sellrecommender component. Service-oriented architecture facilitates integration 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 interfaces facilitate integration and interoperability, independently 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, messaging interfaces and communication protocols such as IBM MQSeries or J2EE JMS would serve well, too.

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 multichannel 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 onechannel- and one-application-at-a-time approach. We’d also suggest starting with the channel/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 application functionality to address most requirements. But don’t let that stop you. You might start by selecting 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

CONCLUSION AND RECOMMENDATION Use Customer Scenarios® Our Customer Scenario® Mapping technique provides an ideal approach for understanding your customers’ multi-channel CRM requirements. Remember 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 prefer to use for which tasks. Customer scenarios will

A Customers.com® Research Service

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 implementations. In addition, we’ve planned workshops for you that use Customer Scenario® Mapping to understand that your requirements and the services that can implement them. Watch our Web site for the schedule.

© 2005 Patricia Seybold Group

An Executive’s Guide to CRM

Framework for Evaluating Cross-Channel, Cross-Lifecycle Customer Service Products How to Evaluate Solutions That Support a Great End-to-End Customer Experience By Mitchell I. Kramer, Sr. VP and Sr. Consultant, Patricia Seybold Group

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 relationships with you. Think of that help as customer service—cross-channel, cross-lifecycle customer service. Channels link your customers to customer service personnel and to customer service systems. There are two types of channels: partner networks and customer touchpoints. Touchpoints 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 evaluate products that offer cross-channel, crosslifecycle 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 criteria 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 service. We viewed the topic first from a personal perspective and then from the perspective of our consulting experience.1 From a combination of the two perspectives, there are two critical lessons to remember: •

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 interaction and iteration within the lifecycle phases of plan, explore, select, buy, use, maintain, and renew.

Remember also that customer service encompasses all of your customers’ cross-channel, crosslifecycle 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, September 2, 2004, http://dx.doi.org/10.1571/PSGP9-204CC.

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

46 • An Executive’s Guide to CRM

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 applications. Before we get into the details of the framework, let’s build a common understanding of what we mean by channels and by the customer lifecycle. CROSS-CHANNEL CUSTOMER SERVICE What Are Channels? Your customers do business with you through mechanisms that we call channels. Channels link your customers to customer service personnel and to customer service systems. There are two types of channels: partner networks and customer touchpoints. Partner networks are the multitiered structures of distributors and resellers that market, sell, and support the products produced by manufacturers and suppliers. Customer touchpoints are your technologies and your personnel with which your customers interact with you. Businesses have many customer touchpoints. Their technology touchpoints include the Web, email, kiosks, and contact centers. Their personnel 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 CONTROL. Remember that

customers are in control. Customers choose their channels. Even if you’ve built a partner-based business model, customers pick the partners with whom they want to do business. And given that you’ve implemented 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 customer service.

A Customers.com® Research Service

Self-Service and Assisted Service Touchpoints support either self-service or assisted-service interactions. Self-service interactions occur when customers interact with your customer service systems. Self-service touchpoints are automated. They may have high implementation costs but very low costs to serve. The Web is a key selfservice touchpoint. It can support the broadest range of types of interactions and just about every activity of every phase of your customers’ lifecycle. Interactive voice response (IVR) systems are another selfservice touchpoint. Assisted-service interactions occur when customers interact with your customer service personnel, who, in turn, interact with your customer service systems for your customers. Assisted-service touchpoints are manual. Contact centers, stores, and personnel 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 demand cross-channel customer service, you will deliver 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 Scenario®, 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-

© 2005 Patricia Seybold Group

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

Cross-Lifecycle Customer Service

PLAN

EXPLORE

SUPPORT REPLACE

SELECT

My Account Information

MAINTAIN

BUY

USE

© 2005 Patricia Seybold Group Inc.

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: • • • • • •

Plan Explore Select Buy Use Maintain

•

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.

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

© 2005 Patricia Seybold Group

A Customers.com® Research Service

48 • An Executive’s Guide to CRM

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 effectiveness

•

Learn about the availability of patches, fixes, and upgrades

• • • • • •

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

Maintain

© 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 common 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. Customers 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 influence your customers’ behavior. For example, once a customer purchases and deploys one of your products, 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

A Customers.com® Research Service

their lifecycles. If you want to build long-term, profitable 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 customer experience that delivers excellent crosschannel, cross-lifecycle customer service by helping you select software products that best address your channels and the phases and activities of your customers’ lifecycles. Through our work with you, our work understanding software solutions, and our ongoing customer-centric analyses, we’ve identified the requirements for cross-channel, cross-lifecycle cus-

© 2005 Patricia Seybold Group

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

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

Operational Functionality

Analytic Functionality

Architecture

Product Viability

Company Viability

Channel Support

Instrumentation

Organization

Product Background

Company Background

Lifecycle Support

Real-Time Analysis

Environments

Installed Base

Product Lines

Reports

Infrastructure

Target Market(s)

Customer Base

Analytics

Structure

Pricing

Financials

Customization

Product Plans

Integration

Competition © 2005 Patricia Seybold Group Inc.

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 evaluation frameworks, this one delivers the following significant benefits: •

It shortens your time to market.

•

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

© 2005 Patricia Seybold Group

•

It reduces your risks in product evaluation, comparison, and selection.

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

A Customers.com® Research Service

50 • An Executive’s Guide to CRM

Evaluation Framework for Cross-Channel, Cross-Lifecycle Customer Service The framework for cross-channel, cross-lifecycle customer service has five top-level evaluation criteria 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 support

•

Architecture

•

Product viability

•

Company viability

CROSS-CHANNEL, CROSS-LIFECYCLE OPERATIONAL SUPPORT In our evaluation of channel and lifecycle support, we’ll describe and analyze the operational ca-

pabilities that a product packages for each key activity of every lifecycle phase and on which channels it delivers those capabilities. For example, an ecommerce 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 customer 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.

A Customers.com® Research Service

© 2005 Patricia Seybold Group

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

Cross-Channel and Cross-Lifecycle Operational Capabilities

CROSS-CHANNEL, CROSS-LIFECYCLE ANALYTIC SUPPORT

Completing Table B for a product is the first of two steps in evaluating a cross-channel, crosslifecycle customer service product’s operational capabilities. 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 lifecycle 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 product’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 product 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 evaluation 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 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 experience. You use the results of this analysis to refine operational processing, thereby improving the customer experience that you deliver. Every crosschannel, 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, customer hold time. When its value exceeds a threshold, you should consider any of several remedies including 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.

© 2005 Patricia Seybold Group

A Customers.com® Research Service

52 • An Executive’s Guide to CRM

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, crosslifecycle 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 business. So you have to customize its look and feel, its application logic, and its data. Second, no crosschannel, 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 experience. 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 performance information. For example, an online product configurator should be instrumented 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 warehouse 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 incidents 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 information in easily understood formats.

Analytics

Sometimes reports aren’t enough, and analytic processing is required in order to understand cross-channel, cross-lifecycle performance. For example, you might use data mining analytics to identify the factors that most influence customers to renew your subscription-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.

A Customers.com® Research Service

© 2005 Patricia Seybold Group

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

We describe these further in Table E.

Architecture Factor Organization and Environments

Description 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 Webbased architectures. Web-based organization is preferred for most applications. It provides 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, crosslifecycle customer service product. A deployment environment provides runtime services like request handling, process and thread management, memory management, and security. 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 example, 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 approach 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 order 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 packaged 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.

© 2005 Patricia Seybold Group

A Customers.com® Research Service

54 • An Executive’s Guide to CRM

Architecture (continued) Factor Customization

Description 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 information. 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, products 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, crosslifecycle 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 support, or architecture, but the factors that contribute to product viability can be real deal breakers. For ex-

A Customers.com® Research Service

ample, a product may be targeted for industry segments other than the ones in which you do business. A product may be brand new with no reference customers in companies similar to yours. Or the product’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.

© 2005 Patricia Seybold Group

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

Product Viability Factor Product Background

Description 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 indicate problems. Your organization could be kept very busy doing installations and then reimplementing 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 acquisitions. 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 innovative, 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 segment. 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 supplier’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. Understanding 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.

© 2005 Patricia Seybold Group

A Customers.com® Research Service

56 • An Executive’s Guide to CRM

vice

COMPANY VIABILITY You want to purchase a viable product from a viable company. A viable company is a going concern with increasing revenue, profits, numbers of customers, 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 examine than product viability because it’s more subjective and it’s more difficult to obtain source information. 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 virtually impossible to assess financial health. We’ve identified four factors for examining company viability. They are:

•

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

•

Company background and status

•

Contact center products

•

Products and product lines outside customer ser-

•

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 company—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 viability.

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

A Customers.com® Research Service

© 2005 Patricia Seybold Group

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

•

•

“Customer service” products (products that offer problem diagnosis, problem resolution, and incident/case management capabilities) Customer analytics products

© 2005 Patricia Seybold Group

•

Partner relationship management products

The result of our evaluations will let you understand which channels and which lifecycle phases and activities product types and particular implementations of those types support.

A Customers.com® Research Service

An Executive’s Guide to CRM

Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix A Blank Matrix to Facilitate Your Evaluation Process for Customer Support Offerings By Mitchell I. Kramer, Sr. VP and Sr. Consultant, Patricia Seybold Group

FACILITATING YOUR EVALUATION PROCESS Evaluation Framework In our “Framework for Evaluating CrossChannel, Cross-Lifecycle Customer Service Products,”1 we presented the criteria that we believe are important when evaluating how well any given offering will support an organization’s needs. In the framework, we emphasize repeatedly that each organization is different, with different skills and requirements, 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 “crosslifecycle” in “cross-channel, cross-lifecycle customer 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 lifecycle. 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 long1

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 experience that delivers excellent service at every phase and for every activity of the customer lifecycle. Of course, no single product or product suite can address every phase and every channel of the customer service experience. You’ll be selecting, purchasing, and implementing multiple products to deliver 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 supporting 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

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

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

actually package hard-coded customer service functionality in the manner, say, of an ecommerce system that has packaged product exploration functionality; 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 customize in order to implement the products and address 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 product offerings use for their content, metadata, search, navigation, and process management capabilities. (See Table A.)

© 2005 Patricia Seybold Group

Our Evaluation Framework in Matrix Format To assist you in your evaluation efforts of products designed specifically to support your customers’ 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 evaluation 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 priority in your environment. We hope you find this matrix useful for prioritizing capabilities as well as for collecting and organizing information about cross-channel, cross-lifecycle customer service alternatives.

A Customers.com® Research Service

60 • An Executive’s Guide to CRM

Knowledge Management Framework Evaluation Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

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 customer support activities?

External Content

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

Product:

Product:

Product:

What types of external content are supported? Metadata Taxonomy

Does the offering have a taxonomy independent of its content? If so, then what is the organization and structure 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 capabilities?

A Customers.com® Research Service

© 2005 Patricia Seybold Group

Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix • 61 Knowledge Management Framework Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Process Management

Does the offering package customertouching process management capabilities? If so, then how do those capabilities help implement your customers’ Customer Scenarios®?

Samples

Does the offering package samples or examples of taxonomies, content components, processes, or Web pages?

Product:

Product:

Product:

© 2005 Patricia Seybold Group Inc.

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

Product:

Product:

Product:

Plan Phase Determine technical and budget requirements for new or additional products or services. Learn about products that address requirements.

© 2005 Patricia Seybold Group

A Customers.com® Research Service

62 • An Executive’s Guide to CRM

Cross-Lifecycle Operational Capabilities Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

Plan Phase (continued) Determine whether currently installed products address those requirements. Determine what additional product types and products address those requirements. Be aware of new products or product upgrades that address new or additional requirements. Understand best practices in the use of products that address requirements. Explore Phase Find products that address requirements. Compare products that address requirements by features, functions, and price.

A Customers.com® Research Service

© 2005 Patricia Seybold Group

Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix • 63 Cross-Lifecycle Operational Capabilities Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

Explore Phase (continued) Be aware of merchandising offers on the products or product alternatives that address requirements. Select Phase Select products that address requirements. Request and receive quotes (RFQ process) for products that address requirements and request and receive proposals (RFP process) for products that address requirements. Negotiate prices, terms, and conditions for RFQ and RFP responses. Be aware of ordering incentives on selected products.

© 2005 Patricia Seybold Group

A Customers.com® Research Service

64 • An Executive’s Guide to CRM

Cross-Lifecycle Operational Capabilities Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

Select Phase (continued) Configure products that address requirements. Buy and Renew/Replace Phases Order selected products 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 purchased products in production.

A Customers.com® Research Service

© 2005 Patricia Seybold Group

Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix • 65 Cross-Lifecycle Operational Capabilities Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

Use Phase (continued) Diagnose (installation, functionality, performance, availability, integrity, security, etc.) problems with deployed products. Report problems with deployed products. Be aware of the availability of fixes that apply to products that are deployed. Fix problems with deployed products. Maintain Phase View and modify customer information, including identification information, account information, contact information, security information, role information, and preference information.

© 2005 Patricia Seybold Group

A Customers.com® Research Service

66 • An Executive’s Guide to CRM

Cross-Lifecycle Operational Capabilities Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

Maintain Phase View order status, order details, and order history. Modify orders. Initiate returns. View incident status, incident details, and incident history. © 2005 Patricia Seybold Group Inc.

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 Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

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 crosschannel, cross-lifecycle customer experience 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?

A Customers.com® Research Service

Product:

Product:

Product:

© 2005 Patricia Seybold Group

Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix • 67 Analysis Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Reports

What are the packaged reports for gaining insight into the customer experience that you deliver with the offering? What tools are included 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.)

Product:

Product:

Product:

© 2005 Patricia Seybold Group Inc.

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 Evaluation Criterion Organization and Environments

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

Organization describes high-level aspects of a product’s architecture—for example, twotier client/server, three-tier client/server, or three-tier Web-based architectures. Environments specify the details of an offering’s organizational components. For example, the environments of a three-tier Web organization include the clients, server platforms, and databases it supports.

© 2005 Patricia Seybold Group

A Customers.com® Research Service

68 • An Executive’s Guide to CRM

Architecture Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

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) specifications? Does the offering package a templatebased approach to build the product’s UI?

Application Logic

Is the offering’s application logic segmented into sets of modular, coarsely granular stateless business (logic) objects/components and stateful business (data) objects/components? Does each business object/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 flexible to represent your customers and products?

Customer Data

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

A Customers.com® Research Service

Product:

Product:

Product:

© 2005 Patricia Seybold Group

Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix • 69 Architecture Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product Data

Does the packaged product data model represent all aspects of your products? If not, can it be easily customized?

Content

What content management capabilities are packaged with the offering? Are they sufficient to enable you to create and maintain the content that customers and agents navigate and search to perform customer service/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 architecture (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 facilities?

© 2005 Patricia Seybold Group

Product:

Product:

Product:

A Customers.com® Research Service

70 • An Executive’s Guide to CRM

Architecture Evaluation (continued) Evaluation Criterion Integration

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

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 integration? What level of technical skills are needed to use integration facilities and packaged integrations? © 2005 Patricia Seybold Group Inc.

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

Product Viability Evaluation Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

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 offering in house, or is development outsourced?

Key Acquisitions

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

A Customers.com® Research Service

© 2005 Patricia Seybold Group

Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix • 71 Product Viability Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

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 vendor target for marketing and selling the offering? 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 installation price? How much consulting service (as a percentage of price) is typically required 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? © 2005 Patricia Seybold Group Inc.

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

© 2005 Patricia Seybold Group

A Customers.com® Research Service

72 • An Executive’s Guide to CRM

Company Viability Evaluation Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

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

A Customers.com® Research Service

© 2005 Patricia Seybold Group

Cross-Channel, Cross-Lifecycle Customer Service Product Evaluation Matrix • 73 Company Viability Evaluation (continued) Evaluation Criterion

Cross-Channel, Cross-Lifecycle Offering Capabilities

Product:

Product:

Product:

Financials (continued) Current Assets for the Four Most Recent Quarters © 2005 Patricia Seybold Group Inc.

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

© 2005 Patricia Seybold Group

A Customers.com® Research Service