Build conversational experiences for credit card services using Amazon Lex

New trends are shaping the credit card industry as shopping habits have rapidly evolved over the last 18 months. The pandemic has accelerated the move away from cash towards cards. Card issuers are transforming their products to better serve cardmembers through innovations such as contactless payments and mobile wallet. The rapid change in consumer behavior and expectations requires issuers also improve their customer service function as consumers adopt a digital-first experience. Credit card members contact issuers for several reasons such as bill payments, balance transfers, and resetting PINs. They may have queries related to rewards programs or interest rates. Card members expect a personalized and frictionless experience in their customer service interaction.

In this post, we review how you can use Amazon Lex, a service for building conversational interfaces, to automate the customer service experience for common cardholder activities such as activating the card, making payments, and reporting a lost or stolen card.

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. This enables you to build applications with highly engaging user experiences and lifelike conversational interactions. Amazon Lex for financial services 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 as we cover the different components of the pre-built solution:

Sample conversation: Credit card payment

Agent: Welcome to card services. Can you please say or type your 16-digit card number?

Caller: 1234 5678 1234 5678

Agent: Okay. And the zipcode on the card?

Caller: 76543

Agent: Thank you for being a valued customer. How may I help you?

Caller: I want to make a payment.

Agent: Sure. For verification, please enter the last four digits of the primary card holder’s social security number.

Caller: 6789

Agent: Our records indicate that your last payment transaction was processed using a checking account number ending in 7890. Would you would like to use the same account?

Caller: Yes

Agent: All right. So how much would you like to pay? Your minimum due $125, the current balance of $400, or a different amount?

Caller: Minimum due

Agent: Thank you. You are requesting a payment of $125 towards your credit card account. The funds will be withdrawn as a one-time electronic transfer from your bank account, ending in 7890. Can I go ahead with the payment request?

Caller: Yes

Agent: Can I have the three-digit security code printed on the back of your card?

Caller: 123

Agent: Thank you. Your payment was successful and has a confirmation number 12345678. Let me know if there’s anything else I can help you with.

Caller: No thanks.

Agent: Thank you. Have a great day!

In the preceding sample conversations, the agent first collects information (SSN and account ID) to verify the caller’s identity. After the caller is verified, the agent engages to complete the user request (make a payment) by starting a dialog to collect additional information (payment amount). Lastly, the agent performs the task (process payment) and provides a confirmation. The pre-built solution includes bots for authentication and card services that can be deployed on Amazon Lex to automate the conversations.

The CardAuthentication bot provides dialog to authenticate the caller. It includes the following intents:

Authentication – The intent collects information such as the caller’s credit card number and zipcode, and verifies these with the details on the account that are stored in a secure database (DynamoDB table).
MissingInfo – The intent is triggered if the caller does not have access to information requested in the authentication intent.
Fallback – The intent is invoked when the input does not match any of the configured intents.

The CardServices bot contains intents for common cardmember activities such as activating cards, resetting PINs, and reporting a lost or stolen card. It includes the following intents:

ActivateCard – The intent activates the card after collecting information such as credit card number and security code.
CreditCardBenefits – The intent provides information about the benefits to card member.
EmailCardPIN – A follow-up intent so that caller can request delivery of PIN through email.
EndConversation – An intent to end the conversation on caller inputs such as “Bye” and “I am done”.
MailCardPIN – A follow-up intent gated by context so that it is triggered after a the ResetCardPIN intent.
PayCardBill – The intent collects information such as payment amount, security code, and last four of SSN and processes the payment.
Repeat – An intent based on the built-in capability to repeat the last bot response.
ReportMissingCard – The intent captures information related to lost or stolen cards by recording details such reason and date.
RequestNewCard – The intent captures callers request for a new or replacement card.
ResetCardPIN – The intent helps with resetting the PIN after verifying the security code on the card.
ZipcodeVerificationNewCard – An intent to capture the zipcode on the card.
Fallback – The intent is invoked when the input does not 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 card data used for authentication is stored in a DynamoDB table.
After the caller is authenticated, the control is passed to the main card services bot to perform transactions (for example make payment) or provide caller with requested information (for example “What can I redeem rewards for?” We use Lambda to run business logic required for completing 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 a Connect instance or integrate with your website.

We include a template that creates an AWS CloudFormation stack for you containing all of 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 card services on the Amazon Connect channel.

Prerequisites

You should confirm the following pre-requisites 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 an AWS CloudFormation stack in the Region of your choice:

For Stack name, enter a name for your stack. This post uses the name card-services-solution:

Next, provide the Parameters for Lex bots, DynamoDB table, and the Connect contact flow.

Lastly, review the IAM resource creation and click on ‘Create Stack’. After a few minutes, your stack should be complete. The core resources are listed below:

Amazon Lex bots: CardAuthentication and CardServices
Lambda functions: CardAuthenticationFunction and CardServicesFunction
DynamoDB: card_services_table
Amazon Connect contact flow: CardServicesFlow
IAM roles: LexRole, LexImportRole, LambdaRole, ConnectRole

If you provided a Connect ARN during stack creation, then navigate to the Amazon Connect dashboard and click on ‘Phone numbers’ tab.

Next you will associate a phone number with the card services contact flow. Once 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 V2 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 add more intents as required and integrate with the backend systems.

Card services: Key capabilities

Let’s review some of the core capabilities offered by the pre-built solution across dialog management, natural language search, and contact center flows.

Dialog management: Customer service conversations often include patterns as the caller interacts with the agent. Amazon Lex provides native support for some conversation patterns such as Wait and Continue when a caller requests the agent to wait in a conversation (“Can you hold on a second while I get my credit card?”) and then continue the call (“Ok let’s go ahead. My credit card number is 1234”). In addition, the pre-built solution offers functionality to handle other conversation patterns such as request disambiguation and input confirmation.

First, let’s review how we can disambiguate user requests such as “I’d like to cancel”. It’s not clear from the input if the caller wants to cancel a recent balance transfer, or their auto payment, or the credit card. Agents have to navigate such conversations carefully to elicit the relevant details before performing the appropriate task. The pre-built solution uses intent classification confidence scores along with the alternate intent matches surfaced in the API response to disambiguate user requests. In this case, the Lambda function in the fallback intent is configured to respond with a clarification “Do you want to cancel a balance transfer, cancel auto pay, or cancel the card?” If an alternate intent (for example, cancel auto pay) is above a certain threshold confidence score, then the corresponding verbiage (“Did you mean cancel auto pay?”) is appended to the clarification prompt. The following is the dialog management code for the disambiguation pattern:

disambiguation_prompts = {
    "CancelAutoPayment": "Did you mean cancel auto pay?",
    "CancelRecentBalanceTransfer": "Do you want to cancel a balance transfer?",
    "CancelCreditCard": "Do you want to cancel the credit card"
    "DefaultFallback": "Some of the things I can help you with are: bill payment, 
        card activation, reporting missing card. Can you please rephrase your request?"
}

intent = dialog.get_intent(intent_request)
active_contexts = dialog.get_active_contexts(intent_request)
session_attributes = dialog.get_session_attributes(intent_request)

if intent['name'] == 'Fallback':
    prompts = disambiguation_prompts

    interpreted_intents = [
        {'name':intents_list['intent']['name'], 
         'nluConfidence':intents_list.get('nluConfidence')}
        for intents_list in intent_request['interpretations']]
    
    possible_intents = interpreted_intents[1:]

    default_fallback_message = 
        disambiguation_prompts.get('DefaultFallback')
    message = default_fallback_message
    
    if len(possible_intents) > 0:
        nearest_intent = possible_intents[0]
        if nearest_intent.get('nluConfidence') > 0.6:
            message = 
                disambiguation_prompts.get(nearest_intent['name'])

    return dialog.elicit_intent(
        active_contexts, session_attributes, intent, 
        [{'contentType': 'PlainText', 'content': message}])

Next, let’s will walk through a conversation pattern that requires confirmation of input. For example, consider a dialog to collect the destination account for a credit balance transfer request. It’s critical to capture the destination account accurately; an agent would typically confirm the destination account (“I have the account ID as 1234567890. Is that correct?”) The pre-built solution offers a capability so you can confirm user input for such slots. The Lambda function for the dialog codehook for the slot is configured to respond with a confirmation (“To make sure I got that right: Do you want to initiate the transfer to 1234567890?”). The following is the dialog management code for the slot confirmation pattern:

if account_number and not account_number_confirmation:
    previous_slot_to_elicit = dialog.get_previous_slot_to_elicit(
                                                        intent_request)
    if intent['confirmationState'] == 'Confirmed':
        dialog.set_slot('AccountNumberConfirmation', 'Confirmed', intent)
        account_number_confirmation = 'Confirmed'
    elif intent['confirmationState'] == 'Denied':
        dialog.set_slot('AccountNumberConfirmation', 'Denied', intent)
        account_number_confirmation = 'Denied'
    else:
        dialog.set_slot('AccountNumber', 'others', intent) prompt = "Okay, Can you
               give your account number again?" 
	return dialog.elicit_slot(
            'AccountNumber', active_contexts, session_attributes,
            intent, [{'contentType': 'PlainText', 'content': prompt}])
    else:
        prompt = "I have your account number as, 
                    "+str(account_number)+
                    ", Is that correct? "
        return dialog.confirm_intent(
                    active_contexts, session_attributes, intent,
                    [{'contentType': 'PlainText','content': prompt}],
                    previous_dialog_action_type='elicit_slot',
                    previous_slot_to_elicit = 'CheckAuthorization')

Natural language search

Callers often ask questions related to the product or service during a customer service call. For example, they may inquire about interest rates (“What is the APR applied to my card?”) in a payment call or ask about a rewards program (“Can I apply the rewards points to groceries?”). Amazon Lex natively integrates with Amazon Kendra, an intelligent search service, so you can configure the bot to answer questions in a conversation. You can upload your content to Amazon Simple Storage Service (Amazon S3) bucket and create a search index on Amazon Kendra. You simply define the search index parameters in a search intent as part of the bot definition. The bot queries the Amazon Kendra search index during the interaction if the user input doesn’t match any of the other configured intents. The search query responses are populated with request attributes that the bot can use in its response.

Contact center flows

You can deploy the pre-built solution as part of Amazon Connect contact flows. When customers call in to 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 customer input block to invoke an Amazon Lex bot. The following diagram shows the credit services contact flow in Amazon Connect:

The first ‘Get customer input’ block passes the control to the Authentication bot. You can restrict the number of authentication attempts with the following code:

if zip_code = dialog.get_slot('ZipCode', intent)
card_number = dialog.get_slot('CardNumber', intent)

number_of_attempts = dialog.get_session_attribute(intent_request, 'number_of_attempts') or '0'
number_of_attempts = number_of_attempts + 1

# use session attributes to maintain the number of user attempts
dialog.set_session_attribute(
    intent_request, 'number_of_attempts', str(number_of_attempts))
session_attributes = dialog.get_session_attributes(intent_request)

if not zip_code or not card_number:
    return dialog.delegate(active_contexts, session_attributes, intent)

if zip_code and card_number:
    # authenticate customer
    customer_id = card_system.get_customer_id(card_number, zip_code)
    
    # didn't find customer id
    if not customer_id:
        if number_of_attempts >= 3:
            response 
                =   "For your security, we are unable to complete your request, 
                    until you are able to provide required information. Bye"
            dialog.set_session_attribute(
                intent_request, 'authentication_status', 
                'UNAUTHENTICATED')
            return dialog.close(
                active_contexts, session_attributes, intent, 
                [{'contentType': 'PlainText', 'content': response}])
        
        if number_of_attempts == 1:
            prompt = "I didn't find a match. Please say or enter your card number. 
                    If you need time to get that information, say, wait a moment."
        elif number_of_attempts == 2:
            prompt = "I didn't find a match. Please try one last time. 
                        Say or enter your card number."
            
        return dialog.elicit_slot(
            'CardNumber', active_contexts, session_attributes, 
            init_state, 
            [{'contentType': 'PlainText', 'content': prompt}])
    else:
        ''' 
          got the customer id
          store customer authentication details in the session
        '''
        intent_request = dialog.set_session_attribute(
            intent_request, 'authentication_status', 'AUTHENTICATED')
        dialog.set_session_attribute(
            intent_request, 'customer_id', customer_id)
        session_attributes = dialog.get_session_attributes(
            intent_request)
        response = "Thank you for being our customer."
        return dialog.close(
            active_contexts, session_attributes, intent, 
            [{'contentType': 'PlainText', 'content': response}])

After the authentication, the ‘Check contact attributes’ block verifies the status and transfers the flow to the card services bot only if the contact attribute is set to ‘Authenticated’. Information captured during verification (such as account ID) passed in the flow through session attributes.

Cleanup

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 financial services offers pre-built solutions that you can use to expedite delivery of natural and sophisticated conversational experiences. In this post, we reviewed a solution for a credit card services customers service function for common cardmember activities such as making a payment, activating a card, and resetting a PIN. 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. Building on AWS empowers you to modernize infrastructure, meet rapidly changing customer behaviors and expectations, and drive business growth. Try the pre-built financial services solution on Amazon Lex today!

About the Authors

Jaya Prakash Kommu is a Technology Lead on the Smartbots.ai team. He manages a passionate team of AI engineers building next generation conversational AI interfaces. When not architecting bots, JP enjoys playing football.

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.

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

← previous - next →