Triggers in a data driven world

To begin talking about and understand triggers in a data-driven world one needs to think about an entire strategy including models, data variables, business rules and segment based outcomes as a trigger. In fact, what makes it a trigger is more how it is used then the type of data that it processes. A trigger can and often should contain all the complexity (models, rules, data transformations, etc...) as full blown campaigns. The key is that triggers are executed frequently: whenever data changes and/or there is an opportunity to take the right data-driven action. For a company like Intelligent Results whose production engine can easily be called in real-time or batch this isn't a big deal; however, for many organizations that use scores/models and decision trees today this is difficult because they have to recode those models and decision rules into other operational systems to make them work. So once you think of the entire decision tree with all its scores, variables and actions as a trigger you can imagine that any type or types of data and analysis could go into the trigger. For example, a trigger might in fact be statistically based, like a score with cut points, or might be based on the occurrence of a words or concept in a call center conversation. What's more a trigger can also involve multiple elements like a cross-sell offer trigger which initiates an offer if the transaction value of the current shopping cart is >25% over the 6 month average or the predictive model score, p(acceptance), for the optimal product is 35%, or the customer record in the past contains the concept of "moving or relocation." In that example, text, temporal roll-ups, transformations (feature math) and predictive models would all have to interact to fire a "trigger" and initiate the Action. Triggers are an awesome concept for Intelligent Results and we should never miss an opportunity to bring them into the conversation. They are hot in the industry right now and they rely on several concepts that we've long supported:

• Execute Often - and we really mean score, evaluate and decision often. Triggers are often used in real-time or fast batches and we believe this is important because you want to be able to react as soon as the information changes or as soon as the customer gives you an opening.




• Use Scores and Decisions - Triggers are more than scores and data. Triggers may require scores and data which we provide, but they also require decisions, cut-points, thresholds and actions. Only PREDIGY gives customers the ability to do all that in one system.




• Use All Your Data - Powerful Triggers can be based on all types of data, used independently and in combination. From unstructured text and sequence data to data comparisons (transformation in feature math) and statistical models PREDIGY allows users to use and combine all types of data into simple and complex business rules and triggers.




• Rapid Production - Triggers are more valuable when they can be quickly designed, simulated, implemented and executed. PREDIGY makes all that fast and reliable. The PREDIGY application factory concept integrates and streamlines each of these steps. And of course with the IR Production Engine your Triggers can be easily integrated, deployed and distributed across multiple operational systems and client interaction channels.




• Track Everything - the PREDIGY platform does that.

Below I've added 2 examples of Triggers that a banking call center customer might use.

The first, is an example of a skills based routing trigger used by a credit card company to route inbound emails about AOL Billing issues to specialized agents. Without going into to much detail on why this is necessary (that's a whole other posting on discovering attrition drivers) you can see that if the email is about AOL charges then the customer is to be routed to a special queue. This is a very simple text based trigger that could be executed by the IR Production Engine against emails, call center call, web forums, etc... The IR Production Engine makes it possible for a bank to run this strategy in real-time or in batch.

The second example is a bit more complex. It's designed to allow call center agents to constantly, profitably and quickly respond to customer's rate adjustment requests or to proactively offer rate adjustments to particularly valuable segments. The first decision element looks at a customer's current interest rate and compares it to the rate they could get from industry competitors. If the delta is within 2 points no action is taken. If the delta is 2 points or greater then the value of the customer is assessed. If they are not a high spender then the account must be sent for additional review (in fact the entire rate management strategy behind this additional review could also be run in real-time if the bank wanted to but that's a different posting). If the customer is a high spender then the call center agent is empowered to make an immediate rate adjustment. This simple, real-time data-driven strategy improves customer satisfaction, regulatory compliance and profitability.