Engaging Your Customer with a Multilingual Chatbot

Customer service is a must-have for any business today. With the global reach of many companies, there is a real need to engage with customers at any time, in a convenient way for your customers. Chatbots provide the ability to enable that customer support in a 24/7 model, giving your customers the ability to engage when they have a need to. But now there is another dimension to consider – language.

Introducing a bot that can support and speak multiple languages provides immense value to any organization, both in terms of customer support as well as in operational savings. Below, we talk about why it’s important, the different approaches to implementing a multilingual chatbot, and how Master of Code has implemented a solution using the Microsoft Azure stack of services.

The Value of a Multilingual Chatbot

First, let’s consider the customer service aspect. The value of a chatbot that can provide multilingual supports puts all of your customers on an even playing field. No one customer should be greater than the next; they are all customers, and how they engage with your brand is important. An omnichannel approach to customer design and engagement has long been a growth strategy in the customer experience space, and with contact center and chatbot platforms providing the ability to bring those channels into a single support interface, that horizontal growth of channel adoption is well underway.

The next step is to extend the reach of support over those channels to as many users as possible, and that’s where a multilingual chatbot can come into play. With these conversational systems already in place and with the ability to analyze and understand customer interactions, it’s relatively easy to review and understand which languages your customer base is attempting to engage in. This provides you some unique insight into your own current operational plans in which you can extend your bot automation services to allow for the adoption of additional languages, providing a more valuable customer experience. And, if you can ensure that the main use cases for those other languages can be transactionally contained within the chatbot, then some burden gets lifted for your live support agents.

Multilingual Chatbot vs. Multi-Language Live Agents for Call Centers

Those agents make up the second consideration when considering a multilingual chatbot solution. Today, when a bot is unable to answer a question or concern that a user is having, what happens? The conversation gets escalated to a live agent to work with the user. But there is nothing that says the live agent can engage with the customer’s language either, and with the escalation already possibly frustrating the customer, reaching someone who still cannot assist due to a language barrier will make the customer more frustrated and not look as positively on the brand.

Although it is possible to staff up individuals who can speak all of your customer languages, the impact to an organization is hard, and can also be quite costly. Consider the steps in bringing someone onboard to support a brand in a call center: you have to find and recruit the individual; coordinate a start time, usually with a larger group to optimize costs; perform the training, which on average can take from 6-12 weeks; not to mention procure equipment and enable setup and support for the agent. Even if we look at the lower end of the timing, say 1 week for recruitment and 6 weeks for training, that’s 7 weeks for effort and cost per agent. And in an industry that in recent years has seen attrition rates of 34%, the whole process is quite costly. And many organizations provide a premium to those agents who can provide multilingual support, which also increases cost and can decrease customer satisfaction should those agents leave the organization.

Many of the challenges that result in customer support agents leaving is overwork and frustration. But this is where a chatbot solution can come in and provide value, containing many of the repetitive and simple-to-answer queries for a customer before it hits the agent, reducing their volume and their own frustration and burnout. And in an industry that has high turnover due to burnout and with 53% of support teams experiencing an increase in demand for support, minimizing turnover and reducing that onboarding cost can help businesses focus on the issues that are most important to customers.

Implementing Multiple Bots for Multilingual Support

Historically, the most common method of creating chatbots that can support multiple languages is to create a single bot per language. By implementing this approach, a system needs to first understand the language in which the user is attempting to engage and then route them to the appropriate language-specific bot. That language bot then picks up the engagement and begins to engage with the customer.

The advantage to this model is that each language bot can be developed in parallel because they are disconnected from one another. Parallelism can mean faster to market to support more customers, which is great, but there are some challenges to consider when approaching the solution in this manner:

• The use cases may be different for each language bot. This can lead to an apples-to-oranges end result, with different bots providing different information. In other words, the customer in one language does not get the same support as in other languages, which can also lead to additional frustration from a live agent escalation in terms of how they need to handle individual customers.
• The conversation design and customer journey maps are disconnected from one another. This may make sense from a geographical standpoint, when different services are available in certain areas, but not from a multilingual support solution for a single geolocation.
• Support costs can escalate quickly. In the above example, there are 3 or 4 bots to manage and support – one for each language and then possibly the orchestration bot which allows the user to select the language. When changes are made, multiple standalone bots need to be updated, trained, tested, and supported. This can require more manual testing in each language, resulting in significant effort to effect a small change.
• You are limited to a single language at a time. There is no supportability for switching languages and maintaining context and positioning in the flow. Essentially, with a language change, the user is starting over again. This makes sense if not every flow is supported across all languages, but definitely not an optimal experience for the end user.

Now, none of those challenges are necessarily wrong. They are a valid approach in which multilingual support can be provided, but being aware of some of the challenges provides some new appreciation for the complexity of this automation.

But with that said, there is an alternative approach.

Implementing a Single Multilingual Chatbot

An alternative method for implementing a single chatbot that supports multiple languages is to leverage the ever-expanding cloud-based cognitive services to provide this language expansion. In this instance, there is a single Natural Language Understanding (NLU) service implemented in a default language for the bot. The use cases for this language are laid out, the persona and journey map exercise is developed, and the core of the chatbot is built.

Now, within the multilingual chatbot itself, a language detector component is implemented. This detector will then work with other services to translate the request and then apply it to the NLU to understand the intent of the question, which exists in the default language. Once matched, the appropriate response will be identified and formulated, in the language that the user engaged within, and then returned to the customer in their selected language.

That is a rather simplified explanation of the service, but let’s apply this approach to the challenges listed above:

• Different use cases for each bot. By approaching the solution this way, we mitigate this by having only a single multilingual bot. All use cases are available to every language that is available within the chatbot, but we can now ensure that the experience for a user in any of the available languages has parity with the other supported languages. This also means that the same activities before agent escalation are identical, so agents should have more confidence in what has happened before they engage with the customer.
• The journey maps are aligned because there is only one multilingual bot and so the experience is fully aligned in terms of what is being serviced and provided.
• Support costs exist, but now there is only a single multilingual chatbot to maintain. Additional costs may exist to leverage some of the other cognitive services as the underlying architecture has become more complex, but a DevOps team now has fewer bots to monitor and support in production, but now instead of doing individual testing in languages and deploying the chatbot independently, time can be optimized to deploy this solution in one fell swoop.
• Because the language is translated and understood as it happens, should the user change languages mid-stream then the flow continues unabated. The chatbot will then change its own responses to mirror that of the user, so long as that language is enabled and made available within the bot. This level of adaptability provides an enhanced experience to the end user and creates some additional value to the chatbot, including providing interesting data points of language switching mid-conversation, if that is of importance to the business.

Challenges of a Multilingual Chatbot Implementation for Enterprises

Even with these challenges mitigated somewhat, there is still some additional work in maintaining the multilingual chatbot. For each language implemented, the responses need to be crafted and formulated to be correct for the languages that make up the chatbot. Although it is reasonable to use NLU and automatic translation to understand the intent of the user, it is not necessarily the same as to how you create the response. Language is very nuanced and when you are talking about value, you need the responses to be aligned with the persona of both the chatbot and the brand. So the language within the responses need that additional support. (You would be doing this in the previous example as well, but it would be done in the confines of its own language bot.)

Because of this need to still manually craft the responses, the organization needs to decide on which languages they wish to perform multilingual support. Not every language can be easily detected, so there can be some technical limitations, which may result in a hybrid of the above 2 solutions being implemented. But when the language is supported, then adding an additional language to the portfolio is more a matter of intent mapping, utterance development, response message, crafting, and then training the bot to understand the updated language. The intent with this architecture is to not recreate the wheel with each subsequent language, but rather expand its language support as needed.

How Master of Code Global Developed this Multilingual Chatbot

There are many cloud service providers in the market today offering numerous cognitive services that can be creatively combined to provide a service such as this. The solution we explore above we have put together with a focus on using the various services from the Microsoft Cognitive Services suite.

The Microsoft suite provides all of the necessary tools and services to make either of these solutions happen. At the core of both methods in the Microsoft stack is Microsoft Conversational Understanding, which is a next step beyond LUIS, the previous iteration of NLU provided by Microsoft. Both of the products work with the Microsoft Bot Framework successfully, and have APIs for use by other systems, but the future of NLU at Microsoft resides with this next step tool which allows for many of the services outlined above, including the language orchestration activities.

The activities for Conversational Understanding are supported with the Azure Language Detection service, another one of the cognitive services provided in the Microsoft Cognitive Services suite. This service, which is continually advanced by Microsoft, allows for the growth of language quality and support, creating new opportunities over time for additional services to be bundled on top of this solution.

With all that, there are also services from other cloud providers that can provide similar services. For example, AWS has Amazon Comprehend, which can also perform detection on content to reliably understand the language that the inbound request is in. So although above we talk about how Master of Code has developed Conversational AI solution and an approach using Microsoft Azure services, there are similar options available from the other major cloud cognitive service providers that can be leveraged based upon the underlying architecture that an organization chooses to utilize.

How Do I Choose The Multilingual Chatbot Solution That Best for My Business?

That depends on your customer base. There is no one right answer as to how to approach developing and implementing a multilingual chatbot. Each organization needs to consider its customers, the volume of queries they have in some of the additional languages, and the value of those languages to maintain and support their brand. If the brand’s website is available in a certain language, then customers will expect support in that language as well, and so those should be the minimum number of languages supported. It also is based upon the technology stack that your organization utilizes, leveraging what you already have available without necessarily needing to go through a new onboarding and procurement process.

If you want to explore which options are best for you and your customer engagement strategy, reach out to our team of specialists at Master of Code who will help you to map out a path to customer engagement success with chatbots and automations to support your existing contact center activities.