I’ve been building bot for more than a year and a half now. Hell, I’ve been building software that build bots for even longer. And yet, in these past 24 months, I’ve been hearing the same things. They all amount to building a good bot is impossible. Or it’s a freaking nightmare at least.

LANGUAGE IS A HARSH MISTRESS

It has to do with the fundamental nature of language: there are too many things to think of. Building a good chatbot means imagining a full conversation, in all possible languages. It means creating a bulletproof user experience that guides the user through the flow, that has personality and charm (but not too much), humor (but not too much) and knows about who it’s talking to (but really not too much).

It also means taking into account all possible outcomes at every step. Picture this: when I ask a friend “do you like sushi?”, their answer could be “yes”, “no”, “I don’t know”, but also “I hate snow” or “ice castle”. As a human, I’m equipped with a language dedicated part of my brain, five senses that can conjure a sense of context, and a knowledge of all basic things that make human life. My bot, on the other hand? It knows what it’s taught. And I’m definitely not teaching him about snow, ice castles or anything related to Frozen when he should be ordering sushi.

It is particularly important for chatbots to do one thing and do it well because they handle an input as beautiful as it is evil: human conversation. – Lucas Deschamps, The Art of Bot Design

CAN WE MAP A CONVERSATION?

Today, the system used by all bot building platform that uses Natural Language Processing (NLP) is based on intents and entities. If you’re not really comfortable with these two concepts, this article will get you up to speed. Building a system that adapts and manages all possible outcomes is very complicated with only these two concepts. They are powerful tools, don’t get me wrong, and work well to analyze and classify language. They, however, aren’t really efficient at managing a conversation. And when using them in bot building, you can quickly get awfully complicated structures.

They also don’t allow a strong adaptation to user speech. See these three versions of the same conversation:

Our human brains automatically do “oh good, he gave me all necessary information” or the “I’m missing the order number, I should ask for it” gymnastics. Current chatbots require an extensive setting to handle this.

We can avoid these struggles if we start thinking in objects.

FROM MACHINE LOGIC TO HUMAN LOGIC

A conversation is made of sub-conversations that all have a very specific purpose. It is the exchange between all these sub-conversation that creates a global interaction. Therefore, when building a bot, start by identifying the things you want it to master. Want to complete an order? To provide data? To obtain information from the user? Think object-oriented programming.

And then, determine what information you need from the user, how should such object be triggered and how it should be considered completed. This allows you to build very adaptable flows.

Building bots in bricks is like working with containers. It’s much easier to update, maintain and test. It makes collaborative work possible and allows you to share prebuilt blocks with friends and coworkers.

THINKING IN OBJECTS

Let’s consider a pizza bot. Its purpose is to autonomously process client orders. If we only rely on intents and entities, the flow of the bot would be long and complex, where we’d ask many questions without any flexibility:

the number of pizzas ordered

which flavors

which size

what’s your name?

what’s your phone number?

That’s more a doctor interrogation on your dietary needs than anything else.

But by thinking in “what are the main steps of my conversation”, it’s possible to make this workflow much more flexible. Our whole flow would be broken down into several objects:

Order-main: Builds the flow of the order and links to the other objects.

Builds the flow of the order and links to the other objects. Pizza-amount: Fetches the amount of pizza desired and triggered the pizza-order object as many time as required.

Fetches the amount of pizza desired and triggered the pizza-order object as many time as required. Pizza-order: Orders ONE pizza. It fetches its size and desired flavor.

Orders ONE pizza. It fetches its size and desired flavor. Contact-info: Collects the user’s name and phone number. (Only on the first order)

Collects the user’s name and phone number. (Only on the first order) Order-send : Sends the full order to the server, once the client confirms.

: Sends the full order to the server, once the client confirms. Order-cancel: Let’s the customer cancel its order. The different objects in pizzabot

WHAT’S IN IT FOR YOU?

All in all, thinking in objects brings you many things:

A more organized bot flow

A very adaptable bot capable of managing unexpected situations much better

Much easier testing, as every object can be tested independently

Much easier iterations, as you can just keep on building new objects to expand your bot

And a greater peace of mind because everything’s clean, everything’s clear, everything’s organized.

We’ve reflected this way of building bots on SAP Conversational AI, but it is a design concept all bot makers can use to prototype and clearly define their use case.

The next step in the world of conversational interfaces is to modelize bot flows from existing conversations. Surely, all major companies have extensive conversational datasets that they can use to provide really spot-on conversational experiences. We’ll get here sooner than you think.

Happy coding!