Deployment Settings
Updated
Before we begin
Before we look at Deployment Settings and how it is configured, it is important to know about Issue Types.
Overview
After you have created your dialogue tree bots and FAQ bots, you need to deploy them. To do this, go to the Deploy section. The function of the deploy section is to assign each dialogue tree bot and FAQ bot a priority so that the workflow of the application helps the user’s journey to run smoothly.
Prioritizing your bots works in the same way as it does with intents.
To Configure Deployment Settings
Click the New Tab icon. Under the Sprinklr Service tab, click Conversational AI App within Resolve.
On the Conversational AI Applications window, hover over the desired application and select Manage.
Next, click Deployment Settings under Deploy.
On the Deployment Settings window, you can see that there are three sections: Qualifying Bots, Issue Type Bots, and Fallback Bots. You will need to add each of your dialogue tree bots & FAQ bots to one of these lists and give each one a priority before they become active in your application.
Qualifying Bots
A Qualifying Bot is a bot which is used to perform some initial neccessary operations (e.g., tagging CFs, user differentiation, etc.) irrespective of the users query, before sending the query forward to the issue type bots.
Create a dialogue tree that is triggered when you need to capture the service tag of a customer's laptop. Note that when you click the “save and deploy” button in a bot, the bot gets added to a list of bots that are ready to be assigned a priority in the deployment settings.
On the Qualifying Bots window, click Add Qualifying Bot in the top right corner. Next, select the bot you just made from the list. Give it a priority, for example, 1, and click Save.
Fallback Bots
The Fallback Bots are the bots that take over if no conditions are met by any other bot or if a local fallback occurs inside any bot and there is no “Handle Invalid User Reply” setting configured.
Fallback bots are created and prioritized in the same way as Qualifying Bots. On the Fallback Bots window, click Add Fallback Bot in the top right corner. Next, select the bot you just made from the list. Give it a logical priority to dictate the order that they will spring into action and click Save.
This one is created by having the conditions blank. This means it will run irrespective of any triggers but because it’s deployed in the Fallback Bot section, it will only run if none of the Qualifying Bots or Issue Type Bots are triggered.
Issue Type Bots
An Issue Type Bot is a bot that is dedicated to a specific issue type. You know that Issue Type Intents are your top call drivers. ‘Issue Types’ are like the parents of ‘Issue Type Intents’. For example ‘Battery Issues’ is the issue type where ‘battery swelling issue’, ‘battery charge issue, and ‘battery draining issue’ are the children of Battery Issues. These children are ‘Issue Type Intents’.
As a best practice, you should create separate bots for each individual Issue Type. This is also important when it comes to deployment.
For the purpose of deployment, It’s important that every Issue Type Intent is assigned to an Issue Type. The assignment can be one to one OR many to one. The parent/child example we just gave above is a many to one assignment. But if you don’t have such a use case, then you can just make an Issue Type for each of our Issue Type Intents, for example, here we have made two issue types namely webcam issue and speaker issue, and added in them the corresponding issue type intents.
Now if you want to trigger a dialogue tree only via an ‘Issue Type Intent’, then, in this case, you can leave the trigger conditions field blank, i.e, there is no need to put an issue type intent here. This is because you will set your triggers for Issue Type Intents in the deployment section. Let’s take a look at how you can do this.
On the Issue Type Bots window, click Add Issue Type Bot in the top right corner. Now you have two fields, Select Bot and Select Issue Type. So, select the bot that you created for Speaker Issue and then select the Speaker Issue under ‘Select Issue Type’. This means that when the intent “Speaker Issue” is detected, the Speaker Issue bot will be triggered.
You can also Enable A/B Testing to run experiments on small sections before making the new similar bot live. If you select a new bot with % Split as 20, this bot will be deployed on 2 cases out of 10.
Logic behind deployment
Now that you have had a look at the three sections, let’s take a look at the logic behind deployment. Let’s say, you have a user that has written that they are having an issue with their laptop with both the webcam and the speaker.
Firstly, all of the qualifying bots will run. In our example, this bot will run and ask the user to enter their Service Tag. The user enters their service tag and authentication will take place via the API call for example. Now as the user gets qualified, the Conversational AI will address the user’s initial query.
In the very first user message of this conversation, the Conversational AI application detected two issue types and saved those issue types in its memory.
Now that all of the qualifying bots have passed, the application jumps to the Issue Type Bots and checks to see if the detected issue types that were saved in its memory have been addressed or not. If not then the issue type bots that have been assigned the detected intent will run.
Here we can see the two Issue Type Bots, one for Webcam issue and one for Speaker issue. The priority is set in the underlying issue type intents. If they have the same priority, then either of these would be triggered at random.
Next, after one of these bots has ended, the next bot will be triggered and so on until all of the detected issue types in that conversation that are saved in the memory of the application have been solved. Once all the issue type bots run, the conversation context will be cleared and the Conversational AI application will reset and wait for the next message.
At this point, maybe the user asks a question about an OS Update. Because the user is already tagged as verified, instead of being routed back to the qualifying bots again, the next message will jump directly to the Issue types bots. If no issue type is detected, it will jump to the fallback bot section and a fallback bot will be triggered.
Global Bots
You have the option to configure and deploy a global bot (Dialogue Tree) which will automatically operate on every fan message received, providing consistent and automated responses based on the predefined decision logic within the Decision Tree. This approach eliminates the need to create individual steps for specific intents and entities. For instance, consider the scenario where a customer requests to "connect to agent" at any point in the conversation. Instead of setting up the "connect to agent" action at each step, you can establish a global bot with trigger filters. This bot is the first to run on every fan message, ensuring that the "connect to agent" intent is recognized and addressed consistently, regardless of the context or stage of the conversation.
Consider another example where you wish to further enhance your interactions by tagging custom field values at each bot step. With global bots, you can dynamically tag fan messages with the appropriate custom filed values as the conversation progresses.
You can deploy multiple global bots and assign priority levels to dictate their sequential execution upon receiving fan messages.
