Build a Considerate Reservation Bot

Sean Wu
5 min readJul 27, 2024

--

Understanding natural language was considered a main blocking issue in building chatbots. ChatGPT has demonstrated that large language models (LLMs) can understand natural language. But given that all chatbot platforms have by now integrated LLMs in one way or another, why is it still really rare to see considerate conversational experiences for simple tasks like booking a table?

It turns out, ChatGPT only needs to respond based on common sense knowledge; a considerate business chatbot needs to be programmed to respond based also on business conditions and logic. Injecting such logic into a GUI is easy, since users can only interact with your software in the ways that you’ve implemented for them. With a chatbot, users can say anything they want. So if you don’t plan for enough scenarios, your bot will not be able to handle some users’ legitimate input in a manner tailored to your current business conditions, thus frustrating your users.

Using a restaurant reservation bot as an example, we will bring attention to some considerations beyond the basic flow. This way, product managers can gain a concrete understanding of the complexity involved in building considerate conversational user interfaces, so they can budget their efforts accordingly.

User history

While “Hi, good {time_of_day}, what can I do for you?” is a good greeting, there are many things we can do improve the experience.

Use the user’s name to make it personal. While popular messaging channels like WhatsApp and iMessage do not give your bot the user’s name directly for privacy reasons, you can get their phone number. Ask for their name and save it in the CRM software as follows. This user can then be greeted with a personal touch in all subsequent chat sessions by using their phone number to look up their name first.

Bot: Hi! Welcome to [Your Business]. May I know your name?
User: Jane Doe
Bot: Nice to meet you, <user name: Jane>! How can I assist you today?

Similarly, if the user has an existing reservation coming up, it is useful to mention that during the greeting to acknowledge that the bot is on top of things and set up the context for potential relevant discussions about that.

Bot: Hi, <user name: Jane>! I notice you have table reserved for tonight,
what I can do for you?

In fact, any useful interaction in the past can potentially be used for add personal touch to greeting, and to every turn along the way.

Business condition

When users express interest in booking a table, it is important to find their date preference. The bot can simply ask, “Which day would you like to come?” This approach works well for quiet restaurants. However, for a popular restaurant with limited availability, this can frustrate users. The bot may frequently reject their chosen dates due to unavailability, leading to a poor user experience.

In such a scenario, it is better to provide a candidate list of available dates for users to choose from. By checking the production database first for a list of dates via some API call, using all the existing information to filter, the bot can instead say:

Bot: Which day would you like to come? The next available date are July 20,
July 24 and July 25th.

Of course, this opens up a whole can of worms. Now, users might say ‘The second option is good’ or ‘None of these are good. Any more choices?’ Needless to say, you also need to figure out how your bot should behave if the API call returns zero candidate dates when you are fully booked or when only one candidate date is available.

Current business conditions can be used to improve other aspects of the chat experience. For instance, when a user makes a choice, we can instantly check its serviceability in our system. If the option isn’t available, we can notify the user immediately. This can potentially avoid frustration shown in the following conversation.

Bot: Which day would you like to join us?
User: July 30th.
Bot: How many people will be in the party?
...
Bot: Sorry, actually we donot have availability on July 30th.

User initiated unhappy path

Even for a simple use case like reserving a table, there are many reasons that users change the course of the planned conversation.

  • Take a detour. In middle of a conversation, user might need to change topic, for example, to collect additional information to make decision:
Bot: What time do you want to join us?
User: When do you guys close?
  • Change their minds. This includes canceling a reservation after it is made or changing something about the reservation during the booking process.
  • Communicate from a different angle. For a chatbot, the easiest communication occurs when the bot asks the user for a date and receives a date. The bot can just fill the corresponding slot with the value collected. But sometimes, users might express themselves differently:
Bot: What day would you like to dine with us?
User: I can not do it on Mondays.

Don’t frustrate me

In his book “Don’t Make Me Think: A Common Sense Approach to Web Usability”, Steve Krug popularized the idea that a well-designed website or interface should be intuitive and easy to use, requiring minimal effort from users to understand and navigate.

The goal of a user interface should always be straightforward and self-explanatory so that users can accomplish their tasks without confusion or unnecessary cognitive load. For conversational user interfaces, we might need a more general phrase: “don’t frustrate me,” since now users can redirect conversations in many ways. When these common user initiated interactions are overlooked during the design and implementation phase, it is hard to expect users will be effective in getting serviced via conversations.

Parting words

We know how to build good graphical user interfaces now. Given a starting point, usually a menu selection, we just need to provide a sequence of interaction pages so that users can effectively get what they want without having to think too much.

But building a usable conversational user interface is different. You still need to connect the user input to an end state where users get served. But the number of interactions that you need to support is not dictated by you, but by users. If common interactions users expect are overlooked during the design and implementation phase, users can quickly sense that and deem your chatbot unusable. So, for a conversational user interface, you really have to budget enough resources to cover enough common paths, if you really want to reap the benefit of the conversational user interface for your services. Because, during every turn, chatbot’s response can potentially depends on your business condition and logic, not just common sense knowledge.

--

--