Abstract This paper explores the evolution of customer interaction management systems and their possible place in the support of customer relationships.

BACKGROUND

Since early 1999 there has been an explosion in the number of technology vendors touting ‘customer interaction management systems’. In many cases it is campaign management or call centre or web personalisation technology under another name. But there are a few who have taken a novel look at a growing business problem, coping with real time interactions across a wide range of customers points. For most organisations the idea that there should be consistent and/or relevant treatment of clients (customer and prospects) across the organisation’s touchpoints seems logical, but for most marketing managers it is just a dream. Yet again, technology is ahead of most organisations’ ability to deliver the other pillars of success, the people, process and technology changes. In some cases the technology being promoted is ‘slide ware’ with little real substance — buyer beware.

This paper explores some of the approaches being taken by the technology vendors to solve this growing business problem.

INTRODUCTION

In the last five years the introduction of high-end campaign management applications with scheduling functionality provided marketing teams with the ability significantly to increase the volume of communications (tenfold is not uncommon) while maintaining and in some cases reducing the size of the marketing team. Adding to this armoury the tighter integration of the novel real-time communication methods such as e-mail and short text messaging, (many with significantly reduced unit costs per communication) has resulted in a situation where the same marketing team could potentially deliver 100 times more communications. The issue now is that many of the other marketing processes cannot cope with the increasing power of the core marketing communication engine. Wider automation of the marketing function and the evolution of customer interaction management systems is therefore inevitable.

In an earlier paper the requirements for a marketing automation solution were examined,1 this paper identified the key components and the functions to be supported by such a solution. The functions to be supported are:

managing client information
managing communication decisioning: maintaining communication reference data; determining client communication eligibility; determining client communication priority; determining client communication delivery mechanism;determining client communication cell involvement
managing communication execution: maintaining communication delivery reference data; transferring required data to communication delivery system; executing communication; maintaining contact history; automating and optimising communication execution
managing communication channels
monitoring communication performance
managing communication content
managing the marketing process: task management; workflow
managing model development and deployment.

This paper expands on the requirements to manage communication channels.

The last few years have seen an explosion in the communication methods available to the average marketing manager. With this has come a requirement to manage the resources utilisation better in these communication channels and to improve the integration between them. A comprehensive marketing automation solution should support these utilisation and integration requirements.

The primary focus of the integration is to ensure a consistent treatment of a client regardless of the organisation touch point.

Consistent treatment does not mean that the same data are available at all points of contact. Providing credit reference data to a teller operator in a bank may be valid but the bank may not want to make these data available to a client as part of a personalised view on a website. The key is to disseminate the corporate understanding of the client resulting from the analysis of the data in the client repository to the rest of the organisation in a form relevant to the recipient.

The technologies that have supported this component of the marketing automation solution have tended to be independent of the communication decision process, but there has been a move to tighter integration of these systems to make more effective use of the channels. A whole class of technology solutions is being developed to meet this business requirement generically called customer interaction systems.

The following section explores the requirements for a customer interaction management system (CIMS).

OVERVIEW

The customer interaction management system (CIMS) plays a central role in the execution of client dialogue. It receives information from the organisation’s touchpoints, processes these through policies or business rules that determine how to respond, and sends appropriate content back to the touchpoint for delivery to the client. The CIMS should support the following key processes:

obtaining data from the touchpoint
processing data through a communication decision engine
communicating the outcome to the touchpoint system
maintaining a record of communication
monitoring communication effectiveness.

Meeting these requirements raises a number of technology issues as follows.

INTEGRATING CIMS WITH THE TOUCHPOINT

Most organisations have a large number of possible customer touchpoints. The CIMS would therefore have to interface all the possible touchpoint systems.

Where this is the case, the CIMS would be able consistently to manage the customer dialogue across the whole enterprise. This is the core objective of this type of system.

Before a customer interaction can be managed the touchpoint system has to collect and pass the necessary data to the CIMS.

The following technical solutions have been proposed.

Modify touchpoint solution to collect and transfer the required data

In this case the touchpoint system is modified so that it generates a message that is consistent with the application program interface (API) built into the CIMS.

This approach provides the implementer with the greatest flexibility, since it means the CIMS can work with any touchpoint system that can generate an appropriate transaction. It also means, however, that a significant amount of work is required by the customer organisation to add each new touchpoint system to the overall solution.

CIMS manages the communication with the touchpoint

In this case the CIMS provides an application that itself manages communications with the touchpoint. This approach moves the development effort to the CIMS vendor but does facilitate integration with any of the common touchpoint technologies.

For example, one could provide HTML snippets that can be embedded in a Web page; these call the customer interaction management system when the page is requested, transfer information such as the customer ID and context, and display as part of the Web page whatever message the CIMS determines is appropriate. These applications are called ‘adapters’ or ‘connectors’.

Middleware technology translates data between the touchpoint system and the CIMS APIs

In this case a middleware application would be used to translate data between the different system APIs, without building a point-to-point connection between each touchpoint and the CIMS. These technologies do exist, although this strategy has not been adapted by any of the main interaction management vendors. This generic approach may not be attractive to the vendors who want to own this key part of the process. It does, however, allow the customer organisation to deliver a flexible architecture that allows each of the components to be changed with ease.

Monitor data in non-touchpoint system

Some CIMSs avoid any touchpoint integration at all by scanning for significant transactions outside the context of a particular touchpoint process.

For example, a system might scan a stream of bank deposits, regardless of which touchpoint hosted them, and select those over $10,000 for closer examination. This could be done by reading inputs to the deposit system, which might actually be linked to a number of different touchpoint systems.

In many cases some degree of transaction filtering is deployed into the touchpoint integration mechanism, so the CIMS is only called when a decision is truly required. This could be accomplished by building screening rules into either the touchpoint logic that calls the CIMS’s API, or the CIMS application embedded in the touchpoint.

TYPE OF DATA PROCESSED BY CIMS

The type of data passed from the customer touchpoint will vary depending on the nature of the customer interaction. As a minimum the following types of data are implicated:

client reference data, eg client ID (unique customer or prospect reference)
channel reference data, eg channel ID (unique reference for the touchpoint)
interaction transaction

In many cases the touchpoint system will collect significant amounts of data on the interaction including contextual information such as the path the client took to get to the present location, and specific information such as replies to questions.

If integration is achieved using a CIMS API, then the design of the API will determine how many data can be captured. Systems that integrate via connectors built for specific touchpoints are governed by whatever types of data the connector has been designed to process. The maximum data available is usually determined by the touchpoint system’s API, but fewer data may be transferred if the connector accepts only a subset of what the API presents.

A business rules engine is used in the CIMS to determine what the most appropriate response is to the current dialogue request. In its simplest form this could be a lookup of the client ID in a list of eligible campaigns or communications. This campaign list could be held in the CIMS (most likely) or locally in the touchpoint sytem. The latter results in control issues when campaign involvement is changed in the CIMS.

The touchpoint system must continue to operate even if the CIMS fails to respond. Such a failure could occur for any number of reasons. If the CIMS is functional it should first test other content or campaigns to see if they are available; if not, it should deliver a default content or campaign.

DATA CREATED AS PART OF THE CUSTOMER INTERACTION

The CIMS accepts information from the touchpoint and generates additional information about its own activities, such as movement of a client through a campaign sequence or which messages a client has been sent. Persistent storage is important in campaigns that walk a client through a sequence of messages or that use changes in a customer’s behaviour or status to trigger interactions.

This has implications for:

the types of data stored
user control over data
storage format
accessibility
data transfer to other

all in real time. Accessing these data sources represents a significant technical problem. This is further compounded by the potential need to execute complex decisioning processes including channel optimisation.

OVERVIEW OF CIMS VENDORS

The following is a sample list of vendors claiming to have technology that supports customer interaction management:

Allink Agent
Black Pearl
Data Distilleries
Epiphany
Intrinsic
Manna
MarketSwitch
NetPerceptions
Prime Response
Quadstone
Recognition systems
Revenio
Verbind
Xchange
Yellow Brick

Even though each vendor/product offers a different combination of functions, the systems appear to fall into two clusters. Products in the first group (Yellow Brick, Verbind, Revenio) offer complex, multi-step marketing campaigns that are delivered through one or more touchpoints, but driven by the CIMS itself. The second group (Epiphany, Black Pearl, Manna, Data Distilleries, Intrinsic) delivers recommendations in response to touchpoint requests. In these, the touchpoint itself is the main driver. Note that all the products in this group provide integrated modelling, while none in the first group do.

The one product that falls into neither group, Allink Agent, is indeed an oddity, designed less for real-time interactions than to identify marketing opportunities and react through outbound messages.

Products in the recommendation group may find themselves competing less with the other CIMSs than with recommendation engines like NetPerceptions and modelling products like MarketSwitch and Quadstone. This assumes the modelling vendors deliver real-time scoring solutions that are easy to deploy.

Similarly, products in the multi-step campaign group may eventually find their primary competitors are conventional campaign managers and marketing automation systems, particularly as these re-engineer to integrate with multiple touchpoints in real time. However, the division between one-time and multi-step CIMSs itself may not last, if vendors in each group add the key capabilities provided by the other.

An analysis of the key vendors of customer interaction management technology clearly shows that there is:

no best practice approach: no two vendors have the same strength and weaknesses. This variation in approach reflects the newness of this technology category and the lack of an accepted best practice approach in the industry
no comprehensive solution: no single vendor has addressed all the key business requirements. This reflects the fact that few vendors have given this area a high priority. It is also technically a complex problem, particularly when it comes to handling real-time decision making. The scope of the current solutions tends to reflect the background of the vendor company or the design team
mainly small specialist vendors: most of the products in the market are provided by small (early adopter) organisations, with many being less than two years old. The fragmentation of the market among multiple vendors suggests that any significant market expansion will be accompanied by consolidation, or more likely, acquisition of vendors by larger CRM firms
immature market: no vendors appear to have more than a dozen sites up and running. This would indicate that the market is still immature and in the early adopter stage.

CONCLUSION

The desire by organisations to manage client interaction across all touchpoints will drive technology vendors to develop systems to meet this business requirement. There are significant technical issues surrounding access to data from multiple sources in real time and the complex decision process and these problems will slow the evolution of these systems, but they can be solved. The bigger issue is that few organisations have the ability to deliver the other pillars of success, ie the people, process and technology changes.