The Online Insurance Puzzle
When thinking about online insurance systems many people fall in the trap of believing they can start with an existing product, add a web interface to an automated underwriting system, and they have an online solution. Maybe this is an over-simplification, but this is often the basic premise. The result is more likely to be an expensive project that delivers little in the way of sales or useful experience.
Let’s consider the business changes needed to successfully ‘go online’…
Product
The core of what I will say about product is also true about other components, that is, you can’t simply take something that has been designed for a manual process and expect it to deliver results in an online environment. Product features once developed to help sales agents differentiate their products now only serve to confuse online customers. Online customers need simple to understand products; features such as renewability introduce a solution to a problem that customers had never thought of.
Underwriting Engine
Traditionally automated underwriting engines were developed to support underwriters, as such data input is not optimized for online input. Part of the problem lies in the design of the underwriting rules which is discussed below; related to this is the need to have structured responses with all the information available. Online systems need to take questions one step at a time in order to solicit the information needed from the customer. Systems adapted from traditional automated underwriting engines typically result in a combination of limiting the underwriting functionality that can be presented and duplicating underwriting rules in the interface so the required information can be collected.
Just like with product, an automated underwriting engine developed specifically for an online process needs to be developed with the customer in mind. This means asking a question and then based on the response to the question, making a question level decision — this decision may be to move on with the next step in the process, to ask another new question, or to apply any number of underwriting outcomes such as loadings, exclusions, deferral or decline. We refer the process of generating a new question based on the prior question reflexive questioning.
In addition to question level logic, rules need to exist for the responses as a whole (combinational logic) and integrate third-party data into the decision, not simply use the third-party data to refer to a manual decision as many systems do with MIB.
Finally, and often overlooked, is the need to manage rules as they are developed and modified over time. A system designed to be a manual assistant relies on the underwriter to be the final arbitrator, an online automated decision system must accommodate changing rules without missing a beat.
Underwriting Rules
The underwriting rules are integral with the rules engine as the rules are obviously limited by the functionality of the underwriting engine. However, and more important, when developing underwriting rules for an online customer you need to be able to focus on the customer experience — will they find it easy to answer the questions, are they clear and easily understood, does the order make sense, can they result in confusion on the part of the customer, and are they detailed enough to provide full disclosure? Many systems adapted from a manual process fail in this regard — medical terms confuse customers, the way the questions are structured result in duplicated disclosures.
Another feature of an online automated decision is that the rules need to handle disclosure of trivial conditions that a sales agent would know not to include, or an underwriter would simply ignore. This vastly expands the rule logic needed, but the last thing you want is an online process to fail due to the attempted disclosure of something trivial such as a doctor visit for flu or a bad cold, that is not accommodated and therefore entered by the customer as “other condition”.
Customer Journey
In addition to collecting responses to underwriting questions, the applicant needs to be guided through the purchase process. This starts by selecting a product to buy — can you select based on affordability? Integrated needs analysis? As the client gets further into the process, they need to be guided through options, changes they may choose, be presented with cross-sell options, confirm the application, and choose between loadings and exclusions.
The considerations above are logical issues, there is also the physical issue of implementing and maintaining the customer journey. Making it clear and easy to understand, enabling the customer to pause and come back to the process and finally deliver the policy document, these all have to be developed and maintained. These should also be easily modified as you gain experience.
Back Office Support
Back office support — this is more than just an underwriting workbench to allow underwriters handle cases that require additional evidence. Back office needs processes that differentiate between roles such as customer support, tele-underwriters and underwriters; processes to follow up on abandoned applications, collect payments and deliver policy documents. There are also functions to set up and manage the system; the most significant is security and processes around application handling.
Analytics
Analytics starts with data, data collected in the application process is extremely personal, before analytics is considered the challenges around holding this data needs to be addressed. Data should include the information collected through the process, and data about the process such as changes to answers and how long the application takes, and any additional data available from the applicant’s internet profile, such as location.
Conclusion
The old adage “a chain is only as strong as its weakest link” is very true here; the six components described above need to fit together seamlessly. Taking an existing solution designed for a manual process and building around it results in needing to find solutions to problems that should not exist, and spending time on minor issues that are discovered during the process.
We see a continuous iterative process across all areas with purpose-built components as the solution. The first iteration needs to start from a complete online solution; simply put — think top-down rather than bottom-up, customize and iterate.
