Build conversational experiences for auto insurance using Amazon Lex

Auto insurance companies are focusing on digital innovations to meet customer needs. Digital-first engagements provide tailored coverage, transparent information, and seamless experiences. The shift to virtual channels for customer service that occurred during the pandemic is unlikely to revert to traditional channels for many customers. The change in consumer behavior continues to accelerate due to a growing population of tech-savvy customers who want to interact with businesses online. Throughout the lifecycle, customers expect a quick turnaround as they evaluate policy options (pre-purchase), make a premium payment (purchase), or report a claim (post-purchase). A faster and personalized service improves policy holder satisfaction and allows insurance agents to focus on building deeper relationships.

In this post, we review how you can use a pre-built solution with Amazon Lex to enable rich, customized interactions so insurers can provide faster handling of payments processing, claims reports, policy updates, and policy quotes.

Solution overview

Amazon Lex provides the advanced deep learning functionalities of automatic speech recognition (ASR) for converting speech to text, and natural language understanding (NLU) to recognize the intent of the text, to enable you to build applications with highly engaging user experiences and lifelike conversational interactions. Amazon Lex for Insurance offers pre-built solutions so you can enable more conversational experiences, faster. The pre-built bots are configured with intents, sample utterances, and slot types for credit card use cases and are integrated with Amazon Connect contact flows.

Let’s review a sample conversation regarding a policy quote as we cover the different components of the pre-built solution:

Agent: Welcome to ABC insurance. How can I help you today?

Caller: I want to get a new policy quote

Agent: Great. I can assist you with that. What kind of policy are you calling about? Auto, or Home?

Caller: Auto

Agent: Ok. I will need some information about you in order to serve you the best. First, please say your date of birth, including the year.

Caller: January 1, 2001

Agent: Ok. What is your first name?

Caller: Joe

Agent: And your last name?

Caller: Smith

Agent: Ok, please say or enter your 10-digit phone number.

Caller: 1234567890

Agent: Ok. Say or enter the 5-digit zip code where you would like to insure your vehicle.

Caller: 1234

Agent: Tell me the make of the vehicle.

Caller: Ford

Agent: And what is the model?

Caller: Focus

Agent: And year?

Caller: 2020

Agent: Ok. What is the expected annual mileage?

Caller: 10000 miles

Agent: Thank you for providing the details. Just a second while I pull up the quote …

Agent: Based on the zip code, mileage, and other vehicle details, we can do $125 per month or $1200 annual billing.

Caller: Thank you!

In the preceding sample conversation, the agent first collects basic information (insurance type, date of birth, name, and phone number). The agent engages to complete the user request (policy quote) by starting a dialog to collect additional information (zip code and vehicle details such as make, model, year, and mileage). Lastly, the agent performs the task (registering a follow-up) and provides a response. The pre-built solution includes bots for auto insurance services that can be deployed on Amazon Lex to automate the conversations.

The AutoInsuranceBot contains intents for common policy holder activities such as getting policy quotes, making premium payments, making a claim, finding an advisor, adding or removing a driver, and adding or removing a vehicle. It includes the following intents:

GetPolicyQuote – This intent collects caller contact details and information related to the vehicle such as make, model, year, and annual mileage to process the policy quotation
MakePremiumPayment – The intent collects information such as the payment amount, source account ID, and date, and processes the payment
PaymentByCard – The intent gathers credit card information from the user to make a payment toward a policy
MakeAClaim – The intent collects information related to the incident and raises a claim
FindAnAdvisor – The intent suggests an insurance agent, based on the location and product category
AddDriver – The intent adds a driver to the existing policy by collecting the driver details
AddVehicle – The intent adds a vehicle to the existing policy with the necessary details such as make, model, and VIN
MakeModelYear – A follow-up intent to AddVehicle and MakeAClaim intents
EndConversation – An intent to end the conversation on caller inputs such as “Bye” and “I am done”
Fallback – The intent is invoked when the input doesn’t match any of the configured intents

The bot definition includes a complete dialog along with the prompts to manage the conversation. Each bot also integrates with an AWS Lambda function that contains code to simulate business logic execution; integration with Amazon Kendra provides the ability to answer natural language questions during the conversation.

Solution architecture

Let’s review the overall architecture for the solution (see the following diagram):

We use an Amazon Lex bot to first authenticate the caller by verifying information that is stored in a secure database.
We use Lambda to simulate access to backend systems and perform the authentication function. For the purposes of this post, the insurance policy data used for authentication is stored in an Amazon DynamoDB
After the caller is authenticated, the control is passed to the main insurance bot to perform transactions (for example, make a payment) or provide the caller with requested information (for example, “What good driver discounts do you provide?”). We use Lambda to run business logic required for running transactions.
To answer any user questions, we configure an Amazon Kendra search index so the bot can look up the information and provide a response.
You can deploy the conversational experience on an Amazon Connect instance or integrate with your website.

We include a template that creates an AWS CloudFormation stack containing all these AWS resources, as well as the required AWS Identity and Access Management (IAM) roles. With these resources in place, you can use the pre-built solution for auto insurance on the Amazon Connect channel.

Prerequisites

You should have the following prerequisites before we deploy the solution:

An AWS account
Access to the following AWS services:
- Amazon Lex to create bots
- Lambda for the business logic functions
- DynamoDB to create the tables
- IAM with access to create policies and roles
- AWS CloudFormation to run the stack
IAM access and secret key credentials
Optionally, an existing Amazon Connect instance (if you plan to deploy on Amazon Connect)

Deploy the pre-built solution

To deploy this solution, complete the following steps:

Choose Launch Stack to launch a CloudFormation stack in the Region of your choice:

For Stack name, enter a name for your stack. This post uses the name auto-insurance-solution.

In the Parameters section, enter values for the for Amazon Lex bots, DynamoDB table, and Amazon Connect contact flow.

Review the IAM resource creation and choose Create stack.

After a few minutes, your stack should be complete. The core resources are as follows:

Amazon Lex bot – AutoInsurance
Lambda function – AutoInsuranceBusinessLogic
DynamoDB table – auto_insurance_table
Amazon Connect contact flow – AutoInsuranceContactFlow
IAM roles – LexRole, LexImportRole, LambdaRole, and ConnectRole

If you provided an Amazon Connect ARN during stack creation, navigate to the Amazon Connect dashboard and choose Phone numbers on the Routing menu in the navigation pane.

Next, associate a phone number with the card services contact flow.

After the phone number is associated, the solution is ready to be tested.

Test the solution

You can use sample data to test the bot. If you used an Amazon Connect instance for deployment, you can call in to the Amazon Connect phone number and interact with the bot. You can also test the solution directly on the Amazon Lex console using voice or text. As you engage with the bot, you can observe the DynamoDB table update based on the conversation. After you try out the pre-built conversation flows, you can customize the bot to add more intents as required and integrate with the backend systems.

Auto insurance: Key capabilities

Let’s review some of the core capabilities offered by the pre-built solution, including re-eliciting slots, repeating important information, using context and context attributes, and contact center flows.

Re-elicit information

In a customer service conversation, agents have to clarify a question as they collect information. For example, for an auto insurance claim, the initial question might be “Where did the damage occur?” If the caller doesn’t respond with a specific part of the car, a follow-up question could be more prescriptive: “Sorry, I did not follow that. Can you share where the damage occurred? For example, it could be the windshield, bumper, or the door.” The following code shows this conversation flow example:

if year_of_vehicle and not damaged_auto_component:
        previous_slot_to_elicit = dialog.get_previous_slot_to_elicit(
                                                                intent_request)
        if previous_slot_to_elicit == 'DamagedAutoComponent':
            '''
             User input did not get resolved to a slot value. So, re-eliciting the 
             same slot one more time with a guided prompt
            '''
            prompt = "Sorry, I did not follow that. Where did the damage occur? 
		You can say something like ‘to the windshield’, ‘to the bumper’ 
		or ‘to the door’ etc"
            return dialog.elicit_slot('DamagedAutoComponent',active_contexts,
                session_attributes,intent,
                [{'contentType': 'PlainText', 'content': prompt}])

Repeat responses

Callers may want the agent to repeat with a simple request (“Can you say that again?”) to confirm a question or just capture important information. The pre-built solution offers a capability to store the response and then play it again when requested by the caller. AMAZON.RepeatIntent responds to the user’s words and phrases, to repeat the bot’s previous message. The following is the code for repeating bot responses:

if intent_name == 'Repeat':
    active_contexts = dialog.get_active_contexts(intent_request)
    session_attributes = dialog.get_session_attributes(intent_request)
    intent = dialog.get_intent(intent_request)
    previous_message = dialog.get_session_attribute(
        intent_request, 'previous_message')

    if previous_message:
        return dialog.elicit_intent(
            active_contexts, session_attributes, intent, 
            json.loads(previous_message))
    else:
        return dialog.elicit_intent(
            active_contexts, session_attributes, intent, 
            [{
                'contentType': 'PlainText', 
                'content': "I am sorry. I am unable to repeat that. 
                    Is there anything else I can help you with?"}])

…
…

# following is a dialog utility function 
def elicit_slot(slotToElicit, active_contexts, session_attributes, intent, messages):
    intent['state'] = 'InProgress'
    
    if not session_attributes:
        session_attributes = {}
    session_attributes['previous_message'] = json.dumps(messages)
    session_attributes['previous_dialog_action_type'] = 'ElicitSlot'
    session_attributes['previous_slot_to_elicit'] = slotToElicit
    
    return {
        'sessionState': {
            'sessionAttributes': session_attributes,
            'activeContexts': active_contexts,
            'dialogAction': {
                'type': 'ElicitSlot',
                'slotToElicit': slotToElicit
            },
            'intent': intent
        },
        'requestAttributes': {},
        'messages': messages
    }

Manage flows

The conversation flow can vary depending on the transaction. For example, when making an insurance payment, the flow changes based on the choice of the payment method. If the customer wants to use a credit card as the payment method, then the agent needs to collect the 16-digit card number, expiration date, and security code. If the caller prefers to use an electronic check, the agent needs to collect the account ID and the routing number. The pre-built solutions use a context management capability so you can manage such flows. The bot uses two separate intents to collect the payment details depending on the payment type (card or check): PaymentByCard and PaymentByElectronicCheck. The MakePremiumPayment intent captures basic information such as policy ID and sets the output context based on payment type. Upon the next user utterance, the appropriate intent is triggered based on the input context attribute. The following code shows how the contexts are managed:

# fulfilment of MakePremiumPaymentIntent      
if payment_amount:
    status, date, remaining_statement_balance, amount 
        = insurance_system.get_next_payment_details(
            customer_id)
    dialog.set_active_contexts(
        intent_request, 'CardPayment', 
        {
            'PhoneNumber':phone_number, 
            'DOB':dob, 
            'PaymentAmount':payment_amount,
            'PaymentMethod':payment_method,'Date':date
        },
        120, 10)
    dialog.set_active_contexts(
        intent_request, 'ElectronicCheckPayment', 
        {
            'PhoneNumber':phone_number,
            'DOB':dob,
            'PaymentAmount':payment_amount,
            'PaymentMethod':payment_method,'Date':date
        },
        120, 10)
    prompt = "Okay then, how would you like to pay, 
        by credit card, debit card, or electronic transfer?"
    return dialog.elicit_intent(
        active_contexts, session_attributes, intent,
        [{'contentType': 'PlainText', 'content': prompt}])

Contact center flows

You can deploy the pre-built solution as part of Amazon Connect contact flows. When customers call into your contact center, the contact flow to which they are sent is the one assigned to the telephone number that they called. The contact flow uses a Get customer input block to invoke the Amazon Lex bot. The following diagram illustrates the auto insurance contact flow.

Clean up

To avoid incurring any charges in the future, delete all the resources created:

Amazon Lex bots
Lambda functions
DynamoDB table
Amazon Connect contact flow
IAM roles

Conclusion

Amazon Lex for Insurance offers pre-built solutions that you can use to accelerate the delivery of engaging conversational experiences for increased customer satisfaction. In this post, we reviewed a solution for the auto insurance customer service function, related to activities such as providing a quote, processing a claim, and making a payment. The pre-built solution provides a ready-to-deploy contact center configuration with Amazon Connect. You can easily extend the solution with additional conversation flows that are specific to your organization’s needs. AWS enables an agile infrastructure for insurance organizations to optimize and innovate your business and deepen customer relationships. Try the pre-built insurance solutions on Amazon Lex today!

About the Author

Sandeep Srinivasan is a Product Manager on the Amazon Lex team. As a keen observer of human behavior, he is passionate about customer experience. He spends his waking hours at the intersection of people, technology, and the future.

Harish Lanka is a Conversational AI Specialist on the Smartbots.ai team. He spends his time talking to businesses, understanding their pain points and designing solutions using conversational AI. When he is not at his desk, he is either trading stocks, watching football or reading about spirituality.

View Original Source (aws.amazon.com) Here.

← previous - next →