Build multilingual voice experiences in Amazon Connect
As companies aspire to go global with their products and services, there is an increasing business need to offer voice customer experiences in a number of languages. The need to provide multilingual customer experiences can also arise from the local, state, or international regulatory requirements. Sometimes within the same geographic region, customer segments may speak different languages. It therefore, becomes important to interact with your customers in the languages they feel most comfortable speaking.
With the advent of lifelike conversational voices in Text-to-Speech (TTS), companies are migrating away from using human talent for prompt recording in their IVRs (Interactive Voice Response Systems). The traditional approach of recording voices is not only expensive but it also hinders the ability to quickly change the messaging played on the fly. Using recorded voices for multilingual voice experiences complicates the process further. This is because each message has to be recorded in its own different voice and language before it can be deployed in production.
Companies usually create an IVR experience with one language and eventually add support for new languages as they grow. However, if this is not designed with the end goal in mind, it can result in multiple copies of the contact flows in each language. This will become difficult to manage over time, and will also increase the cost and release cycle time for changes and enhancements.
In this blog post, I will walk you through the steps to build and internationalize the same voice experience into multiple languages. All this without having to develop and maintain multiple copies of the experience in Amazon Connect. Builders will save development and testing cycles, and customers can expect to get consistent experiences in the language of their choice. We will be leveraging Amazon Polly within Amazon Connect to create this solution.
To follow along with the solution presented in this post, you need to understand the following AWS services and features:
- AWS Lambda
- Amazon DynamoDB
- Amazon Connect
- AWS Identity and Access Management (IAM)
- You also need an active AWS account with the permission to create and modify Lambda functions and DynamoDB tables.
To begin, you need an Amazon Connect instance configured for inbound and outbound calls, and you must claim a phone number after you create your instance. The Getting Started with Amazon Connect and Understanding Contact Flows documentation provide valuable background knowledge for this process.
We leverage the following capabilities in Amazon Connect in this approach:
- Ability to retrieve data from a low latency data store like DynamoDB in real time.
- Ability to play messages in plaintext as well as SSML (Speech Synthesis Markup Language).
- Ability to play prompts or messages using dynamic attributes, whose values are populated at runtime.
In the above architecture, the following sequence of steps takes place for an incoming contact:
- A customer calls into a Toll Free/ DID number, which invokes an Amazon Connect Contact flow.
- Amazon Connect invokes a Lambda function by passing the context (language, and the name of the message group) within the contact flow.
- Lambda queries Amazon DynamoDB to retrieve a JSON object representing the messages corresponding to this incoming context.
- Messages are of two types:
- a) Situational messages that can be enabled and disabled by administrators. These are used for situations like emergency messages and high call volume messages.
- b) Static messages that are always enabled, and are used for prompting the user for inputs or for providing information to the users.
- Lambda returns appropriate messages as a flat JSON back to Amazon Connect, where each message is represented by a variable name based on the message ID in the data store.
- Amazon Connect can either store these messages as contact attributes, or can use them directly as return values from the latest Lambda invocation.
- The contact flows in Amazon Connect have to be developed in such a way that every message played back to the user is configured using a dynamic attribute representing the message content from the message store.
Step 1: Deploy AWS CloudFormation template
The AWS CloudFormation template below creates the following instances required for this solution:
- One Lambda function messageRetrieverLambda
- index.js – Main handler
- Environmental variables (AWS Region, table name)
- 1 DynamoDB table – Messages (MsgGroup, Messages)
- One IAM policy and one IAM role that allows the Lambda function to access DynamoDB, Amazon CloudWatch Logs, and AWS X-Ray.
Follow the steps below to deploy the template:
- Log in to your AWS Management Console.
- Confirm that the AWS Region selected has the Amazon Connect service available.
- Click on the button below to Launch Stack in AWS CloudFormation.
- On the AWS CloudFormation page, modify the stack name if you prefer a different one.
- You can keep the other options as default.
- If you change the stack name, the text in this document referencing the prefix mlflows– will be inaccurate, and must be replaced with the stack name you decide to use.
- Click the Create stack button after selecting all three check boxes.
Step 2: Populate data into Amazon DynamoDB
The DynamoDB table is created by the AWS CloudFormation template. Below are the steps to populate test data into DynamoDB.
- In your AWS Management Console, open Amazon DynamoDB and choose Tables in the menu on the left.
- Choose mlflows-Messages, then select Items tab, and click on Create item.
- Change the dropdown at the top left of the Create item window from Tree to Text.
- Download the sample JSON file.
- Copy the contents of this file into the Create item pop-up.
- Click Save.
- You should see one row in the table now.
Step 3: Grant Amazon Connect permission to execute your AWS Lambda function
Ensure that the Amazon Connect instance has permissions to access this newly created AWS Lambda Function by following these steps.
- Select Amazon Connect in the AWS Management Console.
- Select your Amazon Connect virtual contact center instance.
- Choose Contact flows and scroll down to the AWS Lambda section.
- On the Function drop-down menu, select the mlflows-MessageRetrieverLambda function and click on +Add Lambda Function, as shown in the following screenshot:
Step 4: Import and configure the Amazon Connect contact flow
- Download the pre-built contact flow.
- Select Amazon Connect in the AWS Management Console.
- Select and log in to your Amazon Connect virtual contact center instance.
- On the left side of the Amazon Connect console, select Routing -> Contact Flows
- Click the Create contact flow button at the top-right.
- Click the drop-down at the top-right and select Import Flow
- Click the Select button and select the downloaded Blog-MultilingualFlows file from Step 1 above.
- Once the script is loaded, click on the header for the Invoke AWS Lambda function block and select the Lambda function that you granted Amazon Connect permissions in Step 3.
- Save and Publish your contact flow.
The pre-built contact flow Blog-MultilingualFlows is made up of the following key steps:
- Set the basics – logging, recording, and a contact attribute language initialized to en-US (US English).
- Invoke mlflows-MessageRetrieverLambda function to retrieve the initial set of messages using the default language. It plays the greeting message using a dynamic variable returned by the Lambda function.
- Prompt the user for the language option.
- In this blog, I have used two languages to demonstrate this approach – US English and US Spanish.
- If the user chooses an option other than the default initial language (e.g. chooses US Spanish):
- Update the contact attribute language from the default value to this new choice.
- Invoke mlflows-MessageRetrieverLambda function again to retrieve messages in this new language of choice.
- Play a transition message in the language that is chosen by the user to highlight the change in language.
- In a real world application, the rest of the contact flows are developed using the same principles. They would typically would invoke the Lambda function first, with the new language of choice and the name of the appropriate message group. This in turn, will retrieve the relevant set of message for each subsequent message or prompt in the contact flow.
Step 5: Try it out
- In your Amazon Connect instance, choose the Routing icon from the navigation bar, and choose Phone numbers.
- Click on the phone number you wish to associate with your new contact flow to edit. Choose the name of your contact flow from the Contact flow/ IVR drop-down menu, and choose Save.
- Call the phone number you claimed.
This blog uses message group name to identify the message group uniquely. In a real life application, there can be multiple factors that together determine the set of messages to be played (e.g. customer dialed number or DNIS, customer number or ANI, caller type or caller segment, and so on). These fields can be used together to form the partition key. Alternatively, they can be used as levels within the MsgGroup JSON structure.
The capability can be further expanded using Amazon Translate to translate the messages into appropriate language of choice. Messages can be translated at runtime, or event driven whenever a new message is added to the database.
In this post, we implemented a dynamic and data driven approach to build multilingual contact flows, without having to develop and maintain multiple copies of the experience in Amazon Connect. This can be used to simplify voice development and testing cycles, and enhance customer experience in the language of their choice.