Today’s enterprises are increasingly serious about coordinating customer interactions across all touchpoints. While some firms may be fortunate enough to execute all interactions through a single, multi-channel contact system, most will find themselves working with several independent touchpoint products. Company-wide coordination will therefore require using a separate interaction manager that receives information from all touchpoints and sends back decisions.

Connecting this central interaction manager to the individual touchpoints is a significant challenge. It typically requires modifying the touchpoint system to call the interaction manager when intervention by the interaction manager is or might be required. This intervention point might be display of a particular Web page, receipt of a certain type of email message, or a reaching specific branch in a telemarketing script.

Touchpoint integration is generally accomplished in either of two ways. One is to change the touchpoint system so it generates a transaction in the format specified by the interaction manager’s Application Program Interface (API). This provides the greatest flexibility to the implementer, since it means the interaction manager can work with any touchpoint system that can generate an appropriate transaction. However, it also means a significant amount of work is needed to add each new touchpoint system, and maybe even to add each new intervention point within a touchpoint.

The second approach is for the interaction management vendor to provide an application that itself manages communication with the touchpoint. For example, some vendors provide HTML snippets that can be embedded in a Web page: when the Web page is displayed, the snippet sends the interaction manager information such as the customer ID and context, receives a reply from the interaction manager with an appropriate response, and displays that response on the original Web page. Such applications are often referred to as “adapters” or “connectors”.

Taken to its extreme, this second approach can work without any direct communication between the touchpoint and the interaction manager. In the Web site example, this would happen if the customer ID were picked up from a cookie maintained by the interaction manager rather than the Web site itself. In fact, online advertising networks use this method to deliver targeted messages across multiple Web sites. Another version of this strategy is to have the interaction manager conduct an extensive dialogue before returning control to the touchpoint. Something like this happens in systems that run specialized interactions such as financial needs analysis.

But some communication with the touchpoint is usually needed for the interaction manager to tailor its response to the current circumstances. Most prebuilt connectors do in fact capture and transfer such information from the touchpoint. This generally involves conforming to the touchpoint system’s own API, and is thus the mirror image of the strategy of modifying to touchpoint to write to the interaction manager’s API. The advantage of prebuilt connectors is that they simplify touchpoint integration. The disadvantage is they are only available for whatever touchpoint systems the vendor has chosen to support. A generic connector such as an HTML snippet might support many touchpoint systems of the same general kind. But such connectors cannot capture much specific information, since they cannot read detailed information that each touchpoint product has stored in its own private format.

A third approach is to use middleware to translate between the different systems’ APIs, without building a point-to-point connection between each touchpoint and the interaction manager. This strategy has been adapted by a few interaction management vendors.

Some interaction managers avoid any touchpoint integration at all. Instead, they scan for significant transactions outside the context of a particular touchpoint process. For example, a system might read a stream of bank deposits 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. This approach simplifies implementation but is limited in the types of data it can capture and degree of context it can provide. More important, it cannot integrate its response with the current interaction. At best, it can generate a near-real-time response that goes out through a related channel–say, an email triggered by an action on a Web site. Whether a system without direct touchpoint integration could be considered a “true” interaction manager is debatable, but in fact the products that support transaction scanning can also allow direct touchpoint integration. So this is not a meaningful differentiator.

Actually, it makes sense to build transaction scanning into the touchpoint integration mechanism, so the interaction manager is only called when a decision is truly required. This reduces demand on the network and other resources. It can be accomplished by building screening rules into the touchpoint logic that calls the interaction manager’s API, or into the interaction manager application embedded in the touchpoint.

Other aspects to consider when evaluating a system’s touchpoint integration include:

• data captured from the touchpoint. At a minimum, the interaction manager must be given the identity of the current customer and of the touchpoint system making the call. But the touchpoint system itself usually has additional information available about the current situation. This includes contextual data such as the path the customer took to get to the present location and specific data such as replies to questions. If integration is achieved by writing to the interaction manager’s API, then the design of the API will determine how much data can be captured. Some APIs are limited to basic data, while others can accept additional elements that may vary from touchpoint to touchpoint or even from transaction to transaction. XML is extremely good at this sort of thing and is used by several vendors for such applications. 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 less data may be transferred if the connector accepts only a subset of what the API presents.
• ability to call specific campaigns. A marketing campaign can be considered a set of decision rules. Most companies will have several campaigns active at the same time, each with a different purpose or target segment. Nearly all interaction management systems are designed so information passed from a touchpoint is accompanied by a request for one or more specific marketing campaigns. This enables the marketer to control the type of decision that is returned–for example, a cross selling recommendation in the context of a sales transaction. The list of campaigns available at each intervention point is usually stored inside the touchpoint system at the intervention point itself. But this raises a control issue: if the campaign lists reside within a variety of touchpoint systems, it may be impossible to update them automatically when campaigns are added or retired. Alternate solutions include creating separate lists for each intervention point but storing them within the interaction manager, or having one set of rules that governs selection of campaigns at all intervention points. But these approaches raise other their own management issues, and neither has been widely adopted.
• ability to deliver default responses. The touchpoint system must continue to operate even if the interaction manager fails to respond to a request for a decision. Such a failure could have any number of reasons: insufficient or invalid data, failure of the current customer to qualify for any of the specified campaigns, an expired or non-existent campaign, corrupt or incompatible content, a crashed or overloaded interaction manager, a lost connection or downed server, and so on. The system should fail gracefully in such circumstances: if the interaction manager is functional it should first test other content or campaigns to see if they are available; if they are not, it should deliver a default content or campaign. If the interaction manager cannot respond, the touchpoint itself should deliver a default reply (presumably embedded in the intervention mechanism), or, as a final resort, continue processing with no reply at all. However the system handles failures it should also alert an administrator when touchpoints call for campaigns or content that are not available, so the problem can be addressed before it recurs.
• effort to build the integration mechanism. Whether touchpoint integration is managed through input from the touchpoint API, a call to the interaction manager API, or transaction scanning, some amount of setup is required to establish each connection. Systems vary significantly in the effort to do this and the tools they provide to help with the process. Some vendors simply provide samples of C code, SQL or Java scripts; some have applications that let users specify data sources, formats and processing logic; some provide wizards to generate an HTML snippet. Vendors also differ considerably in how much help they offer with updating integration mechanisms after they are built–a critical maintenance issue that is often overlooked. Such functions might accommodate changes in campaign lists, enhancements to an API, or even replacement of one system with another. Efficiently managing such changes is critical when a large number of different interaction points and marketing campaigns must be managed over time.

*                       *                        *  

Copyright 2001 Raab Associates, Inc.. Contact: info@raabassociates.com

Back to Search