This blog has mentioned BlueConic in passing a couple of times but never quite gotten around to reviewing it in detail. Until now.
The delay may seem surprising, since BlueConic qualifies as a Customer Data Platform, a type of system I’ve been arguing will play an increasingly central role in marketers’ futures. For those of you who haven’t been paying close attention, a CDP is defined as a
• marketer-controlled system that
• supports external marketing execution based on
• persistent, cross-channel customer data.
This definition distinguishes CDPs from traditional marketing automation products, which do their own execution, and from real-time interaction managers, which lack persistent data stores. CDPs are important because few marketers have been able to build adequate cross-channel databases and because connecting those databases with execution systems has been difficult. The databases and connections are needed because today's customers expect personalized, coordinated treatments across all channels. Call it the “Amazon fallacy”: customers believe that since Amazon.com can give them highly personalized treatments, so can everyone else.
Anyway, back to BlueConic. The system has two main capabilities, which are to maintain customer profiles and to deliver targeted messages. The profiles can be based on data imported from other systems via batch processes or APIs or captured by BlueConic itself. It does this with “listeners” that can read data from forms or monitor behaviors via Javascript tags on Web pages, emails, and other media. “Listeners” can also create interest rankings and scores based on user behavior. All of these become available as attributes on the customer profile, which in turn can create customer segments and drive targeted messages.
The messages are delivered by what BlueConic calls “dialogues”, each of which sends a single message to a single location (email, text message, section on a Web page, etc.) to a specified customer segment. Messages tailored to customer interests would require creating a separate segment for each message. Similarly, presenting a sequence of messages would require a separate dialogue for each step in the sequence. If a customer is eligible for several dialogues at once, the system currently relies on an optimizer to pick best-responding option and will soon let users create rules to further guide the results. There is no built-in predictive modeling but the optimizer can continuously test alternative messages within a dialogue and automatically deploy the winner. Users can also apply a frequency cap to dialogues to limit the number of times any customer sees the same message.
BlueConic’s integration features are more extensive than its decision management. The system can capture data entered into forms even if the form ise not submitted. Users can insert message contains into an existing Web page without writing HTML code. Profiles capture customer identifiers provided by other systems and are automatically merged when two profiles are linked to the same external ID. Data is exchanged with other sources and execution systems via REST APIs. There are standard integrations with Twitter, Facebook, and Salesforce.com, as well as a system development kit for integration with mobile apps. The underlying data store is Apache Cassandra running on Amazon Web Services, which is highly flexible and scalable at moderate cost.
Integration and data management are what make BlueConic most interesting from a CDP perspective, since those are the core CDP functions. A “pure" CDP would provide only those services while leaving decision management and message delivery to other systems. I expect “pure” CDPs to appear, but most marketers prefer a broader solution, like BlueConic, to assembling the components for themselves. Pure CDPs will become more attractive as integration becomes easier through more standard APIs and connectors, a promise that cloud-based systems often make but are just starting to deliver.
BlueConic’s pricing is already data-centric: fees are based on numbers of profile and channels, not interactions or messages. Prices start around $1,000 per month although most clients pay more. Current implementations are mid-size and enterprise firms in B2C industries including retail, publishing, financial services, utilities, telecommunications, sports and travel. The system has about 70 current customers and is sold both directly and to partners such as ad agencies, other software vendors, and marketing service providers.
Showing posts with label interaction management. Show all posts
Showing posts with label interaction management. Show all posts
Saturday, September 27, 2014
Wednesday, June 19, 2013
AgilOne Combines Marketing Database, Analytics and Execution: Yep, That's a Customer Data Platform
Well, this is embarrassing.
Here I am, all excited about discovering a new category of Customer Data Platform systems, which combine marketing database management, predictive modeling, and decision engines. Then I bump into Omer Artun, CEO of AgilOne , which he founded seven years ago to combine marketing database management, predictive modeling, and decision engines. It makes me feel much less clever.
But I guess I can’t hold that against AgilOne. As Artun tells the story, the company was created to provide marketers with a packaged, cloud-based version of the advanced data management, analytics, and execution capabilities that are usually available only to the largest and richest firms. The key is a set of 400 standard metrics, which AgilOne derives by mapping each client’s unique data into a standard structure. This, combined with advanced machine learning techniques, lets AgilOne build ten standard predictive models (engagement, next product, lifetime value, etc.) and three standard cluster models (products, behaviors, and brands) with minimal effort. The system builds on these to deliver packages of standard alerts, reports, guided analytics, individual customer profiles, and campaign lists. It also makes its data and predictions accessible to external systems such as call centers and Web sites via real time API calls, so those systems can use them to guide their own customer treatments.
This quick summary doesn’t do justice to the cleverness or sophistication of AgilOne’s approach. Clever, because the standardization allows it to quickly and cheaply deliver a full stack of capabilities, starting with database building and ending with advanced analytics, recommendations, and execution. Sophisticated, because it tailors the standard structures to each client’s business, so what it delivers isn’t some simple, cookie-cutter output.
Some of the tailoring is unavoidably manual, such as mapping client data sources to the standard data model. But much is highly automated, such as predictive models, clusters, and recommendations. I was particularly intrigued by the standard alerts, which look for significant changes in key performance indicators such as churn, margin, or average order value. That sort of alerting is exactly what I've long felt marketers really wanted from their analytics tools. AgilOne takes this a step further by automatically listing the data attributes with the greatest statistical impact on each item. The company refers to these items as goals to prioritize, which is a bit of a stretch – the most powerful variable isn’t necessarily the one marketers should focus on the most. But, as Damon Runyon said*, that’s the way to bet.
The system also recommends actions related to each alert, such as certain types of marketing campaigns. Again, there’s a bit less here than meets the eye, since the recommendations are drawn from a knowledgebase that’s the same for all clients. But that’s still better than nothing, and clients can customize their copy of the knowledgebase if they want.
The other especially noteworthy strength of AgilOne is data preparation. My original concept of the Customer Data Platform included customer data integration, which involves standardizing and matching customer records from different systems. I’ve pulled back from that because almost none of the vendors actually do such processing. Most assume it will be done elsewhere, or not at all, and only associate records with an exact match on a key such as a customer ID. AgilOne does the hard stuff: quality checks, outlier detection, name parsing, address standardization, geocoding, phonetic matching, persistent ID management, and more. This is also highly automated and uses the company’s own technology. The lack of these capabilities prevents many companies from building a truly integrated customer database at many companies, so it’s extremely valuable for AgilOne to provide it.
If AgilOne has a weakness, it's at the execution end of the process. Users can set up campaigns that generate lists on demand or on a regular schedule. But I didn't see multi-step campaign flows or sophisticated decision management, such as arbitration across multiple eligible offers. Some of that can probably be managed through advanced filters and custom models, which the system does provide. However, making it truly accessible to non-technical users requires a specialized interface that the system apparently lacks.
While AgilOne just recently appeared on my personal radar, plenty of other people had already noticed: the company says nearly 100 brands are using the system. Sales efforts have been concentrated among mid-size B2C organizations, typically with at least 200,000 customers and $15 to $20 million in revenue. Pricing is published on the company Web site and is based on the features used and number of active customers. Entry price for the complete set of features starts around $9,000 per month.
_________________________________________________________________________________
*“The race is not always to the swift nor the battle to the strong, but that's the way to bet.” Runyon himself credited Chicago journalist Hugh Keough.
Here I am, all excited about discovering a new category of Customer Data Platform systems, which combine marketing database management, predictive modeling, and decision engines. Then I bump into Omer Artun, CEO of AgilOne , which he founded seven years ago to combine marketing database management, predictive modeling, and decision engines. It makes me feel much less clever.
But I guess I can’t hold that against AgilOne. As Artun tells the story, the company was created to provide marketers with a packaged, cloud-based version of the advanced data management, analytics, and execution capabilities that are usually available only to the largest and richest firms. The key is a set of 400 standard metrics, which AgilOne derives by mapping each client’s unique data into a standard structure. This, combined with advanced machine learning techniques, lets AgilOne build ten standard predictive models (engagement, next product, lifetime value, etc.) and three standard cluster models (products, behaviors, and brands) with minimal effort. The system builds on these to deliver packages of standard alerts, reports, guided analytics, individual customer profiles, and campaign lists. It also makes its data and predictions accessible to external systems such as call centers and Web sites via real time API calls, so those systems can use them to guide their own customer treatments.
This quick summary doesn’t do justice to the cleverness or sophistication of AgilOne’s approach. Clever, because the standardization allows it to quickly and cheaply deliver a full stack of capabilities, starting with database building and ending with advanced analytics, recommendations, and execution. Sophisticated, because it tailors the standard structures to each client’s business, so what it delivers isn’t some simple, cookie-cutter output.
Some of the tailoring is unavoidably manual, such as mapping client data sources to the standard data model. But much is highly automated, such as predictive models, clusters, and recommendations. I was particularly intrigued by the standard alerts, which look for significant changes in key performance indicators such as churn, margin, or average order value. That sort of alerting is exactly what I've long felt marketers really wanted from their analytics tools. AgilOne takes this a step further by automatically listing the data attributes with the greatest statistical impact on each item. The company refers to these items as goals to prioritize, which is a bit of a stretch – the most powerful variable isn’t necessarily the one marketers should focus on the most. But, as Damon Runyon said*, that’s the way to bet.
The system also recommends actions related to each alert, such as certain types of marketing campaigns. Again, there’s a bit less here than meets the eye, since the recommendations are drawn from a knowledgebase that’s the same for all clients. But that’s still better than nothing, and clients can customize their copy of the knowledgebase if they want.
The other especially noteworthy strength of AgilOne is data preparation. My original concept of the Customer Data Platform included customer data integration, which involves standardizing and matching customer records from different systems. I’ve pulled back from that because almost none of the vendors actually do such processing. Most assume it will be done elsewhere, or not at all, and only associate records with an exact match on a key such as a customer ID. AgilOne does the hard stuff: quality checks, outlier detection, name parsing, address standardization, geocoding, phonetic matching, persistent ID management, and more. This is also highly automated and uses the company’s own technology. The lack of these capabilities prevents many companies from building a truly integrated customer database at many companies, so it’s extremely valuable for AgilOne to provide it.
If AgilOne has a weakness, it's at the execution end of the process. Users can set up campaigns that generate lists on demand or on a regular schedule. But I didn't see multi-step campaign flows or sophisticated decision management, such as arbitration across multiple eligible offers. Some of that can probably be managed through advanced filters and custom models, which the system does provide. However, making it truly accessible to non-technical users requires a specialized interface that the system apparently lacks.
While AgilOne just recently appeared on my personal radar, plenty of other people had already noticed: the company says nearly 100 brands are using the system. Sales efforts have been concentrated among mid-size B2C organizations, typically with at least 200,000 customers and $15 to $20 million in revenue. Pricing is published on the company Web site and is based on the features used and number of active customers. Entry price for the complete set of features starts around $9,000 per month.
_________________________________________________________________________________
*“The race is not always to the swift nor the battle to the strong, but that's the way to bet.” Runyon himself credited Chicago journalist Hugh Keough.
Wednesday, November 28, 2012
[x+1] Origin Digital Marketing Hub Offers Cross-Channel Decision Management
My recent posts on real time decision systems have all described products from vendors of batch-oriented, outbound campaign management systems. Expansion to real time decisions helps those vendors cement their strategic position as a complete solution for marketing departments. But technically the two sets of systems have little in common: outbound systems create lists for direct mail and email, while real time systems generate recommendations for Web sites and call centers. Knowing this, you might suspect there are other real time decision management vendors with roots in Web marketing. You would be correct.
[x+1] Origin Digital Marketing Hub is one example. [x+1] originally began as Poindexter Systems, which offered real-time Web ad optimization based in predictive models and anonymous user profiles. This was an early form of what now called a Data Management Platform (DMP), which one articulate blogger defined as “a very smart, very fast cookie warehouse with analytical firepower to crunch, de-duplicate, and integrate your data with any technology platform you desire.”
You could also see DMPs as a type of marketing database because they have the key characteristic of being organized around individual prospects and customers. It’s true that DMPs identify individuals with cookies, not a conventional name and address. But both types of systems can still perform the basic marketing database functions of sending messages to individuals and tracking their responses.
That original DMP is still the foundation of the [x+1] suite. But the company has also extended into Web ad buying (Origin Media DSP), Web site recommendations (Origin Site), attribution (Origin Analytics), and cross channel marketing (Origin Digital Marketing Hub). Supporting multiple channels and potentially storing names and addresses puts [x+1] Hub into direct competition with other real-time decision management products.
I’ll assess the Hub against my real time decision management framework in a minute. But first let's look at [x+1]’s features that are not found in a typical real time decision manager. These include:
- Web tag management: the system provides Javascript code to tag Web pages and advertisements, drop cookies on visitors’ computers, and then use those cookies to track visitor behaviors. The system also supports server-to-server connections that capture user behavior without relying on cookies. Most real time decision systems rely on external systems to capture this data.
-Web audience management: [x+1] Hub can integrate Web audience data from external compilers such as BlueKai and eXelate, enabling marketers to use that information for decisions and targeting. In theory, any decision manager could access the APIs of those providers, but [x+1] is designed specifically to integrate their data and manage the associated charges. [x+1] can also help sell the client’s own data to external syndicators.
- Web media buying: [x+1] can manage real-time bids and other Web advertising purchases. Users set up campaigns with budgets, cost targets, date ranges and other parameters for the system to execute automatically. The system can also track media purchases made outside of [x+1]. Reports provide detailed information on reach, frequency, pacing, inventory, and other advertising-specific metrics.
- attribution: the system tracks visitors through user-defined funnel stages, as defined by visits to specified Web pages or media exposures. It then uses regression analysis to estimate the influence of each promotion and promotion attributes, such as ad size and format, on stage movement . This is much more sophisticated than the first touch, last touch, or fractional attribution methods available in standard marketing systems.
These features make clear that [x+1] Hub isn’t directly comparable to conventional real time decision systems. But [x+1] does offer itself for real time decision applications, and the whole point of decision management is to centralize decisions within a single system. This means that [x+1] Hub is inevitably competing with the other products to be the one thing that rules them all.
So, how does [x+1] Hub stack up against my decision management criteria?
- connecting to external systems. Like other real time decision managers, [x+1] Hub can connect to external systems via Web services and batch file imports. It can also capture Web traffic via the Javascript tags and server-to-server connections. However, displaying the returned messages on a Web site requires code created outside of the system. [x+1] Hub has existing integrations into call center, search, mobile, SMS, social, and email products.
Visitor profiles are stored permanently within the system and can contain whatever attributes the user chooses. The base set includes visitor behaviors, http header attributes (browser, operating system, location derived from IP address, etc.), information imported from external data vendors, and a history of messages presented to each individual. The system can link cookies from [x+1], the client, and third party vendors once these are identified as the same person. Partners including LiveRamp, i-Behavior and Datalogix can link online and offline identities.
Web behaviors and imported data can trigger actions including as assigning a visitor to a segment, adjusting a counter, exporting data, and sending a message through an external system. The results of these actions are stored in the [x+1] database where they can be inputs to other decision rules.
- making decisions based on rules and predictive models. Decision rules in [x+1] Hub are organized into two layers: the system first tests a visitor against one or more “targeted experience” definitions until it finds a match; then, it tests the visitor against a sequence of “targeting rules” associated with the winning experience. Each rule returns a specified offer or creative treatment. Offers and creatives can also have their own eligibility rules, which apply across all campaigns.
Rules can include if/then logic or predictive models. If the models are used, [x+1] can generate scores for multiple responses and pick the best option based on response probability, expected value, or other formulas. This lets the [x+1] select the best option for each individual even though the system always selects the first rule the visitor matches. There are also default choices in case the visitor fails to meet any other rule.
The models are set up by [x+1] technicians. Scoring formulas can incorporate external data, such as inventory levels or sales goals, so long as these are accessible to [x+1] via data import or API connections. Users can also specify the percentage of responses that will receive each option, allowing the system to deliver a fixed mix of results even if the models would favor some choices less or more often.
The system can return multiple offers in response to a single request. Users can block these from containing duplicate offers. Users can also set up “creative groups” of incompatible offers and have the system return only one offer from each group.
- integration with campaign and content systems. [x+1] Hub is not part of a suite with its own outbound campaign manager, although it can be integrated with other vendors’ campaign management products. Similarly, the system also doesn’t store or render content but can connect with third party content management systems. [x+1] does maintain a registry of content IDs that are sent back to execution systems, which look up and render the related messages.
- deployment model. The entire [x+1] suite is sold as a subscription. This can include the software only or software plus supplemental services. On-premise deployment is technically possible but no client has yet selected it. Pricing is based on system functions and volumes. It starts around $12,500 per month but can be lower if the client is also buying media through [x+1].
All told, [x+1] Hub seems functionally competitive with stand-alone decision managers. Still, the system’s main appeal will be to marketers who want the DMP, media buying and attribution features. Those marketers should find that [x+1] Hub lets them coordinate real-time customer treatments across all channels without purchasing a separate decision management system.
Tuesday, November 20, 2012
Pitney Bowes Interaction Optimizer and Dialogue Offer Unified Inbound/Outbound Marketing Campaigns
In his classic Harvard Business Review article Marketing Myopia, Theodore Levitt argued that railroad companies could have survived the rise of the automobile had they considered their business to be providing transportation, not running trains. Someone at Pitney Bowes clearly got the message. The postal equipment giant has aggressively moved to become a provider of “customer communication technologies”, making 83 acquisitions costing $2.5 billion since 2000. Purchases have included Group 1 Software (2004), MapInfo (2007) and Portrait Software (2010), which are now part of a customer analytics and interaction group within the company’s software division.
Portrait itself brought an agglomeration of previous acquisitions, having expanded its original customer relationship management system by purchasing Quadstone analytics in 2005 and Million Handshakes marketing automation in 2008. Their descendants are now modules within integrated Portrait suite, including Portrait Explorer (visualization), Miner (predictive modeling), Uplift (model-based treatment selection), Foundation (data access and integration), Dialogue (multi-step outbound campaigns), and Interaction Optimizer (real-time decisions).
Dialogue and Interaction Optimizer are closely linked, sharing a user interface for campaign definition and both using Foundation to connect with external systems. The interface, called HQ, lets marketers define a hierarchy of campaigns linked to multiple marketing activities, which in turn contain multiple channels and offers. Offers are linked to products, which have customer-level eligibility criteria.
Marketing activities have budgets and response forecasts, which can be set for the activity as a whole or for each channel / message combination (called a treatment). An activity can be assigned an activity type, priority, and scoring rule, which are used to prioritize recommendations during inbound interactions. Activities can also be associated with tasks assigned to the user or others.
HQ provides dashboards showing a campaign calendar, personal and delegated tasks, and results by campaign, offer, and channel. The dashboard can be extended to include external data.
IO connects with touchpoints and other data sources through Foundation, which can accept via Web service calls or SQL queries. Foundation integrates the information it gathers and passes it to IO through a Web services interface. The system usually refreshes the data with each new request, but can be configured to retain data in memory during a multi-step interaction. IO is also integrated with GX Software BlueConic to track and segment Web site visitors. BlueConic-generated events can trigger IO messages and BlueConic-captured behaviors can be loaded to the IO database.
Recommendations in IO are based on marketing activities. Each recommendation has audience and message definitions. The audience can be defined by any combination of static lists, dynamic selections, and scoring rules. Messages belong to a single channel and provide content in a channel-specific format. The content may be an actual message or a pointer interpreted by the touchpoint. IO provides a HTML generator to create messages. These can be personalized with data from the customer record. Messages can be linked to offers, although this is optional.
When IO receives a recommendation request, it checks against the audience and offer definitions of all active recommendations to identify those that are available to the current customer in the current situation. It sorts the options based on activity type, priority, and scoring results, which can be applied in whatever sequence the user defined during campaign setup. More advanced prioritization could be built into the scoring rules but requires a modeling specialist. After the recommendation is selected, it is sent back to the touchpoint for delivery.
Scoring models can be created and automatically updated within IO or imported from external systems. The self-updating models are less accurate than batch built models but make sense where conditions change quickly or very large numbers of models are needed. External models can be created in Portrait’s own modeling tools or with third party software. Scores are calculated within IO using current data.
IO recommendations are generally called by an external touchpoint but can also be embedded within a Dialogue campaign flow, used to generate outbound campaigns. Dialogue provides a drag-and-drop flow builder with a broad range of capabilities to manage data, direct data flows, send messages, and access social media. Campaigns can execute as batch processes or events triggered by database stored procedures. Other Pitney Bowes product offer additional features for database management, data quality, and message creation.
Both IO and Dialogue are available as on-premise software or hosted by Pitney Bowes. Pricing of IO is based on the database size and number of channels supported. It starts around $75,000 for a 100,000 row database for one channel for a perpetual on-premise license. The system has fewer than 50 installations.
Portrait itself brought an agglomeration of previous acquisitions, having expanded its original customer relationship management system by purchasing Quadstone analytics in 2005 and Million Handshakes marketing automation in 2008. Their descendants are now modules within integrated Portrait suite, including Portrait Explorer (visualization), Miner (predictive modeling), Uplift (model-based treatment selection), Foundation (data access and integration), Dialogue (multi-step outbound campaigns), and Interaction Optimizer (real-time decisions).
Dialogue and Interaction Optimizer are closely linked, sharing a user interface for campaign definition and both using Foundation to connect with external systems. The interface, called HQ, lets marketers define a hierarchy of campaigns linked to multiple marketing activities, which in turn contain multiple channels and offers. Offers are linked to products, which have customer-level eligibility criteria.
Marketing activities have budgets and response forecasts, which can be set for the activity as a whole or for each channel / message combination (called a treatment). An activity can be assigned an activity type, priority, and scoring rule, which are used to prioritize recommendations during inbound interactions. Activities can also be associated with tasks assigned to the user or others.
HQ provides dashboards showing a campaign calendar, personal and delegated tasks, and results by campaign, offer, and channel. The dashboard can be extended to include external data.
Recommendations in IO are based on marketing activities. Each recommendation has audience and message definitions. The audience can be defined by any combination of static lists, dynamic selections, and scoring rules. Messages belong to a single channel and provide content in a channel-specific format. The content may be an actual message or a pointer interpreted by the touchpoint. IO provides a HTML generator to create messages. These can be personalized with data from the customer record. Messages can be linked to offers, although this is optional.
When IO receives a recommendation request, it checks against the audience and offer definitions of all active recommendations to identify those that are available to the current customer in the current situation. It sorts the options based on activity type, priority, and scoring results, which can be applied in whatever sequence the user defined during campaign setup. More advanced prioritization could be built into the scoring rules but requires a modeling specialist. After the recommendation is selected, it is sent back to the touchpoint for delivery.
Scoring models can be created and automatically updated within IO or imported from external systems. The self-updating models are less accurate than batch built models but make sense where conditions change quickly or very large numbers of models are needed. External models can be created in Portrait’s own modeling tools or with third party software. Scores are calculated within IO using current data.
IO recommendations are generally called by an external touchpoint but can also be embedded within a Dialogue campaign flow, used to generate outbound campaigns. Dialogue provides a drag-and-drop flow builder with a broad range of capabilities to manage data, direct data flows, send messages, and access social media. Campaigns can execute as batch processes or events triggered by database stored procedures. Other Pitney Bowes product offer additional features for database management, data quality, and message creation.
Both IO and Dialogue are available as on-premise software or hosted by Pitney Bowes. Pricing of IO is based on the database size and number of channels supported. It starts around $75,000 for a 100,000 row database for one channel for a perpetual on-premise license. The system has fewer than 50 installations.
Thursday, June 09, 2011
Swyft Offers Low-Cost Interaction Management Software as a Service
Summary: Swyft offers a Software-as-a-Service real-time interaction manager. It costs less than traditional versions of those products but has similar features.
Last month’s post on Oracle Real Time Decisions offered a brief overview of real-time interaction management products. I won’t repeat that here, except to summarize that these systems use data from multiple source systems to feed centrally-managed, real-time decisions to multiple touchpoints. The most common application has probably been product recommendations in customer service call centers, where there’s a substantial opportunity to sell something to a customer once you’ve solved their problem. Another frequent use has been selecting offers on Web sites, such as the familiar book recommendations on Amazon.com.
You’ll note that both of these are single-channel examples. That may seem odd, since coordinating treatments across channels is a key selling point. I believe the explanation is that most buyers purchase interaction management systems to get more powerful decision engines than those provided with their call center and Web site products.
Indeed, effective interaction management requires a sophisticated mix of predictive modeling, business rules, flow management, response capture, data integration, real-time processing, simulation, and analytics. The simple scripting and personalization engines built into call center and Web products don't provide all this. Equally important, the results of an interaction management deployment are immediately and precisely measureable – so it’s clear when one product works better than another. This means specialist vendors with superior products have a good chance to survive.
But you’ll also notice that these products don’t have many customers. I haven’t done a proper census but doubt there are five hundred implementations among all vendors combined. One reason is the sophistication itself: only a highly knowledgeable set of users can deploy the required rules and models effectively. Another is cost: you’re looking at the price of a 50 foot yacht (about a quarter million dollars if you haven’t bought one lately), plus a sister ship or two for implementation. Few firms with the resources and business volume needed to justify this expense.
(Alternate interpretation: the tools built into standard call center and Web applications are pretty good, so dedicated interaction managers offer only a small percentage gain. A company must be quite large for this to cover the interaction manager's cost.)
Swyft provides a low-cost alternative – more like a 30 footer (around $100,000).
The comparison is inexact because traditional interaction management systems are sold as licensed on-premise software, while Swyft is a Software-as-a-Service product, billed monthly. Pricing for agent-based applications (call centers, field sales, etc.) runs about one dinghy per user ($50 to $80 per month). But even small clients buy a fleet of 100 or more. Web site applications are priced on number of customers but come to roughly the same total.
Implementation is around $15,000 to $25,000, with data connections handled through standard Web Services. The company says a typical deployment takes 30 to 90 days, usually closer to 30.
Functionally, Swyft offers a pretty full set of interaction management capabilities. Decision rules can take into account capacity constraints such as call center workload; customer propensities; current and previous interactions; channel distinctions; offer eligibility; and event-based triggers. Interactions can kick off complex back-end workflows for follow-up treatments.
Call center integrations monitor agent activities and flash an alert if the system has an offer to make. The system then guides the agent through transition statements, probing questions, objections, offers, closing statements, and disposition capture. It can present different messages depending on the agent’s skill level. Web site implementations can present offers, collect data, and run champion/challenger and multivariate tests. The system will automatically adjust offer frequencies based on test results.
One feature that Swyft lacks is built-in predictive modeling. The company says it has found that most clients already have models in place. Rules can use model scores as inputs.
Like other interaction managers, Swyft relies primarily on data stored in external systems. Again like other products, it creates its own database of offers made and responses received for each customer. Less typically, it also stores marketing contents internally and provides a content builder to create these. The system can import and store additioinal information if real-time access is not appropriate.
The current version of Swyft lacks an interface that lets business users create their own rules. The company addresses this largely by doing the work for its clients, providing a “concierge” service that includes content and rule management as part of the base price. Clients do have the option to do this work for themselves; the company says it can be done after a couple weeks of training. A simpler end-user interface is planned for future development.
Swyft was founded in 2004 and launched its product in 2006. It has about ten clients spread among financial services, insurance, communications and media. The largest are mid-sized firms, with a several million customers. Intriguingly, the company offers its product on the Salesforce.com App Exchange, specifically offering a smartphone-enabled version that can use geolocation to identify a salesperson’s current location and recommend the most efficient prospects to visit. It has not yet deployed this at an actual client.
Last month’s post on Oracle Real Time Decisions offered a brief overview of real-time interaction management products. I won’t repeat that here, except to summarize that these systems use data from multiple source systems to feed centrally-managed, real-time decisions to multiple touchpoints. The most common application has probably been product recommendations in customer service call centers, where there’s a substantial opportunity to sell something to a customer once you’ve solved their problem. Another frequent use has been selecting offers on Web sites, such as the familiar book recommendations on Amazon.com.
You’ll note that both of these are single-channel examples. That may seem odd, since coordinating treatments across channels is a key selling point. I believe the explanation is that most buyers purchase interaction management systems to get more powerful decision engines than those provided with their call center and Web site products.
Indeed, effective interaction management requires a sophisticated mix of predictive modeling, business rules, flow management, response capture, data integration, real-time processing, simulation, and analytics. The simple scripting and personalization engines built into call center and Web products don't provide all this. Equally important, the results of an interaction management deployment are immediately and precisely measureable – so it’s clear when one product works better than another. This means specialist vendors with superior products have a good chance to survive.
But you’ll also notice that these products don’t have many customers. I haven’t done a proper census but doubt there are five hundred implementations among all vendors combined. One reason is the sophistication itself: only a highly knowledgeable set of users can deploy the required rules and models effectively. Another is cost: you’re looking at the price of a 50 foot yacht (about a quarter million dollars if you haven’t bought one lately), plus a sister ship or two for implementation. Few firms with the resources and business volume needed to justify this expense.
(Alternate interpretation: the tools built into standard call center and Web applications are pretty good, so dedicated interaction managers offer only a small percentage gain. A company must be quite large for this to cover the interaction manager's cost.)
Swyft provides a low-cost alternative – more like a 30 footer (around $100,000).
The comparison is inexact because traditional interaction management systems are sold as licensed on-premise software, while Swyft is a Software-as-a-Service product, billed monthly. Pricing for agent-based applications (call centers, field sales, etc.) runs about one dinghy per user ($50 to $80 per month). But even small clients buy a fleet of 100 or more. Web site applications are priced on number of customers but come to roughly the same total.
Implementation is around $15,000 to $25,000, with data connections handled through standard Web Services. The company says a typical deployment takes 30 to 90 days, usually closer to 30.
Functionally, Swyft offers a pretty full set of interaction management capabilities. Decision rules can take into account capacity constraints such as call center workload; customer propensities; current and previous interactions; channel distinctions; offer eligibility; and event-based triggers. Interactions can kick off complex back-end workflows for follow-up treatments.
Call center integrations monitor agent activities and flash an alert if the system has an offer to make. The system then guides the agent through transition statements, probing questions, objections, offers, closing statements, and disposition capture. It can present different messages depending on the agent’s skill level. Web site implementations can present offers, collect data, and run champion/challenger and multivariate tests. The system will automatically adjust offer frequencies based on test results.
One feature that Swyft lacks is built-in predictive modeling. The company says it has found that most clients already have models in place. Rules can use model scores as inputs.
Like other interaction managers, Swyft relies primarily on data stored in external systems. Again like other products, it creates its own database of offers made and responses received for each customer. Less typically, it also stores marketing contents internally and provides a content builder to create these. The system can import and store additioinal information if real-time access is not appropriate.
The current version of Swyft lacks an interface that lets business users create their own rules. The company addresses this largely by doing the work for its clients, providing a “concierge” service that includes content and rule management as part of the base price. Clients do have the option to do this work for themselves; the company says it can be done after a couple weeks of training. A simpler end-user interface is planned for future development.
Swyft was founded in 2004 and launched its product in 2006. It has about ten clients spread among financial services, insurance, communications and media. The largest are mid-sized firms, with a several million customers. Intriguingly, the company offers its product on the Salesforce.com App Exchange, specifically offering a smartphone-enabled version that can use geolocation to identify a salesperson’s current location and recommend the most efficient prospects to visit. It has not yet deployed this at an actual client.
Thursday, May 26, 2011
Oracle Real-Time Decisions Empowers Business Users
One of the few dependable rules in the software industry is that Suites Win. When a market first develops, it is filled with “point solutions” that do one function – say, send emails or analyze Web traffic. Over time, products emerge that combine these functions and displace the individual point solutions. Even though the point solutions may be better at their particular task than the corresponding suite components, the time, cost, and risk savings of preintegrated products are irresistible to most buyers.* This is especially true when IT departments, rather than end-users, control the purchase process.
The only reason that companies haven’t already ended up with a single mega-system is that new applications appear constantly. It takes time before the existing suites can expand to assimilate the new features. This is especially true in customer management, where new touchpoints – Web, mobile, social, etc. – appear at a dizzying pace. In the real world, nearly all companies run multiple customer contact systems and probably always will.
What this means in practical terms is that companies wishing to coordinate customer treatments across channels need to knit together their separate touchpoints. A class of systems to do this has long existed, loosely labeled as “interaction managers” or “decision engines”. These systems manage outbound campaigns and real-time interactions using a combination of business rules and predictive models. Examples include Infor Interaction Advisor, IBM Unica Interact, Pegasystems Recommendation Advisor, SAS Real-Time Decision Manager, eponymous thinkAnalytics, and Oracle Real-Time Decisions.
These systems are all broadly similar in that they connect to external systems for customer data, marketing content, and message delivery. This contrasts with standard marketing automation and customer relationship management systems, which maintain their own customer databases, store content internally, and deliver messages themselves. Interaction managers and other types of customer management systems do share decision management capabilities including multi-step process flows, logical rules, and predictive models.
Interaction management vendors compete on the power of their rules, automated model generation, user interface, scalability, and analytics. To some degree they also compete their ability to connect with data sources and touchpoint systems. But every vendor I've spoken with says this integration is easy, so it doesn’t seem to be a major point of differentiation.
I caught up last week with the Oracle Real-Time Decisions (RTD) team, who released their latest version earlier this month. RTD is based on the SigmaDynamics product, originally built in 2002 and purchased by Oracle in 2006. Oracle now sells it as a general purchase decision platform, positioned as one of its business intelligence and middleware products. But although some clients do use it for customer service, sales, and operations management, 90% of implementations are still for marketing decisions, primarily to select offers for Web sites and call centers.
RTD’s particular strengths are automated learning and sophisticated decision rules. Users set up process flows, define decision points within each flow, and connect to touchpoint systems to capture events at those decision points. The system then automatically correlates event outcomes with creative, channels, offers, customer attributes and other factors. This happens without users specifying which factors to track -- a significant labor saving. The scope of data lets the system predict behaviors based on the full context of a situation, not just the customer’s identity. The data also provides the foundation for in-depth reports on the factors driving results, in addition to standard campaign reporting.
Decision rules can incorporate multiple goals, each assigned a relative weight, and multiple choices, each assigned a value towards reaching each goal. The system scores each choice by adding up the value it contributes to each goal, adjusted for the probability that the customer will accept that choice if offered. Users can also weigh goals differently for different customer segments: for example, retention might be more important for high-value customers, while cost reduction could be a priority for customers who are less profitable. The same goal definitions can apply to multiple decisions, reducing work and ensuring consistency.
Although RTD has always been powerful, its user interface was designed for technical users. The latest release changes this, introducing role-based security that allows different business users throughout an organization to control different functions. This means offers could be controlled by one person, campaigns designed by someone else, and touchpoint placements by a third party. Different users can also be presented with different views of the underlying objects, so they can see information organized in ways that make the most sense for their own purposes.
The new version of RTD is still aimed at large enterprises. Pricing depends on the type of deployment but it's a safe bet you won't get started for less than a couple hundred thousand dollars.
__________________________________________________________________________________
*True believers might argue that Software as a Service upends this rule by making integration very simple. I’ll grant that SaaS makes it easier to add new components on top of a standard platform such as Salesforce.com’s Force.com. But I'd argue that the platform itself is the functional equivalent of the suite, so the rule still stands.
The only reason that companies haven’t already ended up with a single mega-system is that new applications appear constantly. It takes time before the existing suites can expand to assimilate the new features. This is especially true in customer management, where new touchpoints – Web, mobile, social, etc. – appear at a dizzying pace. In the real world, nearly all companies run multiple customer contact systems and probably always will.
What this means in practical terms is that companies wishing to coordinate customer treatments across channels need to knit together their separate touchpoints. A class of systems to do this has long existed, loosely labeled as “interaction managers” or “decision engines”. These systems manage outbound campaigns and real-time interactions using a combination of business rules and predictive models. Examples include Infor Interaction Advisor, IBM Unica Interact, Pegasystems Recommendation Advisor, SAS Real-Time Decision Manager, eponymous thinkAnalytics, and Oracle Real-Time Decisions.
These systems are all broadly similar in that they connect to external systems for customer data, marketing content, and message delivery. This contrasts with standard marketing automation and customer relationship management systems, which maintain their own customer databases, store content internally, and deliver messages themselves. Interaction managers and other types of customer management systems do share decision management capabilities including multi-step process flows, logical rules, and predictive models.
Interaction management vendors compete on the power of their rules, automated model generation, user interface, scalability, and analytics. To some degree they also compete their ability to connect with data sources and touchpoint systems. But every vendor I've spoken with says this integration is easy, so it doesn’t seem to be a major point of differentiation.
I caught up last week with the Oracle Real-Time Decisions (RTD) team, who released their latest version earlier this month. RTD is based on the SigmaDynamics product, originally built in 2002 and purchased by Oracle in 2006. Oracle now sells it as a general purchase decision platform, positioned as one of its business intelligence and middleware products. But although some clients do use it for customer service, sales, and operations management, 90% of implementations are still for marketing decisions, primarily to select offers for Web sites and call centers.
RTD’s particular strengths are automated learning and sophisticated decision rules. Users set up process flows, define decision points within each flow, and connect to touchpoint systems to capture events at those decision points. The system then automatically correlates event outcomes with creative, channels, offers, customer attributes and other factors. This happens without users specifying which factors to track -- a significant labor saving. The scope of data lets the system predict behaviors based on the full context of a situation, not just the customer’s identity. The data also provides the foundation for in-depth reports on the factors driving results, in addition to standard campaign reporting.
Decision rules can incorporate multiple goals, each assigned a relative weight, and multiple choices, each assigned a value towards reaching each goal. The system scores each choice by adding up the value it contributes to each goal, adjusted for the probability that the customer will accept that choice if offered. Users can also weigh goals differently for different customer segments: for example, retention might be more important for high-value customers, while cost reduction could be a priority for customers who are less profitable. The same goal definitions can apply to multiple decisions, reducing work and ensuring consistency.
Although RTD has always been powerful, its user interface was designed for technical users. The latest release changes this, introducing role-based security that allows different business users throughout an organization to control different functions. This means offers could be controlled by one person, campaigns designed by someone else, and touchpoint placements by a third party. Different users can also be presented with different views of the underlying objects, so they can see information organized in ways that make the most sense for their own purposes.
The new version of RTD is still aimed at large enterprises. Pricing depends on the type of deployment but it's a safe bet you won't get started for less than a couple hundred thousand dollars.
__________________________________________________________________________________
*True believers might argue that Software as a Service upends this rule by making integration very simple. I’ll grant that SaaS makes it easier to add new components on top of a standard platform such as Salesforce.com’s Force.com. But I'd argue that the platform itself is the functional equivalent of the suite, so the rule still stands.
Tuesday, April 05, 2011
Whatsnexx Manages Customer States, Not Campaigns
Whatsnexx offers itself as a radically easier way to manage customer and prospect interactions than conventional marketing automation. I agree that it's radically different: it works without a central marketing database and tracks customer states rather than assigning them to campaigns. Whether it’s radically simpler is another question.
Some perspective is in order. Although Whatsnexx was launched just last year, state-based systems have been used in marketing before. Previous products include Verbind (later purchased by SAS), Elity (eventually owned by Unica), and Harte-Hanks Allink Agent (still around in some form). The concept is intriguing: instead of creating campaigns that predefine paths a lead can follow, you define the actions to take when customers are in a particular situation. The advantage is you can think in terms of new customers, loyal customers, disgruntled customers, etc., and specify how to treat each group after common events such as placing an order. Most marketers find this easier to conceptualize than a massive campaign with separate branches for each contingency.
Anyway, that’s the theory. In practice, defining customer treatments in Whatsnexx didn’t look much easier to me than defining them in other systems. (You can judge for yourself by viewing several how to videos on the company's Web site.) The process is this: users first define “scenarios”, which are customer processes such as acquisition, retention or complaints, and "states", which are customer types such as new, high value, or disgruntled. They then define the flow of events within each scenario, with the possible responses for each event for each customer state. Terminology aside, I don't find this much different from assigning customers to segments, assigning the segments to multi-step campaign flows, and assigning treatment rules to each step.
But maybe I’m missing the point. Whatsnexx’s Jacques Spilka says he finds huge time savings in the analysis stage that precedes the campaign set-up: instead of taking a week to understand client needs and processes, he can do it in a few hours using the state-based technique. Most of the time setting up any system is spent on analysis, not the mechanics of the campaign design. So savings of that magnitude would be significant. On the other hand, you still have to create the actual content, which is probably the biggest expense of all.
The other main difference between Whatsnexx and conventional marketing systems is that Whatsnexx doesn’t rely on an independent marketing database. This isn’t an inherent feature of state-based systems: other products do work with a database of their own. Indeed, even Whatsnexx maintains a central database of customers and their states. But Whatsnexx doesn’t import all the events that occur in other systems and it doesn’t send messages by itself. Rather, users configure "Infogates" that let existing systems send alerts to Whatsnexx when specified events occur. These alerts (technically, XML messages via a SOAP protocol) include whatever contextual information is needed for Whatsnexx decisions. Whatsnexx receives the alert, applies its logic, and returns a message telling the external system how to respond. The company has existing Infogates for Salesforce.com, Constant Contact, Deliva and CakeMail. It will add new Infogates as required by customers.
It seems to me that this approach is actually a more important differentiator for Whatsnexx than its state-based logic. As the company points out, it lets marketers continue to do their work in their existing systems. This saves the effort of learning a new tool and potentially needing to rewire their current infrastructure. It also lets them avoid building a central marketing database – although I suspect that many will need one anyway for data consolidation and analysis. Still, even deferring that need could remove a barrier to immediate adoption. This is especially true as marketers add data sources that are not built into standard marketing automation products, which are often limited to Salesforce.com and perhaps a tagged Web site.
Whatsnexx was developed by Montreal-based email company Komunik over several years. It was formally launched in late 2010 and has four current customers. Pricing is based on the client’s activity level and starts at $500 per month for up to 100,000 transactions.
Some perspective is in order. Although Whatsnexx was launched just last year, state-based systems have been used in marketing before. Previous products include Verbind (later purchased by SAS), Elity (eventually owned by Unica), and Harte-Hanks Allink Agent (still around in some form). The concept is intriguing: instead of creating campaigns that predefine paths a lead can follow, you define the actions to take when customers are in a particular situation. The advantage is you can think in terms of new customers, loyal customers, disgruntled customers, etc., and specify how to treat each group after common events such as placing an order. Most marketers find this easier to conceptualize than a massive campaign with separate branches for each contingency.
Anyway, that’s the theory. In practice, defining customer treatments in Whatsnexx didn’t look much easier to me than defining them in other systems. (You can judge for yourself by viewing several how to videos on the company's Web site.) The process is this: users first define “scenarios”, which are customer processes such as acquisition, retention or complaints, and "states", which are customer types such as new, high value, or disgruntled. They then define the flow of events within each scenario, with the possible responses for each event for each customer state. Terminology aside, I don't find this much different from assigning customers to segments, assigning the segments to multi-step campaign flows, and assigning treatment rules to each step.
But maybe I’m missing the point. Whatsnexx’s Jacques Spilka says he finds huge time savings in the analysis stage that precedes the campaign set-up: instead of taking a week to understand client needs and processes, he can do it in a few hours using the state-based technique. Most of the time setting up any system is spent on analysis, not the mechanics of the campaign design. So savings of that magnitude would be significant. On the other hand, you still have to create the actual content, which is probably the biggest expense of all.
The other main difference between Whatsnexx and conventional marketing systems is that Whatsnexx doesn’t rely on an independent marketing database. This isn’t an inherent feature of state-based systems: other products do work with a database of their own. Indeed, even Whatsnexx maintains a central database of customers and their states. But Whatsnexx doesn’t import all the events that occur in other systems and it doesn’t send messages by itself. Rather, users configure "Infogates" that let existing systems send alerts to Whatsnexx when specified events occur. These alerts (technically, XML messages via a SOAP protocol) include whatever contextual information is needed for Whatsnexx decisions. Whatsnexx receives the alert, applies its logic, and returns a message telling the external system how to respond. The company has existing Infogates for Salesforce.com, Constant Contact, Deliva and CakeMail. It will add new Infogates as required by customers.
It seems to me that this approach is actually a more important differentiator for Whatsnexx than its state-based logic. As the company points out, it lets marketers continue to do their work in their existing systems. This saves the effort of learning a new tool and potentially needing to rewire their current infrastructure. It also lets them avoid building a central marketing database – although I suspect that many will need one anyway for data consolidation and analysis. Still, even deferring that need could remove a barrier to immediate adoption. This is especially true as marketers add data sources that are not built into standard marketing automation products, which are often limited to Salesforce.com and perhaps a tagged Web site.
Whatsnexx was developed by Montreal-based email company Komunik over several years. It was formally launched in late 2010 and has four current customers. Pricing is based on the client’s activity level and starts at $500 per month for up to 100,000 transactions.
Thursday, March 18, 2010
Pegasystems Buys Chordiant to Help Coordinate Customer Treatment Decisions
Summary: Pegasystems purchased Chordiant last week, adding a sophisticated cross-channel decision engine to its stable. It's been hard for independent decision engines to survive, even though it seems an independent product should make it easier for marketers to unify their customer treatments.
Business process technology vendor Pegasystems announced on Monday that it was purchasing Chordiant, which offers a central decision engine for customer interactions. Although the news is interesting in its own right, it also triggered a twinge of personal regret because I’ve been meaning to write about Chordiant for nearly a year. At that time, they had just added some slick simulation capabilities that estimated outcomes if a different set of rules had been applied to historical interactions.
This type of simulation allows business managers, rather than technicians, to directly assess the impact of alternative business rules. It's an important sign of maturity, showing that the vendor has shifted resources from primary system functions (making things work) to supporting functions (making things work better).
If you’re not familiar with the Chordiant decision engine, its primary function is to apply business rules that guide real-time customer treatments. It has been deployed primarily in call centers, although it is designed to work across multiple touchpoints. To accomplish this, the system must accept inputs from each touchpoint about a current interaction, apply rules to select an offer, and feed the selection back to the touchpoint. Tracking results also requires a second loop for the touchpoint to report whether the offer was actually delivered and whether it was accepted.
The business rules can use both data provided by the touchpoint and data from other systems such as transaction and marketing databases. The rules frequently include predictive models that can either be built within Chordiant or imported from other systems such as SAS or SPSS. Chordiant also supports self-adjusting models that monitor outcomes and modify future recommendations based on the results of different offers.
The appeal of a stand-alone decision engine like Chordiant is that companies can coordinate treatments without using a single vendor for all their touchpoint systems. This makes perfect sense, since in practice most firms do use different products for different touchpoints. In particular, Web interactions are often managed outside of the CRM system.
Yet it’s still been difficult for stand-alone decision engines to survive. Most firms use whatever interaction management features are built into the separate touchpoint engines and coordinate the rules administratively (if at all). Or they rely on interaction management features provided by their marketing automation system.
A few independent decision engine vendors remain, notably thinkAnalytics (another product I’ve been meaning to write about for months) and eGlue (which I wrote about here [update: a week after this post was written, eGlue was apparently purchased by interaction management vendor NICE Systems, although I've yet to see a formal announcement]). But it’s ultimately not surprising that Chordiant should end up as part of Pegasystems, with which Chordiant had already been integrated. The new relationship will let Pegasystems offer added value to its clients and better compete with CRM vendors.
As an aside, it's interesting to compare the position of decision management vendors with execution vendors like Conversen (which I wrote about last month) and ClickSquared (yet another vendor I hope to review shortly). Both sets of products unify a single function that is otherwise spread across multiple systems: offer selection for decision engines and message delivery for execution engines.
The challenges faced by independent decision engines may suggest that the execution engines will face similar problems. But the execution engines sit at the end of the messaging sequence, rather than in its middle: that is, they process outputs from marketing systems and send them elsewhere, rather than feeding them back into the same systems for delivery. This may make it easier for them to survive.
Business process technology vendor Pegasystems announced on Monday that it was purchasing Chordiant, which offers a central decision engine for customer interactions. Although the news is interesting in its own right, it also triggered a twinge of personal regret because I’ve been meaning to write about Chordiant for nearly a year. At that time, they had just added some slick simulation capabilities that estimated outcomes if a different set of rules had been applied to historical interactions.
This type of simulation allows business managers, rather than technicians, to directly assess the impact of alternative business rules. It's an important sign of maturity, showing that the vendor has shifted resources from primary system functions (making things work) to supporting functions (making things work better).
If you’re not familiar with the Chordiant decision engine, its primary function is to apply business rules that guide real-time customer treatments. It has been deployed primarily in call centers, although it is designed to work across multiple touchpoints. To accomplish this, the system must accept inputs from each touchpoint about a current interaction, apply rules to select an offer, and feed the selection back to the touchpoint. Tracking results also requires a second loop for the touchpoint to report whether the offer was actually delivered and whether it was accepted.
The business rules can use both data provided by the touchpoint and data from other systems such as transaction and marketing databases. The rules frequently include predictive models that can either be built within Chordiant or imported from other systems such as SAS or SPSS. Chordiant also supports self-adjusting models that monitor outcomes and modify future recommendations based on the results of different offers.
The appeal of a stand-alone decision engine like Chordiant is that companies can coordinate treatments without using a single vendor for all their touchpoint systems. This makes perfect sense, since in practice most firms do use different products for different touchpoints. In particular, Web interactions are often managed outside of the CRM system.
Yet it’s still been difficult for stand-alone decision engines to survive. Most firms use whatever interaction management features are built into the separate touchpoint engines and coordinate the rules administratively (if at all). Or they rely on interaction management features provided by their marketing automation system.
A few independent decision engine vendors remain, notably thinkAnalytics (another product I’ve been meaning to write about for months) and eGlue (which I wrote about here [update: a week after this post was written, eGlue was apparently purchased by interaction management vendor NICE Systems, although I've yet to see a formal announcement]). But it’s ultimately not surprising that Chordiant should end up as part of Pegasystems, with which Chordiant had already been integrated. The new relationship will let Pegasystems offer added value to its clients and better compete with CRM vendors.
As an aside, it's interesting to compare the position of decision management vendors with execution vendors like Conversen (which I wrote about last month) and ClickSquared (yet another vendor I hope to review shortly). Both sets of products unify a single function that is otherwise spread across multiple systems: offer selection for decision engines and message delivery for execution engines.
The challenges faced by independent decision engines may suggest that the execution engines will face similar problems. But the execution engines sit at the end of the messaging sequence, rather than in its middle: that is, they process outputs from marketing systems and send them elsewhere, rather than feeding them back into the same systems for delivery. This may make it easier for them to survive.
Wednesday, May 28, 2008
Denodo Helps Mesh Enterprise Data
Every now and then you read something along the lines of “more words will be published in the next 30 minutes than in the whole of human history up to the battle of Lepanto”. Whether this is literally true or not (and who could know?), there is certainly more data sloshing around than ever. This is partly because there are so many more transactions, partly because each transaction generates so much more detail, and partly because so much previously hidden data is now exposed on the Internet. The frustration for marketers is that they know this data could be immensely useful, if only they could employ it effectively.
This is the fundamental reason I spend so much time on database technology (to manage all that data), analytics (to make sense of it) and marketing automation (to do something useful with it). Gaining value from data is the greatest new challenge facing marketers today—as opposed to old but still important challenges like managing your brand and understanding your customers. Since the answers are still being discovered, it’s worth lots of attention.
One subject I haven’t explored very often is mining data from the public Internet (as opposed to data captured on your own Web site—the “private” Internet, if you will). Marketers don’t seem terribly concerned with this, apart from specialized efforts to track comments in the press, blogs, social networks and similar forums. Technologists do find the subject quite fascinating, since it offers the intriguing challenge of converting unstructured data into something more useful, preferably using cool semantic technology. It doesn’t hurt that tons of funding is available from government agencies that want to spy on us (for our own protection, of course). The main marketing application of this work has been building business and consumer profiles with information from public Web sources. Zoominfo may be the best known vendor in this field, although there are many others.
But plenty of other interesting work has been going on. I recently spoke with Denodo, which specializes in what are called “enterprise data mashups”. This turns out to be a whole industry (maybe you already knew this—I admit that I need to get out more). See blog posts by Dion Hinchcliffe here and here for more than I’ll ever know about the topic. What seems to distinguish enterprise mashups from the more familiar widget-based Web mashups is that the enterprise versions let developers take data from sources they choose, rather than sources that have already been formatted for use.
Since Denodo is the only mashup software I’ve examined, I can’t compare it with its competitors. But I was quite impressed with what Denodo showed me. Basically their approach is to build specialized connectors, called “wrappers,” that (a) extract specified information from databases, Web sites and unstructured text sources, (b) put it into queryable structure, and (c) publish it to other applications in whatever format is needed. Each of these is easier said than done.
Denodo showed me how it would build a wrapper to access competitive data exposed on a Web site—in this case, mobile phone rate plans. This was a matter of manually accessing the competitor’s site, entering the necessary parameter (a Zip code), and highlighting the result. Denodo recorded this process, read the source code of the underlying Web page, and developed appropriate code to repeat the steps automatically. This code was embedded in a process template that included the rest of the process (restructuring the data and exposing it). According to Denodo, the wrapper can automatically adjust itself if the target Web page changes: this is a major advantage since links might otherwise break constantly. If the Web page changes more than Denodo can handle, it will alert the user.
As I mentioned, Denodo will place the data it retrieves into a queryable format—essentially, an in-memory database table. It could also copy the data into a physical database if desired, although this is an exception. The data can be sorted and otherwise manipulated, and joined with data from other wrappers using normal database queries. Results can be posted back to the original sources or be presented to external systems in pretty much any format or interface: HTML, XML, CSV, ODBC, JDBC, HTTP, Web service, and the rest of the usual alphabet soup. Denodo can join data using inexact as well as exact matches, allowing it to overcome common differences in spelling and format.
The technicians among you may find this terribly exciting, but to most marketers it is pure gobbledygook. What really matters to them is the applications Denodo makes possible. The company cites several major areas, including gathering business and competitive intelligence; merging customer data across systems; and integrating business processes with Web sites.
Some of these applications resemble the integration-enabled interaction management offered by eglue (click here for my post). The difference is Denodo’s greater ability to access external data sources, and what I believe is a significantly more sophisticated approach to data extraction. On the other hand, eglue offers richer features for presenting information to call center agents. It does appear that Denodo significantly lowers the barriers to many kinds of data integration, which should open up all sorts of new possibilities.
The price seems reasonable, given the productivity benefits that Denodo should provide: $27,000 to $150,000 per CPU based on the number of data sources and other application details. An initial application can usually be developed in about two weeks.
Denodo was founded in Spain in 1999. The company has recently expanded outside of Europe and now has nearly 100 customers worldwide.
This is the fundamental reason I spend so much time on database technology (to manage all that data), analytics (to make sense of it) and marketing automation (to do something useful with it). Gaining value from data is the greatest new challenge facing marketers today—as opposed to old but still important challenges like managing your brand and understanding your customers. Since the answers are still being discovered, it’s worth lots of attention.
One subject I haven’t explored very often is mining data from the public Internet (as opposed to data captured on your own Web site—the “private” Internet, if you will). Marketers don’t seem terribly concerned with this, apart from specialized efforts to track comments in the press, blogs, social networks and similar forums. Technologists do find the subject quite fascinating, since it offers the intriguing challenge of converting unstructured data into something more useful, preferably using cool semantic technology. It doesn’t hurt that tons of funding is available from government agencies that want to spy on us (for our own protection, of course). The main marketing application of this work has been building business and consumer profiles with information from public Web sources. Zoominfo may be the best known vendor in this field, although there are many others.
But plenty of other interesting work has been going on. I recently spoke with Denodo, which specializes in what are called “enterprise data mashups”. This turns out to be a whole industry (maybe you already knew this—I admit that I need to get out more). See blog posts by Dion Hinchcliffe here and here for more than I’ll ever know about the topic. What seems to distinguish enterprise mashups from the more familiar widget-based Web mashups is that the enterprise versions let developers take data from sources they choose, rather than sources that have already been formatted for use.
Since Denodo is the only mashup software I’ve examined, I can’t compare it with its competitors. But I was quite impressed with what Denodo showed me. Basically their approach is to build specialized connectors, called “wrappers,” that (a) extract specified information from databases, Web sites and unstructured text sources, (b) put it into queryable structure, and (c) publish it to other applications in whatever format is needed. Each of these is easier said than done.
Denodo showed me how it would build a wrapper to access competitive data exposed on a Web site—in this case, mobile phone rate plans. This was a matter of manually accessing the competitor’s site, entering the necessary parameter (a Zip code), and highlighting the result. Denodo recorded this process, read the source code of the underlying Web page, and developed appropriate code to repeat the steps automatically. This code was embedded in a process template that included the rest of the process (restructuring the data and exposing it). According to Denodo, the wrapper can automatically adjust itself if the target Web page changes: this is a major advantage since links might otherwise break constantly. If the Web page changes more than Denodo can handle, it will alert the user.
As I mentioned, Denodo will place the data it retrieves into a queryable format—essentially, an in-memory database table. It could also copy the data into a physical database if desired, although this is an exception. The data can be sorted and otherwise manipulated, and joined with data from other wrappers using normal database queries. Results can be posted back to the original sources or be presented to external systems in pretty much any format or interface: HTML, XML, CSV, ODBC, JDBC, HTTP, Web service, and the rest of the usual alphabet soup. Denodo can join data using inexact as well as exact matches, allowing it to overcome common differences in spelling and format.
The technicians among you may find this terribly exciting, but to most marketers it is pure gobbledygook. What really matters to them is the applications Denodo makes possible. The company cites several major areas, including gathering business and competitive intelligence; merging customer data across systems; and integrating business processes with Web sites.
Some of these applications resemble the integration-enabled interaction management offered by eglue (click here for my post). The difference is Denodo’s greater ability to access external data sources, and what I believe is a significantly more sophisticated approach to data extraction. On the other hand, eglue offers richer features for presenting information to call center agents. It does appear that Denodo significantly lowers the barriers to many kinds of data integration, which should open up all sorts of new possibilities.
The price seems reasonable, given the productivity benefits that Denodo should provide: $27,000 to $150,000 per CPU based on the number of data sources and other application details. An initial application can usually be developed in about two weeks.
Denodo was founded in Spain in 1999. The company has recently expanded outside of Europe and now has nearly 100 customers worldwide.
Tuesday, March 11, 2008
eglue Links Data to Improve Customer Interactions
Let me tell you a story.
For years, United Parcel Service refused to invest in the tracking systems and other technologies that made Federal Express a preferred carrier for many small package shippers. It wasn’t that the people at UPS were stupid: to the contrary, they had built such incredibly efficient manual systems that they could never see how automated systems would generate enough added value to cover their cost. Then, finally, some studies came out the other way. Overnight, UPS expanded its IT department from 300 people to 3,000 people (these may not be the exact numbers). Today, UPS technology is every bit as good as its rivals’ and the company is more dominant in its industry than ever.
The point of this story—well, one point anyway—is that innovations which look sensible to outsiders often don’t get adopted because they don’t add enough value to an already well-run organization. (I could take this a step further to suggest that once the added value does exceed costs, a “tipping point” is reached and adoption rates will soar. Unfortunately, I haven’t seen this in reality. Nice theory, though.)
This brings us to eglue, which offers “real time interaction management” (my term, not theirs): that is, it helps call center agents, Web sites and other customer-facing systems to offer the right treatment at each point during an interaction. The concept has been around for years and has consistently demonstrated substantial value. But adoption rates have been perplexingly low.
We’ll get back to adoption rates later, although I should probably note right here that eglue has doubled its business for each of the past three years. First, let’s take a closer look at the product itself.
To repeat, the basic function of eglue is making recommendations during real time interactions. Specifically, the system adds this capability to existing applications with a minimum of integration effort. Indeed, being “minimally invasive” (their term) is a major selling point, and does address one of the significant barriers to adopting interaction management systems. Eglue can use standard database queries or Web services calls to capture interaction data. But its special approach is what it calls “GUI monitoring”—reading data from the user interface without any deeper connection to the underlying systems. Back in the day, we used to call this “screen scraping”, although I assume eglue’s approach is much more sophisticated.
As eglue captures information about an on-going interaction, it applies rules and scoring models to decide what to recommend. These rules are set up by business users, taking advantage of data connections prepared in advance by technical staff. This is as it should be: business users should not need IT assistance to make day-to-day rule changes.
On the other hand, a sophisticated business environment involves lots of possible business rules, and business users only have so much time or capacity to understand all the interconnections. Eglue is a bit limited here: unlike some other interaction management systems, it does not automatically generate recommended rules or update its scoring models as data is received.
This may or may not be a weakness. How much automation makes sense is a topic of heated debate among people who care about such things. User-generated rules are more reliable than unsupervised automation, but they also take more effort and can’t react immediately to changes in customer behavior. I personally feel eglue’s heavy reliance on rules is a disadvantage, though a minor one. eglue does provide a number of prebuilt applications for specific tasks, so clients need not build their own rules from scratch.
What impressed me more about eglue was that its rules can take into account not only the customer’s own behavior, both during and before the interaction, but also the local context (e.g., the current workload and wait times at the call center) and the individual agent on the other end of the phone. Thus, agents with a history of doing well at selling a particular product are provided more recommendations for that product. Or the system could restrict recommendations for complex products to experienced agents who are capable of handling them. eglue rules can also alert supervisors about relationships between agents and interactions. For example, it might tell a supervisor when a high value customer is talking to an inexperienced agent, so she can listen and intervene if necessary.
The interface for presenting the recommendations is also quite appealing. Recommendations appear as pop-ups on the user’s screen, which makes them stand out nicely. More important, they provide a useful range of information: the recommendation itself, selling points (which can be tailored to the customer and agent), a mechanism to capture feedback (was the recommended offer presented to the customer? Did she accept or reject it?), and links to additional information such as product features. There is an option to copy information into another application—for example, saving the effort to type a customer’s name or account information into an order processing system. As anyone who has had to repeat their phone number three times during the course of a simple transaction can attest—and that would be all of us—that feature alone is worth the price of admission. The pop-up can also show the business rule that triggered a recommendation and the data that rule is using.
As each interaction progresses, eglue automatically captures information about the offers it has recommended and customer response. This information can be used in reports, applied to model development, and added to customer profiles to guide future recommendations. It can also be fed back into other corporate systems.
The price for all this is not insignificant. Eglue costs about $1,000 to $1,200 per seat, depending on the details. However, this is probably in line with competitors like Chordiant, Pegasystems, and Portrait Software. eglue targets call centers with 250 to 300 seats; indeed, its 30+ clients are all Fortune 1000 firms. Its largest installation has 20,000 seats. The company’s “GUI monitoring” approach to integration and prebuilt applications allow it to complete an implementation in a relatively speedy 8 to 12 weeks.
This brings us back, in admittedly roundabout fashion, to the original question: why don’t more companies use this technology? The benefits are well documented—one eglue case study showed a 27% increase in revenue per call at Key Bank, and every other vendor has similar stories. The cost is reasonable and implementation gets easier all the time. But although eglue and its competitors have survived and grown on a small scale, this class of software is still far from ubiquitous.
My usual theory is lack of interest by call center managers: they don’t see revenue generation as their first priority, even though they may be expected to do some of it. But eglue and its competitors can be used for training, compliance and other applications that are closer to a call center manager’s heart. There is always the issue of data integration, but that keeps getting easier as newer technologies are deployed, and it doesn’t take much data to generate effective recommendations. Another theory, echoing the UPS story, is that existing call center applications have enough built-in capabilities to make investment in a specialized recommendation system uneconomic. I’m guessing that answer may be the right one.
But I’ll leave the last word to Hovav Lapidot, eglue’s Vice President of Product Marketing and a six-year company veteran. His explanation was that the move to overseas outsourced call centers over the past decade reflected a narrow focus on cost reduction. Neither the corporate managers doing the outsourcing nor the vendors competing on price were willing to pay more for the revenue-generation capabilities of interaction management systems. But Lapidot says this has been changing: some companies are bringing work back from overseas in the face of customer unhappiness, and managers are showing more interest in the potential value of inbound interactions.
The ultimate impact of interaction management software is to create a better experience for customers like you and me. So let’s all hope he’s right.
For years, United Parcel Service refused to invest in the tracking systems and other technologies that made Federal Express a preferred carrier for many small package shippers. It wasn’t that the people at UPS were stupid: to the contrary, they had built such incredibly efficient manual systems that they could never see how automated systems would generate enough added value to cover their cost. Then, finally, some studies came out the other way. Overnight, UPS expanded its IT department from 300 people to 3,000 people (these may not be the exact numbers). Today, UPS technology is every bit as good as its rivals’ and the company is more dominant in its industry than ever.
The point of this story—well, one point anyway—is that innovations which look sensible to outsiders often don’t get adopted because they don’t add enough value to an already well-run organization. (I could take this a step further to suggest that once the added value does exceed costs, a “tipping point” is reached and adoption rates will soar. Unfortunately, I haven’t seen this in reality. Nice theory, though.)
This brings us to eglue, which offers “real time interaction management” (my term, not theirs): that is, it helps call center agents, Web sites and other customer-facing systems to offer the right treatment at each point during an interaction. The concept has been around for years and has consistently demonstrated substantial value. But adoption rates have been perplexingly low.
We’ll get back to adoption rates later, although I should probably note right here that eglue has doubled its business for each of the past three years. First, let’s take a closer look at the product itself.
To repeat, the basic function of eglue is making recommendations during real time interactions. Specifically, the system adds this capability to existing applications with a minimum of integration effort. Indeed, being “minimally invasive” (their term) is a major selling point, and does address one of the significant barriers to adopting interaction management systems. Eglue can use standard database queries or Web services calls to capture interaction data. But its special approach is what it calls “GUI monitoring”—reading data from the user interface without any deeper connection to the underlying systems. Back in the day, we used to call this “screen scraping”, although I assume eglue’s approach is much more sophisticated.
As eglue captures information about an on-going interaction, it applies rules and scoring models to decide what to recommend. These rules are set up by business users, taking advantage of data connections prepared in advance by technical staff. This is as it should be: business users should not need IT assistance to make day-to-day rule changes.
On the other hand, a sophisticated business environment involves lots of possible business rules, and business users only have so much time or capacity to understand all the interconnections. Eglue is a bit limited here: unlike some other interaction management systems, it does not automatically generate recommended rules or update its scoring models as data is received.
This may or may not be a weakness. How much automation makes sense is a topic of heated debate among people who care about such things. User-generated rules are more reliable than unsupervised automation, but they also take more effort and can’t react immediately to changes in customer behavior. I personally feel eglue’s heavy reliance on rules is a disadvantage, though a minor one. eglue does provide a number of prebuilt applications for specific tasks, so clients need not build their own rules from scratch.
What impressed me more about eglue was that its rules can take into account not only the customer’s own behavior, both during and before the interaction, but also the local context (e.g., the current workload and wait times at the call center) and the individual agent on the other end of the phone. Thus, agents with a history of doing well at selling a particular product are provided more recommendations for that product. Or the system could restrict recommendations for complex products to experienced agents who are capable of handling them. eglue rules can also alert supervisors about relationships between agents and interactions. For example, it might tell a supervisor when a high value customer is talking to an inexperienced agent, so she can listen and intervene if necessary.
The interface for presenting the recommendations is also quite appealing. Recommendations appear as pop-ups on the user’s screen, which makes them stand out nicely. More important, they provide a useful range of information: the recommendation itself, selling points (which can be tailored to the customer and agent), a mechanism to capture feedback (was the recommended offer presented to the customer? Did she accept or reject it?), and links to additional information such as product features. There is an option to copy information into another application—for example, saving the effort to type a customer’s name or account information into an order processing system. As anyone who has had to repeat their phone number three times during the course of a simple transaction can attest—and that would be all of us—that feature alone is worth the price of admission. The pop-up can also show the business rule that triggered a recommendation and the data that rule is using.
As each interaction progresses, eglue automatically captures information about the offers it has recommended and customer response. This information can be used in reports, applied to model development, and added to customer profiles to guide future recommendations. It can also be fed back into other corporate systems.
The price for all this is not insignificant. Eglue costs about $1,000 to $1,200 per seat, depending on the details. However, this is probably in line with competitors like Chordiant, Pegasystems, and Portrait Software. eglue targets call centers with 250 to 300 seats; indeed, its 30+ clients are all Fortune 1000 firms. Its largest installation has 20,000 seats. The company’s “GUI monitoring” approach to integration and prebuilt applications allow it to complete an implementation in a relatively speedy 8 to 12 weeks.
This brings us back, in admittedly roundabout fashion, to the original question: why don’t more companies use this technology? The benefits are well documented—one eglue case study showed a 27% increase in revenue per call at Key Bank, and every other vendor has similar stories. The cost is reasonable and implementation gets easier all the time. But although eglue and its competitors have survived and grown on a small scale, this class of software is still far from ubiquitous.
My usual theory is lack of interest by call center managers: they don’t see revenue generation as their first priority, even though they may be expected to do some of it. But eglue and its competitors can be used for training, compliance and other applications that are closer to a call center manager’s heart. There is always the issue of data integration, but that keeps getting easier as newer technologies are deployed, and it doesn’t take much data to generate effective recommendations. Another theory, echoing the UPS story, is that existing call center applications have enough built-in capabilities to make investment in a specialized recommendation system uneconomic. I’m guessing that answer may be the right one.
But I’ll leave the last word to Hovav Lapidot, eglue’s Vice President of Product Marketing and a six-year company veteran. His explanation was that the move to overseas outsourced call centers over the past decade reflected a narrow focus on cost reduction. Neither the corporate managers doing the outsourcing nor the vendors competing on price were willing to pay more for the revenue-generation capabilities of interaction management systems. But Lapidot says this has been changing: some companies are bringing work back from overseas in the face of customer unhappiness, and managers are showing more interest in the potential value of inbound interactions.
The ultimate impact of interaction management software is to create a better experience for customers like you and me. So let’s all hope he’s right.
Subscribe to:
Posts (Atom)
