Start building your own chatbot now!

Hi! The purpose of this guide is to help you create a bot from scratch, from the first thought of its existence to its launch in production. This article focuses on the project management and bot building more than on the coding and framework implementation.
This enterprise methodology is used internally at SAP Conversational AI and is based on the way our bot building platform works.

This article is a really good toolbox if you want to build a bot on your own and don’t know where to start! But it’ll also be very valuable if you are a complete team working on bot projects for your own company or external clients.

1. Entreprise chatbot workshop

The first thing we do are bot workshops. For these, it’s important to bring together all project team members (on your side and on the client side, if there is one). Take all the time you need to complete these three tasks before jumping into the technical side. An average of time is 2h-3h for each workshops is estimated, depending the complexity of your bot.

a. The bot functionalities

The first step is to define what your bot will do and what answers it should provide. To do that, we have two activities we want to share with you.

The first one is to write conversation examples from the end-user point of view. That way you’ll see if your bot has multiple conversations on different topics. Think about any way users can reply to a question! Maybe they’ll be satisfied, maybe they’ll have follow up questions or be straight up rude. And also explain how you want users to get information: go straight to the point, or follow a procedure created by the bot?

The second exercise is to take a step back and draw a sketch that represents the entire bot usecase. Try to answer to these questions:

  • What’s the main user goal ?
  • What’s a successful conversation ?
  • What are all features the bot has ? and which is the most important ?

When you have the answers to these questions, write a single sentence that describes what your bot does. It’s typically the first sentence your bot will say to present itself. It’s the same exercise as a preparing a pitch or a kickass tweet.

Here are a few good ones:

SAP Conversational AI - messenger - enterprise chatbot

Now, it’s time to summarize your research to clearly identify the scope of your bot before jumping into the construction of your conversational flow.

A smart and good bot has a clear and defined scope. This can be sketched as follow:


Name each feature and each user intent (try to categorize what they say). The main feature, the core of your bot, can be 1 to 3 different intents, but more isn’t advised.

The extended use case, broader requests, can be different intents, but always keep your focus on the bot’s core use case.

The third circle includes default questions. It’s not about your bot use case but about the company, the maker, or other thing you want to capture during a conversation.

The last one is the biggest and contains all small talk you want your bot to understand: compliments, greetings, goodbyes, insults, weather and pizza related questions (always asked…).

Remember: If you don’t list what you want to understand, your bot will reply “I don’t understand”. You don’t have to set a reply to each sentences but if you can be smarter in your answer than a simple “I don’t understand”, do it.

At the end of this session you have a list of all intentions / features of your bot from the core to the small talk. Learn more about entreprise chatbot design.

b. The conversational flow

Now, let’s focus on the heart of your conversation. All small talk and default questions can be put to the side for now, let’s focus on the main feature.

Ask yourself this:

  • What are the questions the bot has to say to guide the user to the end?
  • What informations will the user have to give to get a great reply ?
  • What are all the steps to reach that goal ?

Draw a diagram, actually draw your conversational flow. Lot of tools are available to help you, such as, Cacoon or SketchBut start with paper and pen first 😉

You can have small separated flows to represent the few different actions in your main feature e.g. get the next train from a station and get the entire itinerary. Take the first conversation example you wrote at the beginning to help you 😉

A good conversation is not more than 2-3 interactions. It’s similar to a website experience! UX designers will say that the number of click to reach the user goal is important: the same principle applies inside a conversation. The number of interactions the user has to go through to get a real answer from the bot is critical.

Here’s an example of a flow:


Once you have your main tree, think about all the possible information you need to complete actions. Have you forgotten something ? Think about the limitations of your use case. In our use case shown before, we need to take false information from the user (like a wrong train station) into account, and handle all errors.

At each step, think about all possible errors and write them to complete your flow.

c. UX & Personality

Now, it’s time to think about the most important part of your bot, the user experience (UX) and personality.

The only interactions your users will have is through conversation, so building a rich and detailed personality makes your enterprise chatbot more believable, relevant and fun to your users. Mapping your personality out into a Bot Persona will help you translate a designed personality into a real ‘job’ use case.

The first exercise is to create this personae according to who your users are and what their purpose is. If you are building a bot to help you find a bar, it will be rather young, talk with friendly slang, emojis, and maybe make some jokes. Describe your bot persona and focus on the tone, the friendliness and the image that represent it. This article might shed some light on giving personality to a bot.

Now that you’ve created quite a character, it’s time to work with the UX: conversation interactions. Depending on the messaging application you connect your bot to, you can include cards and buttons. Messenger is today the smoothest messaging app in terms of UX. 

By paying attention to the limitations in characters, you can now write each bot interaction in detail. Follow your diagram and think about how you want to represent that exchange: do you need cards? Buttons? A text entry? Specify each UX element for every reply.

d. User Acceptance Tests (UATs)

If you are developing a bot for clients, it’s really important at this point to create UATs: User Acceptance Tests. What’s this?

It’s a conversation set that represents the conversation flow. Write 3 or 4 different conversations: one that succeeds, one where the bot is managing false user input, and on when the user isn’t talking about the bot’s use-case. Make sure that all conversations are feasible!

UATs are important for the developer who will code and train the bot as it is the main example he will have to correctly deliver.

They’re also the success conditions of the project for the client before wrap up.

2. Technical design

This methodology is mainly used for innovative bots projects offering a new service to users, and not for an  enterprise chatbot automating existing conversations (e.g. customer support with a large history of conversations). So here you will have to focus on two things: The business logic and the training of your bot.

a. The business logic

Bots are in most cases connected to external APIs and large enterprise information systems. Therefore, a technical meeting is necessary to understand the API, its documentation and what’s possible to use in the bot. Once you have all the informations you can start the technical design. Remember to go from your business objectives to the technical design, not the other way around.

Depending on the tool you use to build your bot, which NLP provider, which channel connector,  your design could be different. At SAP Conversational AI, the first thing we do is to split the conversation flows into real intents. Define which entities will be used to retrieve important information and then create the files architecture needed. If you need a starter kit, I suggest you to try one on SAP Conversational AI GitHub account.

Next, modelize the flow with all the intents in the Bot Builder on SAP Conversational AI. It should be really close to the flow you’ve drawn previously 😉

b. Knowledge base

Each intent in SAP Conversational AI must contain sentences to train your bot to understand user inputs. You need between 30 and 50 expressions in each intent. To fill these intents, you need the entire project team, and especially the business unit and those close to the end-users. Share an excel sheet or give access to the platform to everyone (you can add contributors), so they can help fill the intents directly and train the bot.

This first knowledge base is necessary at the beginning of your bot, the second part of training is different and needs more people 😉

3. Test & Train

Testing is very different from training, so it’s important to have clear idea of what is it.

They can be done alternately: one test session followed by one train session. For each task, work by iterations. First add 2 or 3 people to test/train your bot in your extended team, then in your client team. Then ask 5 friends, then 10 random people and finish with 10 to 20 people that correspond to your user target.

Do it as many time as you need to provide a great experience. We have experienced training and testing time from one week to one month depending the complexity of the bot and the target audience.

a. Test

Testing is about user experience. The main goal is to put testers in the shoes of the users and give them a specific goal, context or mission e.g. “you are a young worker who wants to go to Paris and you don’t know when the next train will leave your station. What do you ask the bot?”.

Testers should try the same flow but respond differently: once explaining a lot of things in replies, once just by clicking on buttons.

The test master (overseeing all testing sessions) has to write down all remarks such as ambiguous wording, unclear images, pain points in the conversation, etc. Try to always have new testers as well as old ones to see your progress 🙂

b. Train

The train task is focused on bot understanding. The goal is not to finish a conversation flow at once, but rather to find sentences that the bot doesn’t understand. The most unmatched sentences found the better is. After training sessions, your team has to enrich the knowledge of the bot by adding all the unmatched logs in intents and improve the bot 😉

The best way for trainers to train is to ask the same thing to the bot in different manners for each step of the conversation. What’s important at this step is to have different trainers, and change them regularly. Keep them in your target audience though!  Young people will not express themselves like seniors. If you have a specific bot such as a bank assistant, young workers will not have the same bank vocabulary than a more experimented manager.

We’re getting closer to the end, but one last best practice. During the first two weeks of the bots launch, train the bot, check the logs and add expressions in the bot training.

You are now ready for the last step: release! Some companies start small with a pool of beta testers and slowly start advertising their new talking service. Others just launch and iterate during the next weeks to adjust! Do as you feel.

I hope you have a better idea of a complete methodology to start building robust enterprise chatbot. If you have feedback don’t hesitate to ping us back! 😉

Ask your questions on SAP Answers or get started with SAP Conversational AI!

Follow us on
  • Maddie

    Hi there great article. Just wondering, what happens if you need to untrain the chatbot – Ie something you have previously taught it needs to change to something new. Do you need to identify every single time a question might refer to to the thing that has changed, and then update it? For an enterprise wide chatbot that seems like a lot of work!

This site uses Akismet to reduce spam. Learn how your comment data is processed.