Building a chatbot is different from building a traditional application. The mindset and considerations when developing a chatbot are not the same. It will take some getting used to because it is so different from a regular application.
I’ve been building a chatbot for the past year now, so in this post, I want to share some of the differences to building a regular application. For the purpose of this post, when I use the term “application” it will refer to a traditional/ regular application.
1. Think in Terms of Conversations
The flow for a chatbot and an application is different and involves a different way of thinking. While an application can stick to a defined flow, a chatbot needs to accommodate for more. The flow in most cases is the happy path (including expected errors). For a chatbot, the form of input from the user is a conversation (statements), which can open many different paths. Although it is impossible to account for every single path a conversation can take, related topics would need to be handled. This is a concern that is not necessary for a regular application.
For example, let’s say you have a chatbot trying to take orders for restaurant reservations. If it was a regular application, you would have a screen that asks for their name, party size, and the date. Those would be the only information the user can provide otherwise it would be considered an error and won’t continue. For a chatbot, the user might type in all the information at once although only asked for their name, such as “My name is John Doe and would like a reservation on 2/14 for two people.” In such a situation, all the information is provided and the bot shouldn’t ask for any of them individually and jump straight to placing the reservation. While for an application, it can say an error and ask for the name again and it would be fine.
2. A Conversation Is Ongoing
A conversation always follows the pattern of a question then answer which leads to another set of questions and answers and so on. Even when a chatbot is to provide a service, even after the service is complete the conversation is not over. The user might still have other questions or want to do another task. While for an application, once it is done with the specific task it can call it done.
3. Error Handling Is Not Showing an Error Message
When the chatbot asks for a piece of information and the user provides something else is that actually wrong? For an application, it would be, but for a chatbot it depends. If the user provided an answer to a future question then the bot needs to show acknowledgment of it instead of treating it as an error. It is only an error when what the user says has nothing to do with the service(s) the chatbot provides. Otherwise, the chatbot needs to guide the user towards the right answer.
For example, the following conversation shows how an error handling conversation can be like:
Bot: “What is your name?”
User: “I want to reserve a table for two”
Bot: “Alright, I can help reserve a table for two. Can I get your name?”
5. Wider Range of User Inputs
The possibilities of what a user can type to the chatbot are endless. There can be many ways to say an answer that has the same meaning. For example, if a user provides an answer to the question, “What is the party size for the reservation?” The user can say:
- “I want to make a reservation for two”
- “Reservation for two people”
- “two people on 2/14”
- “two”
All those statements within context mean the user wants a reservation for two people.
Unlike an application, you can’t enforce specific expected answers. You have to give the user freedom in order to create a naturally flowing conversation.
6. Need to Have a Personality
Just like how each person speaks in a unique way, a chatbot should have a set of characteristics that dictate how it should speak. It’s important to keep that character consistent in all the messages the chatbot says as it adds to the conversation.
It’s a similar idea to how an application has a certain theme and style throughout the entire application. If there was a section that has a different theme and style it would become noticeable immediately and break the consistency.
7. A Chatbot Is Expected to Be Smart
When it comes to a chatbot, the user often relates their expectation to that of talking with a human. That means they expect follow up question(s) if what they said is not enough. They don’t expect to have to repeat their answers. If they are not understanding what is being asked they expect help such as asking the question differently.
So, let’s summarize these expectations with a simple example conversation of a reservation chatbot. The chatbot needs to know the full name, date, and party size to make a reservation. The chatbot by design asks for each piece of the information individually. So the ideal conversation would go like the following:
Bot: “Hi, I’m Rose your virtual assistant for making a reservation.”
User: “Hi, I want to make a reservation”
Bot: “What date would you like?”
User: “2/14”
Bot: “For how many people?”
User: “2”
Bot: “Under what name would the reservation be for?”
User: “Steven To”
Bot: “Thank you, Steven. I got you a table for two on 2/14. Here is your order number: 12345.”
However, the expectation is for the chatbot to be smart enough to handle the following conversation too:
Bot: “Hi, I’m Rose your virtual assistant for making a reservation.”
User: “Hi, I’m Steven To and I want a table for 2 on 2/14”
Bot: “Thank you, Steven. I got you a table for two on 2/14. Here is your order number: 12345.”
8. Chatbot Is Language Understanding Driven
Writing a bunch of if and else statements can only get you so far when it comes to building a smart chatbot. To really push a chatbot to the next level, it needs to make use of language understanding. This simplifies the code to make it easier to build and to understand. Backing the language understanding service is the language model, which you must build because it is domain-specific. The end result is a language model that is broken down by entities and intents, which is what a statement is broken down into at each turn of a conversation. A simple way to think about it is that entities are keywords and intent is the underlying meaning of a statement, which contains some entities. So, in a conversation, the next set of questions and answers is driven by what the language understanding service understood.
For example, back to the reservation chatbot example:
Bot: “Hi, I’m Rose your virtual assistant for making a reservation.”
User: “Hi, I’m Steven To and I want a table for 2 on 2/14”
Bot: “Thank you, Steven. I got you a table for two on 2/14. Here is your order number: 12345.”
The language understanding service would recognize the intent as making a reservation and entities would be “Steven To”, “table for 2”, and “2/14”. The entities might be name, party size, and date. Before asking for other information the chatbot checks if the name, party size, and date is already available. In this case, they are so the chatbot jumped straight to placing the reservation. If there was a piece of information missing then the chatbot would ask for that piece of information only.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
Have you developed a chatbot before? If so what are your experiences with building one? Are there any other differences between building a chatbot and a regular application not mentioned?
To get in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.