Diligent planning and designing the bot is very crucial to the overall success of your bot strategy and this is where we envision the characteristics of the bot.
Questions that are typically asked in this stage include:
- We already have a web app. What problem are we trying to solve with the bot?
- Will our users know how to communicate with the bot? The answer is to this is mostly “yes”. But often the bot doesn’t know how to communicate with the user.
- What channels our users tend to use the bot on?
- What navigation patterns do you want to apply to the bot?
- What happens when our bot fails to answer?
- What functions are we going to wage our bot to answer?
- How do we ensure the user doesn’t get lost in the conversation?
- Are we creating the bot for the sake of creating a bot?
This list is endless.
I love this excerpt below from Microsoft’s documentation, and I can’t agree more.
None of these questions above directly relates to factors such as how smart the bot is, how much natural language capability it has, whether it uses machine learning, or which programming language was used to create it. Users are unlikely to care about any of these things if the bot solves the problem that they need to address and delivers a great user experience. A great bot user experience does not require users to type too much, talk too much, repeat themselves several times, or explain things that the bot should automatically know.
The same best practices that we gathered with our experience so far working with various other technical platforms may not fit the best with the bot development. In fact, sometimes the intuition is the best gift that you can have while designing the best bot. If you have ever seen a problem with your web application and went “that’s weird?” – Wait until you create a bot.
If you’re creating something new, it is inevitable there will be consequences that were not foreseen — some that will be great, and then there are those that aren’t as positive. There is a responsibility to try and predict as many of the consequences as possible and I think you have a moral responsibility to try to understand, try to mitigate those that you didn’t predict. – Jony Ive.
This paragraph just fits well enough for the bot development because the bot concept is in its inception as well. And the statement above is the ultimate inspiration for this post. Microsoft has sprinkled a lot of good patterns throughout their documentations and I aim to cover all the best patterns that I learnt so far and I have come across while developing bots in this blog post so it is easy to refer for me and others while they launch their bots to their users.
Plan sufficient time for Bot Design
I am not referring to the technical design here. There are a lot of questions that we need to answer during the planning exercise before making our bot answer, some of which I have indicated in the beginning of this article.
Microsoft makes available a tool called ChatDown. This tool helps us create a mock conversations between the bot and the user.
|What would you like to do?|
|* update – You can update your account|
|* List – You can list your data|
|* help – you can get help|
|user: I need the bot framework logo.|
|Here you go.|
|Here's a form for you|
Also, identifying the channels that your bot will support is important to begin with. There are a few functionalities that are not supported by certain channels and there are channel specific functionalities. Knowing this before will reduce the rework on the development phase and as much as possible come up with a channel agnostic design.
Channels – Facebook Messenger, Messenger, Kik, Skype, Slack, Microsoft Teams, Telegram, text/SMS, Twilio, Cortana, and Skype.
Do not compete with Siri, Alexa, Google Assistant or Cortana.
Plan to be simple. Identify a single core business function that is repetitive and time-consuming for your customers and/or agents and build the bot to do just this one thing. And design it very well.
If you are a company helping your customers transfer money, you could develop a bot that just transfers the money. If you are a News company, you can have a bot that fills yours customers in with the latest News.
By doing just this one thing very well, you are
- allowing your users to dip their feet in the new bot platform slow and steady.
- gaining users’ trust and confidence about the fact that they can use it intuitively and consistently.
- allowing your team to observe the user patterns – are the users using the bot? is this useful for anyone at all? what functionality would they like to see next? – gather user feedback before you make strategic investment choice.
This way you can build your bot iteratively while engaging your user base while building the bot.
Do you need Natural Language Processing?
Ask yourself the above question. If the answer is “No”, your bot will greatly be simplified. If you are in the fence to use the NLP (Natural Language Processing), think once again to consider alternate ways – such as
- Asking specific and direct questions to the user
- Providing choice buttons to guide the user to pick the predefined choices, thereby minimizing the user errors.
- Use Regex to parse standard commands such as “HELP”, “CANCEL” etc.,
It is a common misconception to think that the bot should always be a good conversationalist. It is generally not true. The business scenarios that the bot handles may not warrant a natural/free-form conversation. As long as your bot satisfies the core principles below, you are just fine.
- handling the user query faster and simpler.
- making it intuitive to use the bot.
- making the users understand where they are in the conversation and be able to navigate easily.
Don’t get me wrong – If you absolutely need to use NLP, you are welcome to use, but do not use unjustified as it will certainly bring additional layer of complexity.
If you do need to use NLP, you could use LUIS – When the conversation between the bot and the user is free-form and natural, it is important to understand the user’s intent through what the users are saying during the conversation. LUIS helps to identity the intents based on user utterances (requests).
Some of the best practices while considering LUIS are:
- Consider the number of intents you are planning – It could easily go unmanageable if you have a large number of intents. If you do need a large number of intents, consider hierarchical intents. This way you group the intents in a modular way and direct the user utterance using “dispatch” (More on the “Dispatch” later).
- Use “NONE” intent – In case the LUIS is unable to come up with the intent with a good score, the “NONE” intent is returned which will give back the control to the bot to handle the user’s utterance however the bot wishes. It is very important to use “None” intent, otherwise, the LUIS will try and match to one of the configured intents even if the intent matching score is very low which could cause undesired experience.
Use Dialogs to structure the conversation
Asking a single question to gather all the details from the user is not a good idea. Rather, ask a series of questions so that you get a specific answer which can be processed much more effectively.
If you want the users to book a hotel through your bot, the series of questions could look like
- Welcome! I can help with booking a hotel. Which location are you looking to book a hotel?
- How many people will be staying in the room?
- How many adults?
- Are there any kids?
- How many days?
- What is your budget?
and so on..
Dialogs api in the bot framework helps us to develop this model. You can use various prompt types to gather the user response.
For instance, to gather number from the user’s response, we can use “NumberPrompt”, to gather the text from the user’s response, we can use “TextPrompt”. For all the different prompts, please visit this link.
There is a “ChoicePrompt” that you can use in order to provide the users with the list of options. This will render buttons with the choices for the question that the users can click on without typing. This dramatically simplifies the user interaction.
Use component dialogs to turn portions of your dialog prompts into a reusable library. Let’s say your bot helps with the vacation packages which includes booking a hotel, booking flights, booking car etc., creating multiple component dialogs to group the underlying dialogs (booking hotel, booking flights, booking car) will allow you to manage them in a better way and to reuse these in another bot development.
For more details on Component Dialogs, visit this link.
Store the context of the conversation
A good bot design implies that you track the context of the conversation. This includes the user’s name and preferences and conversation data to track which stage of the conversation the user is currently in.
This way, you do not ask users the same question which really could be annoying to type in each and every time within the mobile real estate.
Also, let’s say you have created a dialog that asks for name, email address and marketing preference. Tracking the conversation’s stage will help to skip to the right question if the user ends up reconnecting to the conversation at a later date.
Do not ask for sensitive data
Plan your bot not to require any sensitive data from the user. If you do have to ask for sensitive data, explain why the data is required and how it will be used.
Also, if you plan on obtaining Personally Identifiable Information (PII) through bot, indicate the reason to make the user comfortable providing the details.
Welcome the user
This probably is a no-brainer statement. But this is really important as it gives you an opportunity to educate the user quickly about “what is this bot for”? and setting the right expectation with the user.
If you are pizza bot, the user might assume that he/she would be able to order a pizza, but what if your bot is just capable of talking about the menu and the nutrition facts of various pizzas.
Create a message “Welcome! I can help you with our menu and various nutrition facts of our pizzas. To order pizza, please visit the nearest store”. This way, the user’s expectation is completely managed.
Let’s imagine you want the users to submit a support ticket through a bot. Create a message “Welcome! I can help you with creating a ticket. Do you want to create a ticket for “Mobility” or “Home Internet”. By giving the “Mobility” and “Home Internet” as choice buttons, we are steering the user in the right direction while making them understand the purpose of the bot interaction at the same time.
Moral of the story is never ask a open-ended question to the user. The user’s response might be unpredictable and the bot will not be able to serve effectively. How can the user know all the possible things that your bot is capable of doing?
Consider asking “Do you want help with “Air-Conditioner” or “Refrigerator” instead of “How can I help you?”.
Handling User Interruptions
There are two types of User Interruptions – Expected and Unexpected.
Expected User Interruptions
When you are within the Case submission dialog that contains a series of questions, some expected interruptions from the users could be
“help” – the user could be shown some helpful guidances about the case submission process.
“cancel” – exit the current conversation.
You could provide the above actions as suggested actions during the case submission process so that the user is aware that they could invoke these actions if need be.
Unexpected User Interruptions
When you are within the dialog, there is a likelihood of user interrupting the bot to ask a related or non-related question to the particular conversation/dialog. Handling these interruptions are very important and greatly increases the user’s confidence to interact with the bot.
You could apply various strategy such as – answer the user’s interruption first and then continue with the current conversation. Or, inform the user to first complete the current conversation before interrupting or exit out of the current conversation altogether to answer the interruption question. There is no right or wrong way and it all depends on the specific scenarios.
Artificial Intelligence can help
You can also look at applying artificial intelligence (Natural Language Processing such as LUIS) to determine the user’s intent.
For example, if your bot is in the case submission conversation with the user and the user asks, “Can I ask you a question on the lawn mower product?” This is not handled by the current case submission conversation dialog, but the LUIS can determine the intent and allows to switch the process that involves answering questions on the products.
Response is mandatory
If everything fails, prepare to show a default message to the user rather leaving the user unattended. It is up to you to determine what the default response is, but having one as a backup plan will prevent you from turning down the user.
You can learn more about handling user interruptions here.
Use Proactive Bot
There are scenarios where you would want the bot to send a message to the user that is not related to the current topic of conversation or the last message received from the user.
Eg., if the user’s service request is completed in the Dynamics 365, you would like the bot to notify the user proactively.
But there are a few considerations to make when applying the proactive bot strategy within your implementation.
- Don’t send several proactive messages within a short amount of time. Some channels enforce restrictions on how frequently a bot can send messages to the user, and will disable the bot if it violates those restrictions.
- Don’t send proactive messages to users who have not previously interacted with the bot or solicited contact with the bot through another means such as e-mail or SMS.
Also, something to consider is when to interject the user with the proactive message. By far the simplest approach is to interject the user almost anytime, that means the user could be in a conversation with the bot in regards to another topic and the bot could interject the user to send a proactive message. This approach is called “Ad hoc Proactive Messaging” and this is by far the simplest approach. As a product owner, with this approach, we need to make additional decisions as to how the bot will continue with the current conversation after the proactive message has been sent to the user? Will the user know how to continue the conversation? What if the users have follow-up questions regarding the proactive message that they started typing on to confuse the bot as the bot could be thinking the user is talking about the current conversation, but clearly the user is not.
You could also explore other options to track when the user ends the conversation and gracefully interject with the proactive message. This will involve additional flags to indicate when in the conversation with the user could be interjected. Although this involves some level of technical complexity, this way we are separating out the current conversation and the proactive messages so that it is simplified from the user interaction perspective and from the dialog/decision making perspective as well.
I have also blogged about how to setup/use the Proactive Message with an example here. Please note that the v3 sdk was used in this blog and bot framework v4 is out.
To learn how to use the proactive message, visit this link.
Leverage Cognitive Services
Cognitive Services are a set of Machine Learning algorithms developed by Microsoft to solve common and popular problems that modern applications face today.
These are what I call as Super Powers that you can infuse your bot application with – there are services for Speech Recognition, Translation, Computer Vision, Intelligent Search, Natural Language Processing (LUIS), Text Analytics etc.,
Depending on the bot that you are developing, you may not require any of the cognitive services and that’s perfectly okay. But, during the planning/design exercise, it is important to identity what cognitive services that your bot needs and plan accordingly.
Visit this link to learn more on the Cognitive Services.
Use Sample projects to your advantage
Microsoft recognizes that the bot development is very recent but growing very fast, so they developed a catalog of sample projects to give a head start in our learning and development processes. These are already developed using best practices and consistent processes.
Visit this link to view all the sample projects.
Microsoft has also developed the “Enterprise Template” that is pre-built with foundational set of capabilities to build high quality enterprise grade bot.
This Enterprise Template can be installed in the Visual Studio and used like yet another project template.
This template comes pre-built with support for Welcoming the user, automated tying indicators, Dispatcher, Transcripts to be stored in Azure Storage, Inappropriate content detection or Personally Identifiable Information detection to name a few.
Overall, this template greatly simplifies the bot development by providing us with pre-built components that saves time and effort while guiding us to be with in the scope of the best practices.
Visit this link to learn more about the Enterprise Template.
Handoff the conversation to Human
Regardless of how much artificial intelligence the bot may possess, there may still be times when it needs to hand off the conversation to a human being. The bot should recognize when it needs to hand off and provide the user with clear and smooth transition.
There are various strategies that you can employ to handoff the conversation to human.
- You could use the bot to be the front line team to gather basic user details and handoff the conversation to human.
- You could use bot to answer basic questions and handoff to human in case of complex questions. The key is to understand the difference between the simple and complex questions and when faced with the dilemma, it is better to show the user with suggested action “Do you want me to engage a human agent”?
- You could also detect the sentiment of the conversation and if there is a negative sentiment during the conversation, you could handoff the conversation to human.
To learn more about the human handoff, visit this link.
If you are familiar with the Azure Application Insights, “Analytics” is an extension to the Application Insights. While App Insights provides “service-level” data such as traffic and latency, “Analytics” provides “conversation-level” reporting on users, message and channel data.
Analytics uncovers information such as,
- Total number of active users and activities sent.
- User Retention details
- Percentage of users on each bot channel.
and many more..
It becomes important to configure Analytics to understand feedback on your bot so as to layout or correct the course of your bot roadmap.
To learn more about the analytics, visit this link.
The business users who were involved during the bot planning phase may subconsciously be aware of the nuances of asking questions to the bot and they might always get away with positive results.
To get an accurate picture of where your bot stands, allow other internal users within your organization to interact with the bot to uncover user interaction issues. This helps to fine tune your bot and avoid embarrassing issues during the public launch.
Bot platform is at its inception, but the adoption is rapid. When we create bot applications, we have a common responsibility to design a bot that is so simple to use so that the transition from the legacy web applications to the bot platform is smoother and successful. We all share this responsibility, because if the users are turned down with the bots that are not designed well, chances are there that the users will develop a similar opinion about the other bots as well and ultimately end up not giving a shot to try different bots. The best practices laid out in this post apply to all the bot platforms and not just the Microsoft Bot Platform. Hope these practices helps us to build bots that are useful, engaging and efficient.