How to build a useful chatbot

A step by step guide to build a useful chatbot with minimum development

Introduction

Over the last 3 years, my team and I have been working on a chatbot for Match Europe (aka Meetic/LoveScout/Neu/Lexa). Lara started as a simple chatbot on Facebook Messenger and she is now part of the core experience of the dating journey for our user. She is available in 10 countries and speaks 6 languages.

I’m not pretending to know the one and only truth about chatbots, but I’m confident I know one. So I’m going to explain how you could build an impactful chatbot for your business.

We are going to sell pizza to our customers. Because I love pizza and I wanted a simple business case to walk through this.

Start Small, Learn Fast

Iteration is the key. Don’t start by building a complex chatbot that will handle all the business cases you think your users might need.

For our pizza business, we could tend to want to go directly to an amazing chatbot that could do something like this for instance:

- User: I would like something spicy. What would you recommend?

- Botzarella: A Diavola. With salami picante and red pepper. Would you like to order one ?

This would take quite some time to build as it has some advanced features, but you would do all this without any user’s feedback.

You have no idea what you customers need, and you need to learn that along the way.

Build a dumb chatbot to test the waters

You should first check if a chatbot will bring value to your business.

Let’s start with something simple, we will just show the menu to the users. Nothing fancy.

They’ll click on it and they will be redirected directly to your regular ordering system.

It’s not rocket science, it’s not a perfect UX, but it allows you to test the waters. Do you want to invest in a chatbot? You probably do, but it’s always nice to have data to back you up.

To do that, there is not a lot to do. And you could do that in half a day I reckon.

At Meetic, we have built our own tools, from User Interface to language recognition, but this is the subject of a future article. For now, you should start (just like we did) with SaaS products.

There is a lot of options to chose from, and most of them will do what you need. For the sake of this article, I will pick my personal favourites, Dialogflow for the back end and Kommunicate for the front end.

In a few minutes, you can build a simple chatbot like this one:

Each item of the menu will redirect your user to a static menu. For the moment, you cannot place an order directly with your bot but if you can see some traction, you can start a new iteration, and start bringing business actions to your chatbot.

Bring business value to our chatbot

Now that we know our users are talking to our virtual agent, we are going to allow our customers to order directly from Botzarella.

This our target flow.

It seems quite straightforward. You can use Kommunicate’s built-in rich message templates (carrousel… ) so you don’t have any front end development to do.

Your conversational tree relies on Dialogflow. You don’t need a developer to build your flow, and your PO (Product Owner) can do it with little training.

That’s nice, but you have a big problem, what happens when you click on add to cart ? Well nothing happens as you don’t have any way to connect Botzarella to your existing infrastructure.

Here comes the middleware

So far here is the architecture we have:

When our customer clicks on “add to cart”, we want to call a cart service with the customer’s id and its order.

{
  customerId: 'some-customer-id',
  item: 'margherita',
}

To do that, we need to squeeze a middleware between our conversational interface and our user interface

In our conversational design, we can trigger actions as well as text responses. Here is how you configure it in Dialogflow:

So now, your middleware can intercept every response from Dialogflow that has an action and handle it. In this case, it has to trigger the action add_to_cart with parameters { item: 'margherita' }

Before sending the request to the cart service, Botzarella will need to add the userId to the request. You need to configure Kommunicate so that it attaches the userId to every request: link

Natural Language Understanding for smart bot

As you might have noticed, you have created an intent that is triggered by add Margherita and then triggers an action that passes a parameter item with a fixed value of margherita.

That means that you will have to create an almost identical intent for every kind of pizza that you will want to add to your cart. It’s a bit cumbersome. But, of course, there is a way around this.

Use entities to standardize your training phrases

Entities are a core concept of Natural Language Processing, and therefore chatbots. Entities are real-world objects, such as persons, locations, organizations, products, etc., that can be denoted with a proper name. (source). In our case, the entity pizza can have multiple values, such as Margherita, Regina, Diavola….

There is a list of very useful system entities on Dialogflow, but you can create your own. For instance, a pizza entity will look like this:

Once you have done that, you can go back to your original intent and configure it properly this time:

As you can see in the training phrases, “Margherita” acts here as a placeholder for any kind of pizza. The value will be transmitted to your middleware in the action add_to_cart and you won’t have to create a specific intent for every button of your pizza menu.

This concept, which is not reserved to Dialogflow of course, opens up to a lot of possibilities in your conversational design.

From buttons to Natural language

Bravo, your chatbot is starting to look good. The only problem is that it is too scripted. You only have buttons to interact with it. Although it’s okay to have buttons as you often want to put your user into a funnel to bring him somewhere, and users will most likely push a “yes” button than type “yes”, sometimes you might need something more.

But let’s say you have an action to get past orders for a user, so that she can reorder exactly the same thing. You want her to be able to call this anytime. This way you have a non-linear conversation decision tree, just like in real life.

To do that, you can use Dialogflow Natural Language Processing to figure out what the intention of the user input is.

Dialogflow will train a model with your training phrases and will interpret all requests and match them if possible. For instance, if your user says “I want the same meal as last time”, the intent past-order will be triggered even though there is not an exact match in the training phrases.

If you use Natural Language, you also have to configure fallbacks if you can’t figure out your user’s intention.

Once you manage and understand actions, intentions, and entities, there is not much you can’t do. You should always keep your conversational design as simple as possible to avoid the costs and efforts of maintaining a complex puzzle. But this is probably the subject of a future article…

What’s Next ?

As in any business, tracking is very important. Here are some key metrics that you should follow:

• Engagement: Rate of users that engage with your bot. A lot of users open a chatbot and then close it right away, so you should find how many of them send at least one interaction. So that you can change your opening line and sees if it improves the engagement.
• Intents: Log the name of the intents that were triggered. It allows you to understand what the most used features of your chatbot are and where you should put your focus on
• Fallbacks: Log and analyse your fallback. Look at what people said, There might be lots of users who want to use your chatbot in a way you haven’t thought of yet and maybe there is a hidden game changer for your business there…