I got a chance to get an overview of the latest release of Oracle Real-Time Decisions, 3.0. This is the platform for real-time decisions on which various applications (for call center, web etc) are built and sold as part of the Oracle Applications suite.
The vision of this product is to optimize “return on attention” – how do I know that I have leveraged the time/attention a customer gives me in an optimal fashion? Do they pay attention to the information and offers I put in front of them? Most companies have a lot of content and, for inbound inquiries at least, have their customers’ attention. But they must understand intention to build an effective, personalized, interaction. Example results included a 5% increase in transaction amounts (revenue) online, 500% reduction in A/B test cycle time in marketing and a 40% increase in customer retention.
Interaction optimization involves recommending the best action. Most current systems are split between analytical and operational while the act of optimizing interactions requires a combination. In addition most processes are not instrumented in a way that supports optimization. RTD Decision Services fit between analytical and operational systems to turn this into continuous process optimization – learn-act-learn. RTD is designed to handle this for millions of interactions and hundreds of different messages/contexts.
RTD decouples Decision Services from the business process execution layer in classic Decision Management style. It delivers these services using rules, analytics and performance goals (of which more later). Starting with the decision, users state the goal, decide how to achieve it and then measure and improve. Oracle sees Business Intelligence and RTD as well as BPM and MDM wrapped around the core applications. These capabilities are delivered across call center, self-service, e-commerce, SFA or Field Service. All these applications are potential users of RTD while the RTD platform works across all of them.
RTD has the platform and then a layer of base applications and then a specialized application E.g. RTD platform, RTD base application (contains use cases) then applied in the context of, for instance, Siebel CRM call center application (retention and cross-sell), Oracle Web Content Management or Siebel Ecommerce. Lots of the work on the platform is to make it easy to integrate with existing technology/workflow e.g. in different website management technologies. They have a strong focus on composite Decision Services – Decision Services that are designed for use in Composite Applications.
The basic process works like this. For each decision the user must express the performance goals that determine good v bad decisions. Choices, rules and models are also defined and then recommendations made to maximize the performance goals (often in a channel specific way). The user specifies a scoring formula for each metric that can then be calculated for each available choice. This could be arbitrary and specified by the business or be a complex, derived formula or any combination. These formulas can use what RTD knows (such as the ongoing likelihood of acceptance), existing predictive models or explicit rules. Many pre-defined measures are available. For each decision, the user can how they are going to weight the goals for a decision in a each segment of their population. There is a very flexible definition for a segment – could be Monday morning for instance- and the user can change the weights instantly e.g. to meet an SLA or a customer retention target that looks at risk. All this gives RTD a powerful, if implicit, link to corporate performance objectives.
The decisions themselves use real time context and historical data. Context is really important for these decisions and real-time context is very complex with lots of factors to capture and consider. This context can be hard to handle using offline analysis or by specifying rules so the RTD folks feel that dynamically building and refining models is the best way to apply it. RTD builds a model based on what seems to predict the desired behavior no matter what it is. All this automated data mining is key to the product. Besides supporting automated versions of the usual data mining techniques, the product handles time windows (that are overlapped) so that models recycle, supports seasonality, partitioning, definition of buckets etc. As usual with automated model development/tuning there is not much incentive to keep the number of predictors down and RTD brings in whatever predictors it finds useful. RTD manages the performance issue by having a separate deployed model. Updates happen when there is a reason (statistical) or time based (say every minute). By reducing the time/cost to develop or adapt a model to nearly zero, RTD can use many hundreds or thousands of models.
Rules are combined with these models to make decisions. Rules are defined either as eligibility rules or as targeting rules. Business users can specify the conditions for eligibility for a given offer. This can include all of the following conditions/any of the following conditions and can be quite detailed and extensive. Conditions can access any of the data elements that are defined. The UI for defining these rules can be embedded in another application (such as one where content, offers or products are defined). Meanwhile the targeting rules generate a score with each offer getting a total score from all the rules that execute. These rules represent an additive scorecard specified by hand or based on an external model.
Release 3.0 has added support for batch decisions, enhanced rule expressivity and active model quality management (so you can control the process of model selection while it learns). They also added noise reduction (to avoid self-fulfilling prophecies in models for instance) and model quality reports. The big trend in 3.0 is the move to composite decisions. This is in part about making it componentized – offers, content defined in different places and integrated into RTD rather than everything being “owned” by RTD. For instance, offers are often managed as part of campaigns in a campaign management system while banner ads are defined in a content management system. Exposing everything (content, campaigns, cases, service requests, promotions, products) to the RTD engine allows it to use it all. These “suppliers” might specify business rules and models too – specifying the eligibility of particular users for a particular offer, for instance. These rules and models are also applied by RTD which acts as a arbitrator across the various sources of information. This allows for centralized Decision Management while allowing decentralized content and rule ownership. For instance, when new banners are defined in a content management system you want RTD to immediately start to learn when the banner ad is effective. This requires the execution engine to pick up the new content. The designer must also be able to define rules for these banners (defining when they can be displayed) and this can increasingly be done using an extension of the RTD environment into the specific environment where the content is being created.
Oracle has a number of decisioning technologies including RTD, business rules and Oracle Data Mining. RTD can call ODM models and its Decision Services, like those based on the business rules product, can be called from within the BPEL process environment. The rules are separate between RTD and the rules product, however.
Ecommerce is a focus area for RTD – in some ways back to the team’s original focus and a change from the days when the product was originally OEMed by Siebel. They see a move from a call center focus to the web. Examples include cross-selling, guided selling, proactive retention. Three case examples illustrate the power of RTD:
- Displacement Selling
A company whose business is 70% online and where the web is the primary channel. With a fairly complex product they wanted to personalize and target more precisely. Prior to RTD they had used simple rules for based on application data. With RTD they collect the information across 60 attributes and RTD then figures if a prospect is looking for a cheaper replacement product, an equivalent product or a more feature-rich product and uses this as part of the promotion/selling process. They claim dramatic results in terms of profit, sales etc. - Guided-selling
Big Telco using RTD in selling to SMB. This was implemented by Accenture (who have a business focused on guided selling that targets customer acquisition, optimizing messages and establishing a closed loop process). The resulting application helps SMBs navigate the catalog of offerings and then see what fits their needs. The Telco use it to generate leads for these products. Ordering of offerings and the list of offerings change to optimize response. - Proactive Retention
A financial products/service company has been moving to proactive retention. Because customers think of this company as a place to save for retirement they often moved away when they retired. The company has lots of models to predict risk of customer churn but were not getting the results they wanted by using these in reactive situations (when someone calls in for example). Moved to be more proactive by identifying retention risk “sensors” that identified at risk people (often using offline information in combination with online behavior). RTD then presents retention-focused information and triggers proactive outbound retention calls. RTD delivers the information and supports the call center. This uses lots of data (200 attributes) from the website and the back office data as well as offline developed models and rules based on their own analysis/models.
RTD is a complete decisioning environment, combining business rules, analytics, adaptive control and decision analysis. Although not a general purpose platform I was impressed by the range of functionality it offers. I hope to see Oracle bring its in-database data mining, RTD and general purpose rules products together over time.
Comments on this entry are closed.
Excellent piece..
How would a Oracle RTD and a business rules engine co-exist ? Can you please comment