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 multichannel contact system, most will find themselves working with several independent touchpoint products. Therefore, company-wide coordination will 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 the display of a particular Web page, receipt of a certain type of e-mail message or a specific branch in a telemarketing script.

Touchpoint integration is generally accomplished in one 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 programming interface (API). This provides the greatest flexibility to the implementer because it means the interaction manager can work with any touchpoint system able to 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 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 occur 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 dialog before returning control to the touchpoint. Something like this happens in systems that run specialized interactions such as financial needs analysis.

However, 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. Thus, it is the mirror image of the strategy of modifying the 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. However, such connectors cannot capture much specific information because 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 touchpoint integration. Instead, they scan for significant transactions outside the context of a particular touchpoint process. This approach simplifies implementation but is limited in the types of data it can capture and degree of context it can provide. More importantly, 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 such as an e-mail triggered by an action on a Web site. Whether a system without direct touchpoint integration could be considered a "true" interaction manager is debatable. However, 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 the touchpoint system making the call. However, 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 that 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. 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. However, these approaches raise other 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. Regard-less of how the system handles failures, it should 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. Efficient management of such changes is critical when a large number of different interaction points and marketing campaigns must be managed over time.

This material is excerpted from Interaction Management Software Industry Analysis, published by Raab Associates. For details on the study, contact Raab Associates at (914) 241-2117 or

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access