Some weeks back I wrote a series of posts on the role of Decision Management in Insurance. One post was called multi-channel distribution and customer communication and outlined how Decision Services that automate customer decisions improve customer treatment in a multi-channel world by improving their accuracy, timeliness and consistency.
The diagram at left shows how this looks – various channel-specific applications exist and support our business. We use Decision Discovery to identify the Decisions that support these applications – the questions to which they need answers in order to execute our processes. We then construct Decision Services using a mix of business rules and predictive analytics. These automated Decision Services can be used by any application that needs a decision made. Finally, because decisions are not static we implement an ongoing process of Decision Analysis to use data from our business systems to continually refine our decision making approach.
I got a comment on the post asking for a worked example to clarify it so here goes. Let’s take the underwriting decision – an important decision for both the company and the customer. I am not going to try and build a definition model of the underwriting decision but we could break out a number of element – sub decisions – that must be answered if we are to answer the question “How should we underwrite this decision?”:
- risk characterisation (what are the risks to be covered?)
- product availability (what products do we have which would cover the risks?)
- product eligibility (what products is the customer eligible for?)
- exclusions (what exclusions should be quoted?)
- pricing (what premium should we charge for the policy?)
- risk (can we accept the risk?)
- referrals (should this application be reviewed by an underwriter?).
These are shown on the decision dependency diagram below.
This kind of diagram (based on work by Alan Fish and described on his blog) not only shows how the various sub-decisions relate, it also shows the various sources of information and know-how that are needed to make these decisions. Building out a dependency network like this is the first stage in designing a decision. The example is neither complete nor definitive, just an example (thanks to Alan for his input).
As we move into designing Decision Services we will clearly want to expose the main underwriting decision as a service. This service might only be used by a couple of systems – our call center application and the application we provide to our independent agents. When we look at the lower-level decisions, however, we might realize that it would be useful to potential customers to expose the product eligibility decision service through our website – it probably does not need as much applicant data as the underwriting decision and it might help customers find the right product quickly, even if we choose not to expose automated underwriting on the web. As we detailed out this design we could easily find other sub-decisions and decide that different systems or channels need access to some of them.
The final step will be to ensure that we improve underwriting over time. We will manage our policy rules using a business rules management system or BRMS to ensure we can change them rapidly and accurately when states change their regulations or when we launch new products. We will capture data about the prices offered and our acceptance rate at that price in various channels. We will track claims against these policies to see how accurately we assessed risk and so on. All this information will feed back into the decision analysis process to improve our decision making steadily and continuously.
Thanks again to Dana for the comment. Hopefully this made things clearer. Thanks also to Alan Fish for his help with the decomposition.
