I’ve had a couple of consulting projects recently that involve real-time decision systems (a.k.a. real time interaction managers), which are used to select the best treatment during a Web visit, telephone call, or other interaction. This type of software has been around for two decades or more and repeatedly proven its value, but still has relatively few implementations.
There are many possible reasons for the slow adoption. Maybe marketers don’t realize how much improvement they get from driving recommendation with predictive models rather than simple rules. Perhaps the decision capabilities built into delivery systems are already adequate. The delivery systems are controlled by Web and call center managers who are not incented to generate revenue and may not be interested in a shared decision engine to coordinate customer treatments. Maybe each of these plays a role.
Still, the interest among my own clients has been enough to spur a fresh look at the vendors in this field. To gather this information systematically, I need a framework that lists standard features and options within those features. This makes it easy to isolate critical differences among the products.
For real-time decision managers, the framework includes:
- connecting to external systems. This includes the touchpoints (customer-facing execution systems), such as Web sites and call centers, and other systems with relevant data, such as order processing and marketing databases. Connections to touchpoints are typically through Web Services calls; connections to other sources are usually made through API calls and SQL queries. The connections are set up during system implementation and then used in real time to look up information about a specific individual during an interaction. One important difference among real time decision systems is whether they look up information each time they are asked for a decision, or whether they look it up once at the start of an interaction and then retain it in a session until the interaction is complete. The session reducing workload and helps to run multi-step dialogues. Another difference is whether the system maintains its own permanent database of individual profiles and contact history or must query external systems for all data.
- making decisions based on rules and predictive models. Rules are always available; systems differ greatly in how hard they are to build and maintain. Predictive models are optional. They be built outside of the system, built within the system in periodic (batch) processes, or built and updated automatically. Systems also differ considerably in how they choose among competing treatments, a process called “arbitration”. The ranking may be as simple as picking the offer most likely to be accepted, or it may involve complex user-specified considerations such as offer value, sales targets, and business priorities. Some systems let users apply weights to multiple factors.
- integration with campaign and content systems. Early decision systems were not connected to outbound campaign managers or to content stores. But today they are often part of a larger marketing suite that includes an outbound campaign manager. The decision system may share campaign flows, offer definitions, customer data, analytics, and other features with the campaign manager. This simplifies training and facilitates integrated, cross-channel customer treatments. But even the unified systems typically run the outbound campaigns and real-time decisions on separate engines, each optimized for its particular type of processing. Regarding content: the decision systems traditionally returned a content ID that the execution system converted to actual content internally. When the decision manager is part of a marketing suite that includes a content repository, it can return the content itself.
- deployment model. Most real-time decision managers are deployed the old-fashioned way, as on-premise software. This gives clients the greatest control over security and performance. Some are cloud-based or vendor hosted (not precisely the same thing, but close enough), which simplifies deployment. Several vendors offer both options.
With that framework in mind, let’s take a look at another product in this group: SAS Real Time Decision Manager (RTDM).
RTDM meets all the framework requirements: it receives a Web Services request from an external system for a decision, runs the request through rules and models, and returns one or more choices. The results are usually displayed in a slot on a Web page or call center screen, although they could also be presented in an email, mobile device, or other channel.
RTDM leans toward the simpler end of most framework options. Each request loads fresh data from the touchpoint and other source systems, even within a multi-step interaction. At best, users can create continuity by storing a session token at the end of one interaction and retrieving it at the start of the next interaction. The systems returns tags, IDs or URLs but not actual content.
Decisions are based primarily on rules. These can incorporate predictive models, but the models themselves are built outside of the system, using SAS or other products, and do not self-adjust based on results. RTDM can return multiple selections but users must write code to rank these on anything other than a single variable. The system does let users define a group of treatments, called a “campaign set”, that share a single set of eligibility rules. Individual treatments can also have their own eligibility rules that are applied whenever the treatment is used.
RTDM is tightly integrated with SAS’s campaign management system, SAS Marketing Automation. It shares the same campaign flow interface, treatment library, and database of contacts and responses. Predictive models built with SAS tools are also available to both. Both use other SAS platform components including data structures, reporting tools, and other general functions. RTDM can be installed on-premise or hosted by SAS.
RTDM has been around in some form since 2008, although the tight integration with SAS Marketing Automation is more recent. The system has sold more than 50 licenses, although fewer than half have been deployed. SAS says most deployments have been single-channel, single-purpose projects. Deployment has come slower where RTDM is part of a larger multi-channel deployment involving other SAS marketing products. The other components must be put in place before the client is ready for RTDM.
Pricing of the system is based on the number of decisions processed or call center seats. Cost starts around $150,000.