Integrating Chatbots, Policy-Handling Apps

Insurers can leverage chatbots to improve a number of customer journeys, including operational processes such as claims first notification of loss, and processes related to the purchasing of insurance products, such as quote and buy. This article covers recommendations related to the latter, specifically focusing on best practices in integrating chatbots with insurance policy-handling applications. Two initial considerations may be relevant. First, will the chatbot journey be a sub-journey within a channel, or a net new channel? Sub-journey within a channel: If the entrance point to the chatbot conversation is contained within the insurance platform’s front end, existing for example as a button on a web page, then the chatbot solution may not attract extra traffic and will effectively be a sub-journey contained within an existing channel. Net new channel: If the entrance point to the chatbot conversation is outside of an existing channel, for example via Facebook, then the chatbot may generate new traffic, potentially adding significant value. Second, will the chatbot journey replicate an existing journey, or will it be a net new journey? Replicate an existing journey: The chatbot asks the same questions in the same order as they are asked in the journey being replicated. For example, if the journey being replicated is quote, then the chatbot asks the same questions as the quote web journey in the same order. Net new journey: The chatbot asks questions different from those asked in other journeys, or asks the same questions in a different order. For example, a quote-and-buy chatbot may be built to ask different questions or use a different tone of voice depending on responses input by the customer, such as age or location. This provides a customer experience that is truly different from that of other channels, potentially engaging different audiences. Beyond the initial considerations, it is important to analyze in depth the architecture of the platform into which the chatbot solution is to be integrated. Key areas to cover:

• Insurance policy-handling application: What data does the policy system expect at the end of the chatbot journey? For example, if the chatbot replicates a quote journey, what data does the policy system require from the chatbot to convert the quote into a policy?
• Integration layer: Is the existing integration solution fit for purpose, or should a new solution be defined addressing how to pass data between the chatbot, the policy-handling application and any relevant near and downstream applications?
• Management information (MI) solution: Does the policy handling platform have an MI solution, and is it feasible to use that MI solution to gather data relevant to the chatbot conversation? For example, a platform may have an MI solution, but a decision may be made to use the analytics produced off the back of the chatbot to gain a more granular view of the conversation.
• Billing application: Are there integrations between the core policy system and the core billing system that could affect the chatbot solution? For example, if the chatbot conversation collects data that needs to land in the billing system, the format in which the data is collected must comply with the billing data model.
• Near-stream/downstream applications: Are there applications that consume data from the core policy system that could affect the chatbot implementation? For example, there may be a documentation system that the chatbot needs to integrate into.

See also: Chatbots and the Future of Insurance   After the architectural issues, consider the overall response times of the chatbot, which have a significant impact on the user experience. Key points:

• One question at a time – the implications: Whereas in web journeys customers can see a number of questions at the same time, and as such have something to read and engage with if the response to their inputs is slow, with a chatbot questions are presented one at a time. The outcome is that when a customer is engaging with a chatbot, and the chatbot response is delayed, the customer can do nothing but wait, which may lead to a poor customer experience.
• Minimizing chatbot response times: An approach to minimizing response times is to build a skeleton proof of concept (POC), then test response times using the POC. A second approach is to perform performance profiling, where speculative analysis is done upfront to model how long each transaction will take. For example, knowing that a rating call made from the policy handling application takes circa one second, it can be estimated that the same called made from the chatbot will take circa one second, too. The combination of early modeling and POC should avoid the situation whereby performance issues are baked into the chatbot solution through architectural decisions that are hard to reverse.

Analysis should be done on the look and feel of the chatbot. The two main options are to have the chatbot conversation align with the look and feel of the other customer-facing journeys, or give the chatbot a look and feel distinct from all other journeys. A key disadvantage of the latter approach is that customers, not recognizing the look and feel of the chatbot, may think they landed on the wrong website or, even worse, on a phishing platform. Points that should be considered are:

• Location in journey: If the platform’s front end indicates to users where they are in the journey, for example highlighting that a user has answered nine of the 12 questions required for a quote, does the chatbot do the same?
• Forward and backward navigation: Is it possible to navigate forward and backward in the chatbot conversation? For example, a chatbot conversation could be built so that questions A, B, C can only be asked once and in order, or could be build so that the customer can navigate both from A to B to C and from C to B to A. If the second, then care should be taken to ensure that answering again previously answered questions does not cause issues with near-stream and downstream application.
• Multi-device look and feel: Is the chatbot look and feel consistent across devices? For example, a chatbot that is built to replicate the look and feel of the underlying policy-handling application will need to maintain that consistent look across web, mobile and other customer devices.

Once deployed, a chatbot coupled with a feedback-gathering and -reporting framework can help uncover insights about customer journeys. For example, web forms do not analyze what the user is doing between when the web page is loaded and the click on the submit button, but chatbots do. Chatbots can help uncover:

• Conversion rates per question, allowing local optimization.
• Net Promoter Score (NPS) for the insurance brand delivering the product.

Each optimization derived from the learning may not be significant on its own, but the sum of all optimizations can lead to significant improvements for the overall journey. Furthermore, because, on average, chatbots can be improved once a month, the result is a learning curve with a faster acceleration than traditional web forms. See also: Chatbots and the Future of Interaction   Key Takeaways:

• Defining whether the chatbot conversation will be a new channel and whether it will replicate an existing journey helps in defining the overall chatbot use case.
• It is good practice to analyze in detail the application architecture into which the chatbot is being implemented, focusing in particular on the core insurance policy application, integration layer, MI solution, billing application and near-stream/downstream applications.
• The time it takes for the chatbot to respond to user inputs is particularly important, as chatbot journeys display one question at a time.
• It is helpful to define upfront whether the look and feel of the chatbot conversation will mimic the look and feel of the other customer-facing channels.
• An implemented chatbot can be used to uncover insights about customer journeys, especially with regard to conversion rates and NPS scores.