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.
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?
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.
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?
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?
Agent: Can I have the three-digit security code printed on the back of your card?
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.
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.
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
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:
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:
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:
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.
To avoid incurring any charges in the future, delete all the resources created.
Amazon Lex bots
Amazon Connect Contact flow
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.
Read MoreAWS Machine Learning Blog