A multi-tenant chatbot with Dialogflow

Chatbots and natural language conversational engines are quite ubiquitous nowadays. The success or failure of a business to an extent hinges on the quality of its support teams. Running a 24 x 7 customer support team is a challenging task, in fact, many businesses would prefer to reduce the load on their support teams by offloading frequently asked questions and repetitive support tasks to machines. This can be achieved in numerous ways, ranging from redirecting customers to a FAQ page on their website to using more sophisticated ways like chatbots that can understand human speech, the latter being the subject of this article.

Everyday support teams end up addressing a wide range of customer queries. Most of the time, these customers are usually looking for something quick and to the point. Eight times out of ten, a simple FAQ page might not be able to cover every scenario that customers end up facing while availing of the service. All of this has to be done on a very tight budget too. Also, it is important to mention the fact that it is in human nature to hear or read a response as if it were coming from another human even if the same response might be illustrated pretty clearly elsewhere. This is where conversational bot engines like Dialogflow can help.

In this article, I am going to pass on some of my learnings working with Dialogflow. Dialogflow is Google’s NLU platform that can be used to design conversational user interfaces. Dialogflow is quite simple to understand and use if you are familiar with NLU and Intent classification. If you are not too familiar with Intent classification then I suggest reading the following articles, but here is a quick introduction of concepts that you will need to understand what is discussed in this article.

Intent: As the article suggests, intent describes the end-users intention for the conversation to take a turn. For example, “What is the weather today?” can be described as a user’s intent to know Today’s weather. Please note, in the above phrase the word today is quite significant as it is a Parameter onto which the Intent’s Action will be performed and a suitable Response will be generated and presented back to the User.

Contexts: As the name would suggest, context describes the context for Intent Matching. Contexts help to control the flow of conversations, by setting the input and output contexts. For example, on matching an intent, you can set an output context which in turn activates the next set of intent in the course of conversation. The application which will be discussing in the article makes use of this concept as well.

Fulfillment: Dialogflow provides a way to generate a more dynamic response by integrating custom APIs. Intents in Dialogflow have the ability to enable fulfillment, which basically allows routing the intent response generation part to a customized API that you can build and deploy.

1. Chatbot Trends Report 2021

2. 4 DO’s and 3 DON’Ts for Training a Chatbot NLP Model

3. Concierge Bot: Handle Multiple Chatbots from One Chat Screen

4. An expert system: Conversational AI Vs Chatbots

So we intended to build a conversational bot using Dialogflow’s NLU platform that could listen to incoming voice calls and redirect them appropriately. Think of this as a replacement for your in-person front desk operator. In addition, this was required to serve multiple tenants at the same time. You could think of this platform as something similar to an IVR that kicks in when you call a company board line but without the irritating “Press 1 for Sales…” but rather relying on NLP to route the call to the correct destination. Let’s call this Smart Attendant for the purposes of the current discussion.

Let me illustrate how this would work with help of the below use-case.

• An incoming call comes to the company’s main board line, the call gets routed magically to Smart Attendant ( How we route this to Smart Attendant is not really important for the scope of this discussion but it is important to note that the tenant information is passed and available to Smart Attendant )
• Smart Attendant kicks off the “event” with a Welcome Message and using Dialogflow’s native text-to-speech(TTS) engine this is relayed back on the line. So it could be somet
  hing like this

Welcome to ABC Car Dealership, please say the department to which you would like the call to be transferred

• The person on the other end might be interested in purchasing a new car, so they might say something like

Please connect me to Sales

• Assuming that the ABC Car Dealership has a Sales Department and an extension for connecting to a Sales Executive, Smart Attendant would satisfy the “intent” by redirecting the call to their extension
• We can take this few more levels if needed, for example, if ABC Car Dealership had multiple Sales Departments and each having its own extensions, Smart Attendant would then try to hint customer to provide more information

Please say which Sales Department would you like to be connected with , Audi , BMW or Mercedes

Connect me to Audi please

Sure, Connecting to Audi Sales Department

• This would be the end of our intent and Smart Attendant would redirect the call to Audi’s Sales Department. Please note how Dialogflow remembered the context of the conversation and remembered that caller had requested to be connected to a Sales Department
• As an alternative, you could also imagine if the caller is really familiar with ABC Car Dealership’s departmental structure and wants to be connected to Audi Sales Department, they might probably not want to waste time by exchanging conversations at multiple levels and rather prefer saying something like this

Please connect me to Audi Sales department

Sure, Connecting to Audi Sales Department

• Dialogflow received all the required parameters to fulfill the intent in one go and this time it did not respond back to the caller hinting to provide any further information

If you take a closer look at the above intent, it heavily relied on some training data specific to “ABC Car Dealership”. Dialogflow must be trained with specific department names of this company and phrases such as “Sales” “Audi” “BMW” “Mercedes” so that it can correctly classify the intent and fill in the parameters. If this was an ABC University, the departments could be something like “Engineering” “Medical” “Computer Science” etc. If you extrapolate this to hundreds of customers and each having their unique data sets and phrases to be fed into the training model, this could easily become a quite daunting task.

Just to set the context right, Smart Attendant was to cater to multiple single-tenanted applications providing Voice Communication as a Service (VCaaS) running on a Kubernetes Cluster. For simplicity, you can imagine each of these VCaaS running as a pod and each pod mapped to a single tenant. Our Smart Attendant solution was supposed to cater to all these tenants.

Now it could have been possible to create multiple agents in Dialogflow, one for each tenant but then all our VCaaS pod and K8s cluster were part of the same GCP project and for some reason, Dialogflow does not let multiple agents map to the same GCP project.

On the other hand, it would have been cumbersome to maintain one agent for every customer given the fact that most of our intents would have remained the same for all of them, so we had to find a way to detect the same intent for multiple customers but vary the responses based on the choice of the tenant.

Adding the training data is not much of a challenge since Dialogflow provides multiple ways of adding the training data to its model. The main challenge was how to ensure accurate classification of intents and their fulfillment specific to each tenant.

In order to achieve the above, we ended up creating a configuration data model that maps information specific to each tenant and then use this configuration data during intent fulfillment by calling our custom API from Dialogflow. When the call gets routed to Smart Attendant, it is accompanied by the tenant information which in turn is used to fetch the tenant-specific configuration. This configuration would contain all the data required to fulfill the intent. This configuration can be stored in any persistent storage like a backend database or any other configuration solution. Below is an example YAML file of a configuration for a single tenant.

- customerName: ABC Car Dearlership
message: Welcome to ABC Car Dealership, please say the department to which you would like the call to be transferred
departments:
- sales
- service
- finance
department_configuration:
sales:
message: Please say which Sales Department would you like to be connected with , Audi , BMW or Mercedes
departments:
- bmw
- audi
- mercedes
department_configuration:
bmw:
action: TRANSFER CALL TO extension 1001
audi:
action: TRANSFER CALL TO extension 1002
mercedes:
action: TRANSFER CALL to extension 1003
service:
<
strong class="kw js">action: TRANSFER CALL to extension 2001
finance:
action: TRANSFER CALL to extension 3001- customerName : ABC Health Care
message: Welcome to ABC Health Care, please say the department to which you would like the call to be transferred
departments:
- radiology
- oncology
- trauma
- cardio
department_configuration: ...

The above configuration maintains the following details for every tenant

1. Welcome messages
2. Department names
3. Sub-departments if any
4. Action to be taken once the intent is classified

Source: https://chatbotslife.com/a-multi-tenant-chatbot-with-dialogflow-aee0d9af77e1?source=rss—-a49517e4c30b—4