Deliver natural and efficient customer service experiences to mobile subscribers with Amazon Lex
Mobile service providers manage a high volume of customer service calls daily. Rapidly evolving network technology and device innovations are shaping customer expectations. Delighting callers with a quick interaction is core to a successful customer experience strategy. Mobile subscribers contact customer support for several reasons such as requesting a new SIM card, changing a plan,…
Mobile service providers manage a high volume of customer service calls daily. Rapidly evolving network technology and device innovations are shaping customer expectations. Delighting callers with a quick interaction is core to a successful customer experience strategy. Mobile subscribers contact customer support for several reasons such as requesting a new SIM card, changing a plan, checking payment due, canceling service, requesting a new connection, or activating a phone. To meet these subscriber needs, providers have to scale customer service across multiple channels while improving the efficiency and quality of communication through automation.
In this post, we review how you can use the pre-built solutions in with Amazon Lex to automate the customer interaction for activating a SIM, making a payment, and reporting a lost or stolen device, so you can deliver a natural and efficient customer experience.
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 telecom offers pre-built solutions so you can deliver natural conversational experiences, while optimizing service delivery models and making new communication and media technology accessible to customers. The pre-built bots are configured with intents, sample utterances, and slot types for mobile services use cases and are integrated with Amazon Connect contact flows.
Let’s review a sample conversation regarding a request for a new SIM card as we cover the different components of the pre-built solution:
Agent: Thanks for calling ABC mobile. How can I help you today?
Caller: I need a new SIM card.
Agent: I see you are calling from mobile number 1234567891. Are you calling to change the SIM card for this phone number?
Caller: Yes.
Agent: For verification, please say or enter your passcode.
Caller: 123456.
Agent: Thank you. Next, for this type of request, I’ll need to text a one-time PIN to your phone number 1234567891. Should I go ahead and send it?
Caller: Yes.
Agent: Ok. I have sent it. Please say or enter the one-time PIN.
Caller: 1234.
Agent: Got it. Thanks for verifying. Can I go ahead and place a request for a new SIM for 1234567891?
Caller: Yes.
Agent: Done. You will receive the SIM card at the registered mailing address in 4 to 6 business days.
Caller: Thank you!
In the preceding sample conversation, the caller wants to place a request for a new SIM card. The agent captures the passcode for verification and then initiates the request for a new SIM card.
The pre-built solution includes bots for authentication and mobile services that can be deployed on Amazon Lex to automate the conversations. The MobileServicesBot contains intents for common mobile services activities such as requesting a new SIM card, changing plans, getting a bill, canceling service, requesting a new service, activating a device, and requesting a number change. It includes the following intents:
RequestNewSim – This intent captures customer information, and helps in placing a request for a new SIM card.
AddNewLine – This intent captures customer information, and helps in placing a request for a new line of service.
ReportLostDevice – This intent captures customer information, and helps the caller to report a lost device and suspend the service.
CheckPaymentDue – This intent captures customer information and provides due payment information to the caller.
MakePayment – This intent captures information such as the payment amount, credit card, or electronic check details, and processes the payment.
FindAStore – This intent captures the zip code and helps the caller find the nearest store.
EndConversation – This intent ends the conversation based on user input such as “Thanks, I am done”.
Fallback – This 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. The 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 authenticate the caller, process transactions (for example, “Request a new line”), or provide the caller with the requested information (for example, “What’s the payment amount due?”).
We use Lambda to simulate access to backend systems and run the business logic required for performing transactions. For this post, the data we use is stored in an Amazon DynamoDB.
To answer any user questions, we configure the 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 it with your website.
We include an AWS CloudFormation stack containing 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 mobile services on the Amazon Connect channel.
Prerequisites
You should have the following prerequisites before we deploy the solution:
IAM roles: LexRole, LexImportRole, LambdaRole, 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 mobile 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 as part of the deployment, you can call 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. After you try out the pre-built conversation flows, you can customize the bot, add more intents as required, and integrate with additional backend systems.
Mobile Services: Key Capabilities
Let’s review some of the features offered by the pre-built solution, including backend system data validation and contact center flow.
Validate user input
Agents authenticate callers by verifying the last four digits of their SSN or their passcode with information on file. If this validation fails, the agent requests the caller to provide the information again. The pre-built solution provides a Lambda function that performs the validation with information stored in the backend system. In addition, the pre-built solution provides logic to limit the number of authentication attempts. If the caller enters incorrect information three times, the bot ends the call.
The following code shows how to manage user input with account information:
phone_number = dialog.get_slot(‘PhoneNumber’, intent) zip_code = dialog.get_slot(Zipcode’, intent) status, customer_id = mobile_system.get_customer_id(phone_number, zip_code) if status == ‘INVALID’: # unauthorized user … … else: # proceed with authentication fulfillment … …
The following code shows how to limit the number of attempts using session attributes:
number_of_attempts = number_of_attempts + 1 dialog.set_session_attribute( intent_request, ‘number_of_attempts’, str(number_of_attempts)) if status == ‘INVALID’: # unauthorized user if number_of_attempts >= 3: message = “For your security, we are unable to complete your request, until you are able to provide required information. Goodbye” dialog.set_session_attribute( intent_request, ‘authentication_status’, ‘UNAUTHENTICATED’) return dialog.close( active_contexts, session_attributes, intent, [{‘contentType’: ‘PlainText’, ‘content’: message}]) if number_of_attempts == 1: prompt = “I didn’t find a match. Please say or enter your phone 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 phone number” return dialog.elicit_slot( ‘PhoneNumber’, active_contexts, session_attributes, init_state, [{‘contentType’: ‘PlainText’, ‘content’: prompt}]) else: # proceed with authentication fulfillment message = “Thanks for being our customer.” intent_request = dialog.set_session_attribute( intent_request, ‘authentication_status’, ‘AUTHENTICATED’) dialog.set_session_attribute( intent_request, ‘phone_number’, phone_number) dialog.set_session_attribute( intent_request, ‘customer_id’, customer_id) session_attributes = dialog.get_session_attributes(intent_request) return dialog.close( active_contexts, session_attributes, intent, [{‘contentType’: ‘SSML’, ‘content’: message}])
Integrate with database
The agent has to retrieve information periodically throughout a call. For example, callers may want to know their payment amount due (“What is my bill amount for this month?”) or their payment due date (“What is the last day to pay my bill?”). The pre-built solution includes a Lambda function with a placeholder business logic code that can be used to integrate with backend systems. The separation of business logic from the dialog management allows you to build and maintain the code base.
The following code shows how to integrate with backend systems to retrieve pertinent information.
You can deploy the pre-built solution as part of Amazon Connect contact flows. When customers call into your contact center, the call is processed by the contact flow assigned to the phone number. The contact flow uses a Get customer input block to invoke the Amazon Lex bot. Let us review the mobile services contact flow.
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 telecom offers pre-built solutions that you can use to expedite the delivery of engaging and sophisticated conversational experiences. In this post, we reviewed a solution for mobile services customers to automate common tasks such as requesting a SIM card or phone, updating plans, making payments, and activating service. By building on AWS, you are empowered to transform customer engagement while simplifying operations on secure infrastructure. The pre-built solution provides a ready-to-deploy contact center configuration with Amazon Connect. You can extend the solution with additional conversation flows that are specific to your organization’s needs. Try the pre-built mobile 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.
How Druva used Amazon Bedrock to address foundation model complexity when building Dru, Druva’s backup AI copilot
Druva enables cyber, data, and operational resilience for thousands of enterprises, and is trusted by 60 of the Fortune 500. In this post, we show how Druva approached natural language querying (NLQ)—asking questions in English and getting tabular data as answers—using Amazon Bedrock, the challenges they faced, sample prompts, and key learnings. Source
Druva enables cyber, data, and operational resilience for thousands of enterprises, and is trusted by 60 of the Fortune 500. In this post, we show how Druva approached natural language querying (NLQ)—asking questions in English and getting tabular data as answers—using Amazon Bedrock, the challenges they faced, sample prompts, and key learnings.
Use Amazon Q to find answers on Google Drive in an enterprise
This post covers the steps to configure the Amazon Q Business Google Drive connector, including authentication setup and verifying the secure indexing of your Google Drive content. Source
This post covers the steps to configure the Amazon Q Business Google Drive connector, including authentication setup and verifying the secure indexing of your Google Drive content.
Advance environmental sustainability in clinical trials using AWS
In this post, we discuss how to use AWS to support a decentralized clinical trial across the four main pillars of a decentralized clinical trial (virtual trials, personalized patient engagement, patient-centric trial design, and centralized data management). By exploring these AWS powered alternatives, we aim to demonstrate how organizations can drive progress towards more environmentally…
In this post, we discuss how to use AWS to support a decentralized clinical trial across the four main pillars of a decentralized clinical trial (virtual trials, personalized patient engagement, patient-centric trial design, and centralized data management). By exploring these AWS powered alternatives, we aim to demonstrate how organizations can drive progress towards more environmentally friendly clinical research practices.