Balandra Orchestrates Customer Journey Without a CDP

Balandra Customer Flow Diagram

The need for a system that assembles unified, sharable customer profiles is now widely accepted. So is the label of “Customer Data Platform” to describe such systems. What people do still debate is whether a Customer Data Platform should only assemble those profiles or should also include features to “activate” them in the sense of selecting customer treatments. I personally find the discussion uninteresting since the plain reality is that some companies want activation features in their CDP and others do not.  Companies that don't want activation in their CDP may already have a separate activation system or prefer to purchase a separate one.  This means that activation is optional, and, thus, not a core CDP feature. QED.

Theory aside, it’s true that the majority of CDPs do include activation features.  This makes a stronger argument for the weaker claim that most buyers want activation features in their CDP.  But this has nothing to do with CDPs in particular: it’s just an instance of the general rule that buyers prefer integrated systems to separate components. This is known (to me, at least) as Raab's Law, stated most succinctly as "suites win".

A diehard advocate of “CDPs need activation” might question whether activation systems can truly be purchased separately. My response points to Journey Orchestration Engines (JOEs), a small but intriguing category that includes Thunderhead, Pointillist, and Kitewheel among others. These products select the best treatment for each customer in each situation and transmit their choice to delivery systems (email, Web CMS, mobile app, call center, etc.) for execution. All need customer profiles to function, but they don’t necessarily meet the RealCDP requirements for accepting data from all sources, retaining all details, storing the data internally, or sharing their profiles with others. This is because their designers’ focus is on the very different challenge of making it easy for users to define, manage, and optimize customer treatments across channels.

Meeting that challenge requires presenting customer data effectively, identifying events that might require an action, selecting the right action in the current situation, and sending that action to external systems for delivery. Some tasks, such as data presentation and delivery system integration, are also found in other types of systems. The unique challenge for Journey Orchestration Engines is finding the right action while taking into account the customer’s complete situation (not just the current interaction). This requires understanding all the factors that are relevant in the current situation and choosing the best among all possible actions.

Of course, "all" is an impossibly high standard.  A more realistic goal is to understand as many factors as possible and choose among the broadest range of available actions. It’s an important distinction because the scope of available data and actions will grow over time.  This means the key capability to look for is whether a system has the flexibility to accommodate new data and actions as these become available.

This brings us to Balandra, a Madrid-based journey orchestration engine.

Balandra is designed for complex service industries such as insurance, telecommunications, and healthcare, where companies have multiple, complex operational systems. Left to run independently, these systems will each send their own messages, creating a disconnected and often inappropriate experience for each customer. Balandra intercepts these messages and replaces them with a single stream is governed by a common set of rules.

The rules themselves draw on a structure that organizes customer experience into major processes such as onboarding a new client, setting up a new service, or filing an insurance claim. Each process is assigned a combination of data, lifecycle stages, available actions, and decision rules. When an event occurs that involves the process, Balandra executes its rules to pick an action based on the customer’s data and lifecycle stage.

This may not sound especially exciting. But it’s important to contrast Balandra’s approach with conventional customer journey flows.  These follow a specified sequence of messages and events, at best with some branching to accommodate different customer behaviors as the journey progresses. But a conventional journey flow can only include a fairly low number of steps and branches before it becomes incomprehensibly complex. The rule-based approach avoids this problem by letting users  create different rules for different factors and apply them in sequence. So, you might have one rule that checks for recent customer service issues, another that checks for customer value, and another for previous purchases. Each rule would add or exclude particular messages from consideration. After all the rules had executed, a final rule would select from the pool of messages that remain available.

The advantage of this approach is that each rule executes independently, avoiding the need for a complex decision tree that specifies different treatments for different combinations of conditions. Rules can just be added or dropped into the mix knowing that they’ll apply themselves only when relevant conditions are met. For example, a rule might check for recent customer service problems and suppress new product offers within the following two weeks if one occurred. This happens (or doesn’t happen) across all interactions without explicitly building that check into each journey flow.

To be clear, Balandra isn’t the only system to take this approach. In fact, its actual rule definition and execution is done using a standard business rules engine – IBM’s Operational Decision Manager (ODM), formerly ILOG. The system does have an interface that lets non-technical users define the data associated with each process and specify connections with delivery systems. It can ingest data in real time via APIs, through event streams such as Kafka, or through batch file updates. It can support both real time interactions and batch processing for outbound campaigns.

If you’re keeping score, Balandra doesn’t qualify as a CDP because it only uploads a fraction of the data related to a customer – the interactions between customer and company systems. While this means Balandra clients might still want a separate CDP system, it also enables Balandra to use many fewer resources than a CDP would.

Balandra launched its product in 2014. It currently has four clients in production, all in Spain, and is looking distribution partners in other regions. Pricing starts around $50,000 per year and grows based on the number of customers.

CrossEngage Orchestrates Customer Journeys Using Events

It feels like forever since I first wrote about Journey Orchestration Engines (JOEs), although it is just one year. Orchestration was already a hot term when I started, so I take neither credit nor blame for its continued popularity. I will say that I’ve now seen enough orchestration systems to start making subtle distinctions among them.

Subtle distinctions are needed because the systems are basically similar. They all ingest data from multiple sources; convert it into unified customer profiles; apply rules and analytics to find the best message for each customer in each situation; and, send those messages to external systems for delivery. Unified customer profiles make these products look like Customer Data Platforms. JOEs that expose their profiles for external access really are CDPs; JOEs that keep the profiles for their own use, are not. In theory, a JOE could connect to an external customer database rather than building its own, but I haven’t seen that configuration in practice.

The main ways that JOEs differ include:

• Channel scope. Some systems are largely limited to online interactions, while others are built to combine online and offline channels. Some systems that look like JOEs work with only Web or email. But orchestration pretty much implies multiple channels so I’d probably exclude those from the JOE tribe.

• Decision methods. JOEs can work with conventional, rule-driven campaign structures or use automated techniques to customize the path followed by each customer. There’s also considerable variation in exactly what gets automated: some automate campaign assignments but use static content; some automatically run a/b tests and pick the winners; some automatically create customer segments that receive different content; some use machine learning to dynamically generate custom content. 

• Journey framework. My original definition of JOE was quite rigorous: journey orchestration meant all campaigns were defined relative to a master model of the customer journey. This really means that stages in the journey are “states” that customers flow between, and campaigns are chosen in part based on each customer’s current state. I still think of JOEs that way and definitely see some systems organized along those lines. But when you start looking at some of the more automated decision methods, it’s harder to apply concepts of fixed states or journey flows. So I still check whether a system has a journey framework but don’t necessarily require a JOE to use it. I realize this means you could have a journey orchestration system without journeys. If that’s the silliest thing you’ve been asked to accept recently, you haven’t been watching the news.

This is all a very long-winded introduction to CrossEngage, a Berlin-based firm that released its product about six months ago. CrossEngage works in online channels, using its own tags to capture Web interactions and API connections to ingest data from email providers, mobile apps, and other sources. It can also load CSV files if necessary.

CrossEngage treats most data as either a customer attribute or event, using big data technologies that store inputs and to allow data access with minimal schema design. The system also stores some information that’s neither attribute nor event, such as products and locations. The vendor maps new sources into the system and can define logic to create custom events. (A self-service event builder is planned by July.) Customer data from different sources is stitched together using deterministic matching only (that is, CrossEngage will only connect different identifiers to the same person if an external source provides the relationship).

A dashboard lets users see Web site events as they stream into the system. Users can apply filters to see only certain events. Campaigns also make heavy use of events, referencing them as entry and exclusion conditions, in combination with user-defined segments; as campaign goals (which may be one or several events); and, as campaign steps (each step being a different event). Event definitions can reference other events and can include brain-bending logic such as checking whether a second train fare request specified the same departure city as the first request and happened within ten minutes. In that example, the first request would be first event in the campaign. This is tremendously powerful and, as the vendor points out with some understatement, poses a substantial technical challenge to do in real time.

Each event in a campaign can be assigned a message, which will be delivered by an external system such as an email vendor. CrossEngage can map its data to delivery systems so they can use the data in their own message templates. Alternatively, messages can be created in CrossEngage’s own templates, which can include conditional scripts for dynamic content generation. The system has external integrations for email, direct mail, mobile push, text messages, and Facebook Customer Audiences, with more on the way. It has its own connectors for Web site and Web browser messages, Web hooks, and file extracts. Users can also attach discount coupons to messages.

Campaigns can be assigned frequency caps that limit the number of messages each person receives in different time periods (per minute, per hour, per day, per week, or per month). Caps are defined separately for each campaign. Another set of caps applies across all campaigns on a per channel basis. Campaigns that generate transactional messages can be exempted from the frequency caps to ensure their messages are always sent. People can also be excluded from campaigns based on whether they were recently in that same campaign or a different one.

CrossEngage also has user journeys, which involve a set of related events. Journeys can exist within a campaign or be used outside a campaign to analyze customer behavior. If you’re keeping track, this is a different use of the term “journey” from the one I described earlier.

This is a pretty mature set of features, especially for such a young system. But nuances also include noticing what CrossEngage doesn’t do. There is no machine learning to recommend the right campaign, right message, or right message timing, although the system does support a/b tests. There’s also no visual flow chart to lay out campaigns. This is a choice made by CrossEngage based on its designers’ previous experience that flow charts quickly become too complicated to be understood or maintained over time.

Speaking of nuance, CrossEngage also has a mature approach to user rights management, allowing administrators to specify which users can perform which actions on each object. Team-based rights are on the roadmap.

CrossEngage currently has about fifteen major clients, spread across travel, ecommerce, fashion, dataing, and other industries. Pricing is based on the number of events tracked in the system, not the number of messages sent. It starts as low as $2,500 per month although average client pays about twice that. 

CaliberMind Offers B2B Orchestration with a Twist

I spent quite a bit of time debating with myself how to classify CaliberMind. But instead of presenting my conclusion and defending it, I’ll just tell you what CaliberMind does. We’ll circle back to classification at the end.

Unify B2B data. CaliberMind ingests data from Salesforce Sales cloud and Marketo, Oracle Eloqua, Salesforce Pardot, and HubSpot marketing automation systems. It reports on missing data and fills in the blanks using data from external vendors. It also uses those vendors to find identifiers belonging to the same person (such as multiple email addresses or alternative company names) and to link contact and lead records to accounts. The system can accept feeds from major advertising systems (GoogleAdwords, Bing, Facebook Ads), from Web analytics (Google Analytics, Mixpanel), and various data stores (MySQL, Amazon Redshift and S3, MongoDB, Apache Hive, etc.). CaliberMind has embedded a third-party data load and transformation tool to manage such inputs. The system stores structured data in Redshift, semi-structured data in MongoDB, and unstructured data in S3.

Report on journeys. CaliberMind system builds an account-level journey visualization that shows different types of events (outbound contacts, inbound contacts, account created, opportunity created, deal won, etc.) on parallel time lines. It imports opportunity stages or account statuses from the source systems rather than creating its own journey stages. Attribution reports show the timing of different types of contacts relative to the date of the final sale, aggregated across multiple accounts. The system doesn’t explicitly report the impact of different contacts but it does consider their effects when recommending which messages to send next.

Create personas. Users can define a list of personas and then assign them profile attributes such as job titles or company sizes. More interesting, they can also submit texts related to each persona. These might be job descriptions, advertising copy, blog posts, video transcripts, email messages, or anything else written in English. (Other languages will be added in the future.) The system uses natural language processing to analyze these and build a profile of what they have in common. This can later be used to determine how closely other texts match each persona. The system can also classify new contacts by persona, based on their profile attributes and associated texts such as content consumed or emails written. The assignments can be adjusted over time as new information becomes available.

Match content to individuals. CaliberMind also uses the texts associated with each contact to build a personal profile. Because the language processor can understand things like level of interest, buyer role, and stage in the purchasing process, it can identify new and generate alerts about important events. The system can also pick up references to other individuals and infer their own roles and interests.

Push results to other systems. CaliberMind draws on its individual-level profiles to push personality insights, engagement tips, and content recommendations to sales people. These can be loaded into the CRM database or displayed in a window on the CRM desktop. CRM users can also see the account-level journey reports and revenue summaries including forecasts. Marketing automation systems could get the same details but usually take more general information, such as persona codes used in segmentation. User-created rules can pick records meeting specified criteria and send them to different marketing automation campaigns. A Salesforce app is pending approval on the App Exchange and Salesforce single sign-on is scheduled for later this year.

Expose detailed data. CaliberMind’s own interface lets users examine the data loaded into the system. Individual-level reports can display details down to the level of single emails or Web visits. These reports are used by marketing, enablement and sales operations teams, not sales people.

These facts should give you an idea why classifying CaliberMind is such a challenge. Its two most notable features are data unification and the personas and recommendations based on natural language processing. The unification and access features make it a Customer Data Platform, while the personas and recommendations make it a Sales Enablement tool. That’s an unusual combination because the marketing and sales domains usually remain separate. You might label CaliberMind an Account Based Marketing system, which also straddles those domains. But there are so many types of ABM systems that it's not a useful classification. CaliberMind itself calls the system an orchestration engine.  That's also accurate, since CaliberMind does indeed coordinate messages across channels. But orchestration is another vague term that if understates the main value of CaliberMind, which is less about coordinating messages than finding the best ones. So must best suggestion is to leave categories aside and consider CaliberMind on its own merits.

CaliberMind was released last summer and currently has eleven clients including a mix of mid-size and enterprise B2B companies. Pricing is based on number of contacts and data sources and starts at $2,000 per month.

Pega Customer Decision Hub Offers High-End Customer Journey Orchestration

My previous posts about Journey Orchestration Engines (JOEs) have all pointed to new products. But some older systems qualify as well. In some ways they are even more interesting because they illustrate a mature version of the concept.

The Customer Decision Hub from Pega (formerly PegaSystems) is certainly mature: the product can trace its roots back well over a decade, to a pioneering company called KiQ Limited, which was purchased in 2004 by Chordiant, which Pega purchased in 2010. Obviously the system has been updated many times since then but its core approach to optimizing real-time decisions across all channels has stayed remarkably constant. Indeed, some features the product had a decade ago are still cutting edge today – my favorite is simulation of proposed decision rules to assess their impact before deployment.

Pega positions Customer Decision Hub as part of its core platform, which supports applications for marketing, sales automation, customer service, and operations. It competes with the usual enterprise suspects: Adobe, Oracle, Salesforce.com, IBM, and SAS. Even more than those vendors, Pega focuses on selling to large companies, describing its market as primarily the Fortune 3000. So if you’re not working at one of those firms, consider the rest of this article a template for what you might look for elsewhere.

The current incarnation of Customer Decision Hub ihas six components: Predictive Analytics Director to build offline predictive models, Adaptive Decision Manager to build self-learning real-time models, Decision Strategy Manager to set rules for making decisions, Event Strategy Manager to monitor for significant events, Next Best Action Advisor to deliver decisions to customer-facing systems, and Visual Business Director for planning, simulation, visualization, and over-all management. From a journey orchestration perspective, the most interesting of these are Decision Strategy Manager and Event Strategy Manager, because they’re the pieces that select customer treatments. The other components provide inputs (Predictive Analytics Director and Adaptive Decision Manager), support execution (Next Best Action Advisor), or give management control (Visual Business Director).

Decision Strategy Manager is where the serious decision management takes place. It brings together audiences, offers, and actions. Audiences can be built using segmentation rules or selected by predictive models. Offers can include multi-step flows with interactions over time and across channels. Actions can be anything, not just marketing messages, and may include doing nothing. They are selected using arbitration rules that specify the relevance of each action to an audience, rank the action based on eligibility and prioritization, and define where the action can be delivered.

The concept of “relevance” is what qualifies Decision Hub as a JOE. It measures the value of each action against the customer’s current needs and context,. This is the functional equivalent of defining journey stages or customer states, even though Pega doesn’t map how customers move from one state to another. The interface to set up the arbitration rules is where Decision Hub’s maturity is most obvious. For example, users can build predictive model scores into decision rules and can set up a/b tests within the arbitration to compare different approaches.

Event Strategy Manager lets users define events based on data patterns, such as three dropped phone calls within a week. These events can trigger specific actions or factor into a decision strategy arbitration. It’s another way of bringing context to bear and thus of ensuring each decision is appropriate to the customer’s current journey stage. Like arbitration rules in Decision Strategy Manager, the event definitions in Event Strategy Manager can be subtle and complex. The system is also powerful in being able to connect to nearly any type of data stream, including social, mobile, and Internet of Things devices as well as traditional structured data.

I won't go into details of other Decision Hub components, but they’re equally advanced. Companies with the scale to afford the system can expect it to pay for itself: in one published study, the three-year cost was $7.7 million but incremental revenue was $362 million. Pega says few deployments cost less than $250,000 and most are over $1 million. As I say, this isn’t a system for everyone. But it does set a benchmark for other options.

History of Marketing Technology and What's Special about Journey Orchestration

I delivered my presentation on the history of marketing technology last week at the Optimove CONNECT conference in Tel Aviv. Sadly, the audience didn’t seem to share my fascination with arcana (did you know that the Chinese invented paper in 100 CE? that Return on Investment analysis originated at DuPont in 1912?) So, chastened a bit, I’ll share with you a much-condensed version of my timeline, leaving out juicy details like brothel advertising at Pompeii.

The timeline* traces three categories: marketing channels; tools used by marketers to manage those channels; and data available to marketers.  The yellow areas represent the volume of technology available during each period. Again skipping over my beloved details, there are two main points:

• although the number of marketing channels increased dramatically during the industrial age (adding mass print, direct mail, radio, television, and telemarketing), there was almost no growth in marketing technology or data until computers were applied to list management in the 1970’s. The real explosions in martech and data happen after the Internet appears in the 1990’s.

• the core martech technology, campaign management, begins in the 1980’s: that is, it predates the Internet. In fact, campaign management was originally designed to manage direct mail lists (and – arcana alert! – itself mimicked practices developed for mechanical list technologies such as punch cards and metal address plates). Although marketers have long talked about being customer- rather than campaign-centric, it’s not until the current crop of Journey Orchestration Engines (JOEs) that we see a thorough replacement of campaign-based methods.

It’s not surprising the transition took so long. As I described in my earlier post on the adoption of electric power by factories (more arcana!), the shift to new technology happens in stages as individual components of a process are changed, which then opens a path to changing other components, until finally all the old components are gone and new components are deployed in a configuration optimized for the new capabilities. In the transition from campaign management to journey orchestration, marketers had to develop tools to track individuals over time, to personalize messages to those individuals, identify and optimize individual journeys, act on complete data in real time, and to incorporate masses of unstructured data. Each of those transitions involved a technology change: from lists to databases, from static messages to dynamic content, from segment-level descriptive analytics to individual-level predictions, from batch updates to real time processes, and from relational databases to “big data” stores.

It’s really difficult to retrofit old systems with new technologies, which is one reason vendors like Oracle and IBM keep buying new companies to supplement current products. It’s also why the newest systems tend to be the most advanced.** Thus, the Journey Orchestration Engines I’ve written about previously (Thunderhead ONE , Pointillist, Usermind, Hive9 ) all use NoSQL data stores, build detailed individual-level customer histories, and track individuals as they move from state to state within a journey flow.

During my Tel Aviv visit last week, I also checked in with Pontis (just purchased by Amdocs), who showed me their own new tool which does an exceptionally fine job at ingesting all kinds of data, building a unified customer history, and coordinating treatments across all channels, all in real time. In true JOE fashion, the system selects the best treatment in each situation rather than pushing customers down predefined campaign sequences. Pontis also promised their February release would use machine learning to pick optimal messages and channels during each treatment. Separately, Optimove itself announced its own “Optibot” automation scheme, which also finds the best treatments for individuals as they move from state to state. So you can add Optimove to your cup of JOEs (sorry) as well.

I’m reluctant to proclaim JOEs as the final stage in customer management evolution only because it’s too soon to know if more change is on the way. As Pontis and Optimove both illustrate, the next step may be using automation to select customer treatments and ultimately to generate the framework that organizes those treatments. When that happens, we will have erased the last vestiges of the list- and campaign-based approaches that date back to the mail order pioneers of the 19th century and to the ancient Sumerians (first customer list, c. 3,000 BCE) before that.




_________________________________________________________________________________
*Dates represent commercialization, not the first appearance of the underlying technology. For example, we all know that Gutenberg’s press with moveable type was introduced around 1450, but newspapers with advertising didn’t show up until after 1600.

** This isn’t quite as tautological as it sounds. In some industries, deep-pocketed old vendors with big research budgets are the technical leaders. 

ABM Vendor Guide: State-Based Flows to Orchestrate Account Treatments

Next up in this series on ABM sub-functions described in the Raab Guide to ABM Vendors: State-Based Flows.

ABM Process	System Function	Sub-Function	Number of Vendors
Identify Target Accounts	Assemble Data	External Data	28
	Select Targets	Target Scoring	15
Plan Interactions	Assemble Messages	Customized Messages	6
	Select Messages	State-Based Flows	10
Execute Interactions	Deliver Messages	Execution	19
Analyze Results	Reporting	Result Analysis	16

Your first reaction that may well be, What the heck is a State-Based Flow?  That's no accident.  I chose an unfamiliar term because I didn’t want people to assume it meant something it doesn’t. The Guide states:

Vendors in this category can automatically send different messages to the same contact in response to behaviors or data changes. Messages often relate to buying stages but may also reflect interests or job function. Messages may also be tied to a specific situation such as a flurry of Web site visits or a lack of contacts at a target account. Flows may also trigger actions other than messages, such as alerting a sales person. Actions are generally completed through a separate execution system. Movement may mean reaching different steps in a single campaign or entering a different campaign. Either approach can be effective. What really matters is that movement occurs automatically and that messages change as a result.

In other words, the essence of state-based flows is the system defines a set of conditions (i.e. states) that accounts or contacts can be in, tracks them as they move from one condition to the next, and sends different messages for each condition. This is roughly similar to campaign management except that campaign entry rules are usually defined independently, so customers don’t automatically flow from campaign to campaign in the way that they flow from state to state. (Another way to look at it: customers can be in several campaigns at once but only in one customer state at a time.) Customers in multi-step campaigns do move from one stage to the next, but they usually progress in only one direction, whereas people can move in and out of the same state multiple times. Journey orchestration engines manage a type of state-based flow, but they build the flow on a customer journey framework, which is an additional condition I’m not imposing here.

This may be more hair-splitting than necessary. My goal in defining this sub-function was mostly to distinguish systems where users manually assign people to messages (meaning that the messages won’t change unless the user reassigns them) from systems that automatically adjust the messages based on behaviors or new data. This adjustment is the very heart of managing relationships, or what I usually call the decision layer in my data / decision / delivery model.

Speaking of hair-splitting, you may notice that I’m being a little inconsistent in referring to message recipients as accounts, customers, contacts, individuals, or people. A true ABM system works at the account level but messages may be delivered to accounts (IP-based ad targeting), known individuals (email), or anonymous individuals (cookie- or device-based targeting, although sometimes these are associated with known individuals). Because of this, different systems work at different levels. The ideal is for message selection to consider both the state of the account and the state of the individual within the account.

As with the Customized Message category I described yesterday, vendors who qualify for State-Based Flows fall into two broad groups: those whose primary function is cross-channel message orchestration (Engagio, MRP, YesPath, ZenIQ, Mintigo*) and those that do flow management to support delivery of messages in a single channel (Evergage, GetSmartContent, Kwanzoo, Terminus, Triblio). Marketers who are looking for a primary tool to manage account relationships will be most interested in the first group.

Differentiators to consider with this group include:

• orchestrates activities at account level (doesn't treat each lead independently)
• assigns Web site visitors to segments during each visit using current data
• automated models to classify content, define segments, and select best content per segment
• automated models to assign contacts to personas and select best content per persona
• automated models to recommend best actions per account
• present sets of content in sequence or all at once
• continue same experience over time across different channels
• prioritization to ensure highest value message is always presented
• accounts can be in multiple programs simultaneously
• contacts can be limited to one program at a time
• limit number of messages sent to each contact within a specified time period

As you no doubt realize, this is the area that most directly overlaps with marketing automation and journey orchestration systems that are not ABM specialists.  They key feature to watch out for when evaluating those systems for ABM programs is the abillity to work at the account level.  That was not part of many older marketing automation systems, although several vendors have now retrofitted their products to support to some degree.
______________________________________________________________________
* via its Predictive Campaign integration with Eloqua

Strikedeck Adds Automation to Customer Success Management

I first started paying attention to “customer success management” systems when I realized they were assembling data from multiple sources to build a consolidated customer view – something that could potentially serve other departments throughout the organization. This made them a fifth subtype of Customer Data Platforms (CDPs), along with systems based on marketing, lead scoring, sales advisory, and tag management. In practice, this classification is more potential than real because few if any customer success systems actually expose their data to other systems in true CDP fashion. On the other hand, several do use rules and/or predictive analytics to help manage the post-purchase portion of the customer relationship – making them possible Journey Orchestration Engines (JOEs). Again, though, they fall short on other parts of the definition, in this case the one related to journey mapping.  If you're wondering why I'm going through this, my point is that customer success systems share functions with other kinds of customer management systems and should be evaluated in that larger context.

This brings us to Strikedeck, which emerged from stealth in April after about a year of development. Strikedeck is aiming squarely at the same market as customer success leaders Gainsight and Totango but includes more automated execution of recommended actions. In fact, the execution is fully automated: users define rules, called “recipes”, that listen for triggers such as support issues, new contracts, or late invoices and specify the action to take when the trigger occurs. Actions can include emails, surveys, and updating customer data or assigning a task in an external systems.  Actions can also initiate a "playbook", which is a sequence of recipes (some serious mixed metaphors there, alas).  This allows for standard treatments to be fully automated.


Users can see the tasks they’ve been assigned in a list or on a calendar, as well as looking at account details and an overview of key metrics for all accounts. They can also define account segments to select accounts for playbooks or reporting. The system includes features to create and send emails, surveys, and in-app mobile messages.

If this sounds like “marketing automation for customer success managers”, that’s not a bad way to think about it. In fact, Strikedeck referred to itself as “customer success automation” in an early discussion I had with them, although they don’t seem to be using that positioning at present.

But Strikedeck goes beyond standard marketing automation in a couple of key ways. Most notably, it takes data from many sources: not just CRM and its own tracking codes, but also customer support, marketing automation, analytics tools, and any other system with a suitable API connector. It also stores this data in what it called a “polyglot” data model of several technologies (Solr, Redis, Mongo, and Cassandra, fronted by Kafka data collection) that allows vastly more flexibility than a conventional marketing automation product. And it embeds Spark machine learning to build churn and upsell predictions, soon to be extended to other predictions such as willingness to give references or participate in case studies. On the other hand, the playbook sequences lack the event-based branching available in most marketing automation nurture flows. Strikedeck says it takes one to two weeks to deploy at most firms, compared with months for a typical customer success management system.

Strikedeck pricing is based primarily on the number of accounts, with some adjustments based on deal size. Pricing starts at $30,000 per year for 500 accounts. The company had 18 clients when we spoke in late May.

Usermind Makes Journey Orchestration Simple

Maybe you’ve been waiting with increasing impatience for me to finish reviewing the set of Journey Orchestration Engines (JOEs) I first mentioned in March.  More likely, it slipped your mind entirely. But I do worry about such things so I’m especially pleased for finish out the set by telling you about Usermind.

Usermind Journey

I'm not saying that Usermind calls itself a JOE.  Its self-description is “the first unified platform for orchestrating business operations”.  But the company uses the language of journeys and customer data stores. So although they see themselves as enabling all kinds of business processes, I think it’s fair to view them largely in the context of customer management.

Usermind is all about simplicity.  Its main screen sets the tone by offering just three tabs: Analytics, Journeys, and Integration. Deploying the system actually starts with the last of these, Integration, which is where the user connects to external systems that are both data sources and execution engines. The company lists about a dozen standard integrations including major marketing automation, CRM, email, customer service, collaboration, and analytics systems. Another half-dozen are “coming soon.”

A key feature of Usermind is it makes integration easy by reading the contents of the source systems automatically, so any custom data elements or objects are incorporated without user effort.  This also means it adjusts to changes in those systems automatically. Users do build maps that show which fields to use to link customers (or other entities) across systems: for example, a map might use email address to link marketing automation to CRM, and customer ID to link CRM to customer service. The system can also map on combinations of fields and do fuzzy matching on inconsistent data. There can be separate maps for individuals, companies, products, customers, partners, or whatever other entities the user wants to work with. Usermind figures out relationships among tables or objects within each source system, so users simply see a list of available fields without having worry about the underlying data structures.

Once the maps are in place, Usermind copies selected data elements into its own database, where they are available to use in journeys. Each journey is a sequence of milestones, which can each contain one or more rules. Each rule has selection conditions and one or more actions to take if the conditions are met. Actions can push data or tasks to back to the source systems.  Rules can be triggered by events or executed on schedule.

Usermind Rule

And that’s pretty much it. The Analytics tab reports on movement of customers through journeys, providing counts, conversion rates and drop-out rates for each milestone. It also analyzes the impact of actions on results.  The system can be connected to business intelligence tools for more advanced reporting. But there’s no predictive analytics, content creation, or message execution. True to its description, Usermind is designed to orchestrate actions in other systems, not take actions itself.

Don’t let that simplicity fool you. Usermind (and other JOEs) address the critical challenge of unifying customer data from different sources and coordinating customer treatments. Tools to make this easy are rare; tools to send emails and deliver other messages are not. So Usermind fills an important gap – which is why the company has attracted $22 million in venture funding since it was founded in 2013, and why its investors waited until this year for it to launch the actual product. (Whether they waited patiently is a question I didn’t ask.) As of March, the company reported 15 live customers and was actively looking for more.

You may be wondering whether Usermind can truly be called a JOE since I've defined the essence of JOE-ness as a system that discovers the customer journey for itself rather than relying on the user to define it. Usermind doesn’t pass that test. In fact, Usermind journeys are individual processes rather than an overview of the customer’s lifetime experience. But Usermind still looks JOE-ish because it’s capturing events that occur naturally, not creating its own events like messages in a nurture flow. And its ability to use the journey as a framework for managing customer treatments is exactly what JOEs are all about. So marketers looking for a JOE should put Usermind on their list.

Pointillist Journey Orchestration Discovers Customer Paths for Itself (Marketing Automation is Doomed, I Tell You)

This post will resume the tour I started in March of journey orchestration engines – our new friend JOE. But first I’ll interrupt myself to announce that I have officially decided to predict that JOEs will replace campaign management and marketing automation as the core system for marketing departments. I usually hedge my bets with this sort of prediction, but will abandon my typical caution because I’m convinced that campaign management and marketing automation are too deeply rooted in the old world of batch list generation to meet today’s need for continuous optimization of customer treatments. Their core architectures just aren’t up to it.

I’m not saying that JOEs will have no competition.  Plenty of other vendors have the potential to make the transition – in particular, products developed for real time interactions and Web personalization. I am saying the competition won’t come from today’s campaign management and marketing automation leaders.*

Now that I’ve shared this exciting bit of news with you, let’s get back to the topic at hand. That would be Pointillist, a just-released “customer intelligence platform” that has been incubating inside financial services technology vendor Altisource since 2014.

As Pointillist’s self-chosen label suggests, its own roots are in customer data analytics, not execution. Sure enough, the system is built around a custom data structure that (if my notes are accurate) they describe as a “combination graph relational time series”, which certainly sounds like something out of Dr. Who.

Put in terms simple enough for me to understand, Pointillist stores all data as events, which can have  attributes including customers, products and campaigns. Different event types contain different sets of attributes but there are no formal data tables or relationships among tables. This sounds broadly like Hadoop and other NoSQL data stores, although I’m sure there are Important Technical Differences that matter deeply to people care about such things. What matters from a marketer’s perspective is this approach makes it easy to add new types of information and to update information very quickly.

Also as with Hadoop and friends, the Pointillist data store needs some added structure to allow fast access and analysis, and that structure imposes some limitations. Pointillist has optimized for customer analysis, meaning that customer behaviors can be analyzed almost instantly but combining information about customers is harder. For example, it could be tough to find out which products two customers bought in common. All data is stored persistently on a disk somewhere in the Amazon cloud, but accessible data is loaded into memory.  This makes things really quick.

That’s probably more than you care or need to know about Pointillist’s technology. Let’s get back to the surface where things are bright and shiny. What makes Pointillist a journey orchestration engine is that it can describe and act against customer journeys. The acting part is especially important, because it makes Pointillist more than simply an analysis tool.

What Pointillist really does from a user point of view is let you pick sets of customers and events to analyze. Users drag the events onto a workspace and connect them with lines to indicate the sequence to analyze. The system then scans its data to find how many customers had an instance of each event and draws lines whose thickness indicates how many passed customers from one event to the next. In other words, it creates a journey map.

Or, and this is my favorite part, you can tell Pointillist to discover the most important paths on its own.  It does this using magic machine learning to determine which paths have the highest combination of frequency, exclusivity, and correlation to a goal (a user-specified event). Users can adjust the balance among those three factors and can further train the algorithm by telling it which connections they feel are important. Because Pointillist is doing the analysis in memory and considerately visualizes its results, you can  watch it test different connections until it settles on a final set. Hours of fun, for sure.

But there’s more. Pointillist can report on the disposition of people within each event, replacing its icon with a little circle graph showing how many people reached the final goal, moved to the next event (but never reached the goal), dropped out, or stayed behind. It can also display other statistics in graphs next to the flow diagram, as well as letting users analyze subsets of the audience or even a trace the path of a single individual. The analysis can run backwards or forwards, finding either where an initial set of customers ended up or where a final set of customers came from. Heck, that’s weeks of fun when you think about it.

Taking action within Pointillist works exactly as you’d think: for any event on the chart, the system can generate a list of customers that it will send to an external system. The list could include all people in the event or a subset with specified behaviors. When I spoke with Pointillist a few weeks ago, the list would be a file export, but API connections were close to being ready. They’ll probably be done by the time you read this.

Also under development when we spoke was an automated cluster builder that would find clusters most related to (or distant from) the target event. This is different, and often more useful, than traditional clusters that find groups that are similar or distant from each other. Pointillist was also working on letting users create calculated variables, such as a lifetime value or engagement score, that would be available for analysis or segmentation. And on automated tools to help load unstructured data and clean dirty data. And on connectors to push data out to other systems. And on fuzzy matching to supplement the existing, and quite powerful, tools to unify customer data from different sources. Because nobody ever had too much fun.

Speaking of data loading, Pointillist has its own Javascript tag to capture Web behaviors, uses third party connectors to import data from many common systems, and can import batch files from nearly any source. Mapping new event types requires some basic technical skills but Pointillist is working to make it simpler. While APIs to push data to other systems are under development, APIs that let external systems pull data from Pointillist are already available.  These can access customer data but not other data types (remember those special data structures?)

In short, Pointillist both builds a robust, unified customer database and presents exceptional tools to analyze and act on the customer journey. It is the very model of a modern journey orchestrator.

_______________________________________________________________________________
*Nor, to be perfectly clear, am I saying that campaign management and marketing automation systems will go away. They will simply retreat to the execution layer where they will deliver emails and other outbound messages, playing an important role alongside other channel delivery systems like Web sites and call centers. But the fundamental decisions about which messages to send will be made by the orchestration engines.

Thunderhead ONE Provides Powerful Journey Orchestration

As I wrote a couple of posts back, I’ve recently noticed a new set of vendors offering “journey optimization engines”*. The key feature of these systems is they select customer treatments based on movement through a journey map. The treatments are usually executed through external systems such as email service providers, CRM, or Web content management. The systems also assemble the unified customer database needed to track customer journeys. This, of course, is a function they share with Customer Data Platforms. But CDPs don’t necessarily have journey mapping or treatment selection functions. On the other hand, journey optimization engines don’t always expose their data to external systems, which is a core requirement for CDPs. Journey optimization engines also provide at least some tools to analyze customer journeys and choose the best customer treatments. These may include predictive models, machine learning, and automatic creation of journey maps, but don’t have to.

Thunderhead ONE Engagement Hub is a charter member of this new little club. UK-headquartered Thunderhead itself was founded way back in 2001 and launched its original customer engagement product (highly personalized customer communications such as account statements) in 2004. ONE was developed by a U.S.-based engineering team.  It was released in Europe in 2015 and in the U.S. earlier this year.

Let’s look at how ONE handles the three core journey optimization functions:

- Data assembly. ONE provides its own Javascript tag to capture Web and email interactions and a SDK to connect with mobile apps. Other systems can feed data into ONE using a REST API or batch file imports. There are prebuilt API connectors for Salesforce.com CRM, Microsoft Dynamics CRM, and SAP Cloud for Customer. The system will automatically replicate the structure of imported data, maintaining relationships between different data elements. This allows ONE to store nearly any kind of data including not just customer attributes and identifiers, but also interaction and purchase details, touchpoint configurations, and product information.

Data is time-stamped to allow trending and give access to previous values of individual elements. Users can define calculations to create derived values such as engagement score, customer type, preferences, or interests. In addition to storing the imported information in a persistent database, ONE can lets users define in-memory profiles available for real-time access during interactions. These are updated immediately as new data is gathered, so the system is always working with the most current information.

ONE can link data using customer identifiers from different sources so long as there is a common element somewhere in the chain, such as an email address that is attached to a Web browser cookie through a form fill and to a mobile device through app registration. This allows the system to start tracking anonymous users when they first appear and later connect them to a personal profile when they identify themselves. But ONE does not standardize customer attributes, such as name or address, or use “fuzzy” matching to infer likely relationships.

All told, this is an exceptionally broad set of data management features. Many systems that build profiles – both CDPs and journey optimization engines – lack ONE's ability to store information about entities such as touchpoints or products. Nor do they always provide both a persistent data store and in-memory access. And while most can stitch together identities using shared identifiers, some rely on external systems to provide a common ID.

- Journey mapping. ONE lets users assign journey stages to activities and then classify interactions by activity type.  Interactions can also be tagged with other attributes such as channel, product, and marketing asset. The system uses this information to create many varieties of journey maps, including one that shows movement between stages broken out by channels, which is delightfully similar to the Customer Experience Matrix** I’ve been working with since 2006.*** Other versions filter the inputs to show maps for specific products, customer segments, or touchpoints within a channel (such as specific Web sites, retail stores, or phone agents). Maps can also compare attributes of different groups, such as customers who advanced towards purchase vs those who dropped out. Slicing the data in yet another way, maps can show the impact on engagement score of specific actions.  Hours of fun, eh?

- Execution. Users can create “conversations” that send messages to customers who match a specified combination of journey stage, customer attributes, and channels.  Eligibility and relevance rules can ensure the chosen messages are truly appropriate. One conversation can include several  messages in different channels.  Message contents can be drawn from a repository within ONE or from an external asset library.

The system uses machine learning to estimate how each customers will respond to each conversation and to calculate the value of the conversation. An arbitration function can then find the highest value conversation in each situation. The system can deploy conversations in real time, presenting CRM agents with recommended actions (along with a detailed customer profile and history) or Web pages with personalized contents (deployed in user-specified locations on the page). Personalized content and data can also be pushed to other execution systems such as email through API connections, either in batch or real time. External systems can access individual customer records through the ONE API.  Data can also be extracted from ONE to standard SQL databases, which external systems could then query.

Pricing for ONE starts at $30,000 per year and is based on the volume of interactions and personalization recommendations, with unit costs varying by channel.  The system has 38 clients in Europe and about a dozen in North America.

______________________________________________________________________________

*I would love to call these JOEs but don’t have the heart to inflict another obscure acronym on the industry. You’re welcome.

** Originally developed by my colleague Michael Hoffman. Click here for his take on it.

*** I’m not suggesting that Thunderhead based their map on the Customer Experience Matrix. Many people have come up with similar ideas. I do like to think that Hoffman and I were ahead of our time.

Hive9 Marketing Performance Management Includes Customer Journey Optimization

As I mentioned in last week's post on the MarTech Conference, there appears to be an emerging class of vendors doing what might be called “journey management” – although I think I’ll rename that “journey orchestration” since (a) orchestration is a trendier term right now and (b) orchestration more accurately reflects the key notion of a system that coordinates other systems.*  This coordination includes both gathering data from multiple sources and sending messages through other systems. Sending messages distinguishes journey orchestration engines from “pure” Customer Data Platforms, which assemble data but don’t make decisions about customer treatments. Some not-so-pure CDPs do combine the data assembly and decisioning, but they don’t use a system-assembled customer journey as the framework for message selection.

Whoa.  What the heck does that last sentence mean?  Let me unpack it a bit:

- By “system-assembled customer journey” I mean the systems automatically derive a customer journey from the customer data they’ve assembled. That’s quite different from pre-defining an ideal customer journey and trying to force customers to follow it. It’s even more different from taking conventional multi-step campaigns and calling them "journeys”.  A true "system-assembled journey" would be built by examining the sequence of events for each customer and finding the most common paths to purchase. This still isn't a purely objective process because some human or machine judgement is still needed to exclude irrelevant details, assign interactions to journey stages, and select the most important sequences.  But it's much more data-driven than starting with an marketer-created design.

- By “journey as the framework for message selection” I mean that marketing messages or campaigns are triggered when customers reach a particular journey step. Again, this is different from defining selection rules separately for each campaign, which is how conventional marketing automation and real-time interaction systems work. It’s also different from systems that draw journey maps but don’t connect them with campaigns for execution. Attaching all campaigns to a single journey map simplifies creation of selection rules and provides greater visibility into relationships among campaigns. In other words, journey orchestration makes it easier to coordinate customer treatments across multiple campaigns, which is one of the key problems with conventional marketing automation and interaction management approaches.**

Ok, let’s assume you’re now convinced that “journey orchestration engine” has a specific meaning that describes something useful. Your next question, presumably, is where can I buy one? (Oh, you’re not that easy to sell? Listen closely: It’s new. It’s bright. It’s shiny. New. Bright. Shiny. Newbrightshiny. Now are you ready to buy? I thought so.) My blog post listed three vendors from the MarTech show: Pointillist, Usermind, and Thunderhead. I promise I’ll review those soon. But I had already spoken with another relevant vendor before the show, Hive9. So let’s start with them.

If you look at Hive9’s Web site, you may wonder whether I’ve sent you to the right place.  They position themselves as “marketing performance management” with no mention of anything resembling journey orchestration. That’s because Hive9 actually has three connected modules: one for marketing planning, one for marketing measurement, and one for optimization (which is what I’m calling journey orchestration). These were all developed within B2B marketing agency Bulldog Solutions, which spun off Hive9 about a year ago.

The planning module was the original product. It lets marketers set up a hierarchy with plans at the top, going down to programs, campaigns, and tactics. Tactics have owners, budgets, start and end dates, revenue targets, types (usually a channel or asset) and other attributes such as journey stage, audience, business unit, geography, and language. These can be tailored to each client. Tactics can be tied to Workfront for project management, filtered on pretty much any attribute, and displayed on a Gantt chart-style calendar. Integration with Oracle Eloqua and Salesforce.com lets a new tactic automatically create a corresponding campaign in either system.  Each plan can have a marketing funnel with its own set of stages and targets for conversion rates, velocity, and deal size.

The measurement module reads information from plans and imports revenue, accounts, opportunities, and contacts from CRM, marketing automation, and other systems. Standard integrations are available for Salesforce.com, Oracle Eloqua, Marketo, Google Analytics, Adobe Marketing Analytics, and other systems. Other sources can be integrated through API connections or flat file imports. The system relies primarily on customer identifiers provided by source systems although it can stitch together identities when different systems share some IDs.

Once the data is loaded, the measurement module provides dashboards and other reports to show marketing results including revenue impact; counts, conversion rates and velocity by funnel stage; and whatever other data the client has integrated, such as social sentiment or customer satisfaction. Revenue impact can be measured with first-touch, last-touch, evenly-weighted, position-based, and several other algorithms.  The vendor plans to add statistically inferred weights in April. Results can be filtered by plan, audience, tactic type, assets, or other attributes; compared across time periods; and examined for trends. Dashboards are customized by the vendor for each client, although Hive9 plans to add self-service capabilities in the future.

The optimization module is where journey orchestration happens. Journey stages are defined within the optimization module.  Tactics can be tagged directly with stages, or stages can be assigned to assets which are themselves assigned to tactics.  Events or assets managed in other systems can also be tagged with a journey stage and channel.  However the connection is made, campaign responses are tagged with channel and journey stage and then assembled into a journey map. The map shows the number of interactions by channel and stage and highlights the most common path taken by buyers. This isn’t fully automated journey mapping because the stages are preassigned by the marketer. But the system does discover the most popular paths and most effective marketing assets on its own. So that’s pretty close.

Even more important, the optimization module can contain rules that trigger external marketing campaigns when a customer enters a given journey stage. This is what really qualifies Hive9 as a journey optimization engine. Here's how it works: users can set up a rule tied to journey stage, product type, or customer attribute such as industry or persona. Customers who qualify for a rule can be sent to specified marketing automation campaign. Rules can avoid repeating messages to the same person and can select a “next best message” for the external system to deliver. This definitely qualifies as journey orchestration.

Hive9 pricing starts around $25,000 per year for mid-market clients.  Modules are priced separately. Fees are based on the size of the company marketing budget for the planning module, on the number of records, dashboards, and data sources for the the measurement module, and on the number of touchpoints for the optimization module.

________________________________________________________________________________
* Also, this lets me call systems that do this “journey optimization engines”, giving a three letter acronym of JOE, which is so darn cute.

** You may notice that “journey optimization” sounds a lot like what I’ve previously called “state-based marketing”. Both do select marketing treatments based on a customer’s location within a state/stage framework. If I had to draw distinction, I’d say that journeys suggest forward progression from one stage to the next, while movement among states is not necessarily linear. Similarly, journey orchestration engines send marketing messages through other systems, while state-based systems could use internal or external delivery functions. In other words, journey orchestration is a special type of state-based system.