Building a chatbot, pt. 2: Conversations

Everybody has met or talked to a person that had a script to follow. Insurance salesmen, dealers, receptionists… All these people were given a script to follow, a checklist to go through, or just a simple answer to give when asked. Not unlike a chatbot.

In the previous article, I described a chatbot that we built for making reservations. Not much was said about the inner works or about its potential. There are indeed multiple topics to cover. In this article, I would like to talk a bit about conversations and conversation flow.

AI?

Our application is designed to fulfill users’ requests. A user usually has a general idea about what he or she wants to achieve. But even the most knowledgeable user can’t possibly know every item and variations that the application needs to achieve a goal. Even if the user is not sure what the right way to ask is, the chatbot should be able to guide the user and in the end, find exactly what the user desires, and then fulfill his request. For each request, the bot should have a list of instructions to follow - information that the user has to provide so that the application is able to execute the user's command.

Illusion of choice

To provide a good user experience, we decided to leave the first step to the user. The user’s first sentence gives us a direction to follow and an idea of the user’s intent, but actually, this is the last time a user is in command of the conversation flow. From this point on, every step of the conversation is directed by the application. The bot knows what checklist it has to follow to fulfill the request. Even if the user is not specific or not sure what to say, the bot should be able to get this information from the user with properly constructed questions.

Every conversation in our application is directed by a set of checklists. These checklists can be simple, even just one item, or they can spawn other checklists, and even create cyclic conversations. What exactly we are able to create with these types of checklists will be described in a separate blog. For now, let’s focus on the following example.

From a conversation to a checklist

Let’s meet our example user: Joe. Joe is working an office job and has multiple meetings per day. For those, he needs to schedule reservations in a call booth or a meeting room with his colleagues. At the start of the week, he knows about two meetings that will take place. One today (for the sake of this example let’s assume it is Monday) and one tomorrow. Interaction with the bot will then look like this:

User : Book me a room for today from 11:30 to 12:30
Bot : Alright! Do you want to book a specific meeting room or should I just book you one that is free?
Options : Any meeting room, Specific meeting room

​

For today's meeting Joe has a remote call with colleagues from out of town, therefore any available room will do the trick. He will select “any meeting room” from the options given. If there is an available room in the system, Joe will get one. Like this:

User : Book me a room for today from 11:30 to 12:30
Bot : Alright! Do you want to book a specific meeting room or should I just book you one that is free?
User : Any meeting room
Bot : I have booked room R.332 for today from 11:30 to 12:30 for you

​

And that's it. Joe has booked a room for a given time. From a user's point of view this is quite easy. Using our mobile applications, Joe can even use voice input!. This is all great, but how does it work?

To make a reservation, the chatbot needs to pass a checklist. For the example above, where the user is making a room reservation, the checklist looks like this:

• Intent - make a booking
• What (seat, room, call booth)
• Where (any available room, or does the user want a specific room?)
• When (date and time, or duration of the meeting)

Joe knew most of these and intuitively created a sentence that matched his wishes best. What was not explicit in the first sentence, the bot asked for in the follow-up question. When asking follow-up questions, chatbot usually gives users multiple options to select from. These suggestions give the user an idea of how to respond and also what kind of information the bot is expecting. In the same answer, the user can also write additional information.

Now let's say that Joe needs a specific room for a meeting that takes place on Wednesday. He needs a big interactive board, a projector and a room for 10 people where he will introduce new products to customers. This room is quite busy so he needs to find a spot for his meeting. The conversation could look like this one:

User : When is room R.121 available?
Bot : For which date(s) do you want to see the room's availability?
User : Wednesday
Bot : How long will you need the room for?
Bot : I will find you times, where there is enough space for your meeting. For example: 1 hour 30 minutes or just like 15 minutes
User : 2 hours
Bot : Alright.
Bot : The room R.121 is available on wednesday from 9:00 to 13:59.
Bot : Do you want to book it?
User : Yes
Bot : Ok, can you specify the time for me please?
User : 10:00
Bot : I have booked room R.121 on wednesday from 10:00 to 12:00 for you.

​

That's a slightly different conversation, right? But in the end, Joe will have his reservation ready. So what does the checklist on the bot’s side look like for this example?

• Intent - check availability
• What - specific place to check
• When - time-frame to check
• How long - meeting duration
• To book it or not

Up to this point Joe has only checked for available time slots. If he wants to make a booking now, he can. For booking, the chatbot has a different checklist. That one was previously listed, but here it is again for completion:

• Intent - make a booking
• What (seat, room, call booth)
• Where (any available room, or does the user want a specific room?)
• When (date and time, or duration of the meeting)

Most of these parameters are already checked for the booking. Joe has already told the bot to look for a specific room. He’s even given it a date so the only thing missing is the time. Joe gave the bot a meeting duration when he was checking for room availability. Now if Joe selects only the start of the meeting, the application already knows the duration and so it will make the booking last 2 hours.

But wait! That’s not all. Up to this point, all user’s requests had no problems. Let's say that our Joe has had a long vacation, he is back in the office again, but lost track of dates:

User : Book
Bot : Do you want me to book you a seat or a meeting room?
User : Meeting room
Bot : Alright do you want to book a specific meeting room or should I just book you one that is free?
User : What is available?
Bot : For which time frame(s) do you want to see available rooms?
Bot : You can tell me any time you want or you can use one of shortcuts bellow.
User : 20.3.2008
Bot : Unfortunately you cannot book or check seat availability in the past.
Bot : Please tell me a time or a time range you want to see available rooms for.
Bot : For example: Today, Tomorrow, Thursday, 24.10. or something like next week or from 10:30 to 11:15
User : Ok what about tomorrow?
Bot : Here is a list of available meeting rooms in your preferred area for tomorrow:
Bot : 1. R.121
Bot : 1. R.122
Bot : 1. R.123
Bot : 1. R.124
Bot : 1. R.125
Bot : These are the first ones I found. But there are some more.
Bot : Do you want to have some of these? You can also tell me, which specific one do you want to have
User : Yes
Bot : Alright
Bot : What room would that be?
User : R.124
Bot : Can you specify the time for me please?
User : From 10:00 just for a quick call
Bot : I have book room R.124 for tomorrow from 10:00 to 10:30 for you.

​

Even in case of a longer conversation and with an invalid date, the bot was able to provide Joe with a reservation.

​

Again, I will show you the checklist that the chatbot had to go through:

• Intent - make a booking
• What - meeting room
• Specification:
  • Check available meeting rooms
  • When - with validation
  • Want to book one?
• Specific room selection
• When - with specific time selection

​

Think in checklists

The main point of these examples is to introduce the checklist philosophy. Every conversation that we have in the system is designed as a checklist with multiple options. It's not a simple checklist where you just confirm an item and move on to the next one. Some of the items can be optional, however at least one has to be mandatory. Each item on the checklist can have its own checklists or policies. There can be policies that end the conversation on the spot or point to another checklist where the conversation continues. Some of the policies and transitions can be seen in the previous examples.

​

For example, for time specification we want only the current day or a day in the future, but not in the very distant future. For room bookings, only single-day reservations are allowed. Furthermore, when specifying a room, we have to select from a place that exists in the system database.

​

Conclusion

Conversations with our chatbot are based on checklists with predefined policies to follow. The user is given an illusion of choice with a first request that can be created any way the user desires, and afterward the control of conversation flow is entirely coded in the chatbot. From a developer’s point of view, that gives us an easy way to test these conversations, and develop each branch of conversation independently.

From the user's point of view, the bot asks for missing pieces of information. Thanks to the firm grip on the conversation, the user should not end up in a situation where he doesn't know what to answer or how to reach a certain goal.

So is it artificial intelligence? No. It's a state machine that follows pre-set lines of conversation. However, the conversation can be very complex, and when it is complex enough, users might come to the conclusion that this is what AI looks like.

Written by: Vojtech Kaisler