Build an AI chatbot for your team in 10 steps

If you’re wondering how you can create an AI chatbot for work, there are just 10 steps you need to follow to make it a success.

In this post I’ll walk you through this process and hopefully, by the end, you have an MVP chatbot for the office, and learned the techniques to improve it continuously to ensure your team will love it.

Collect possible use cases

First we start off with a blank piece of paper, which could look daunting. What, oh what, should your chatbot do? It’s simple: Think of things you have to do at work but that really frustrate you: Which of those are so menial or long-winded that you just wished you could pass them onto a personal assistant?

Then ask a few colleagues in your team the same question, maybe try and catch someone at the water-cooler or post your question to your organization’s chat room. You may find that, very quickly, you have more ideas than you needed. Examples could include:

• Looking up someone’s phone number
• Connecting to an online meeting
• Figuring out how much leave allowance I have
• Booking training and classes available to me
• Finding out what’s for lunch
• Reporting faulty IT equipment
• Checking customer payment status manually
• …

Almost all these have high frustration potential for users, so this is probably the easiest step of this guide.

Map out user stories

Next up you need to figure out the ‘user stories’ that together make up the ‘use case’. Say, if your use case is ‘Order pizza’ then within that, there would be user stories such as:

As you can see all these user stories would require separate attention when creating a chatbot for your team. Alas, we’re not creating any pizzas here, but instead we shall pick an example that, as almost anyone can confirm, is far less delicious: Leave requests.

Many employees find requesting leave quite challenging, beginning from finding out your allowance, over finding someone who can assist you with your request, to eventually submitting their request.

This obviously qualifies leave requests quite nicely to get a smart Leave request chatbot overhaul. However, since it’s multiple degrees more complex than ordering a pizza, we need to map out all the ‘user stories’ in different phases that describe how far off the user is from the finish line.

So in the table below that’s what we’ve done:

What we haven’t even considered is the manager. What would they ask the chatbot? How would they be able to approve or decline a request?

Strictly speaking we’d have to make a separate table just for that – but as you can see, even the seemingly simple user view quickly spiralled into a lattice of user stories, variables and conditions.

Any chatbot for work will have to take the friction out of this process for the user; or else it may not be viewed as useful enough for the user to come back in the future.

Industry secret:
Chatbots Journal found that failure to reduce friction is said to be the most common cause for eventual enterprise chatbot failure. So if you’re going to invest time into making one, make sure it’s addressing an actual problem in users’ lives.

Assign usefulness score

Now then, the next question is: Which parts of the above should our chatbot actually handle? Can users ask policy related questions, check their allowance, and submit new requests? Only some of those?

To answer that question you should list every single user story and assign it a usefulness score:

3 – Absolutely essential use case. Without this the chatbot won’t be remotely useful.
2 – These are definitely common things people might look for.
1 – Offering this use case would be good, but 80% of the time you probably won’t need it.
0 – This is probably so rare we can just leave it up to a human contact to resolve that.

Say this means we arrive at the following list:

Assess the technical viability

Now the big issue is: Can you actually do it? Many chatbots can answer questions, but they’re usually generalized answers or contain links to articles on the Intranet. That certainly gets you out the door with a MVP chatbots quickly…

But you cannot have a canned response for everything. Someone’s actual allowance should be given to them straight, not as a hyperlink to get it somewhere on the HR portal.

Similarly users want to enter their leave request straight into the bot, not be redirected to the boring ol’ form on the Intranet (which probably wouldn’t be mobile-friendly anyways).

Generally, you can say that any user story with a usefulness score of 3 should absolutely be supported in the chatbot.

Everything with a usefulness score of 2, you can resort to those ‘canned’ responses (at least for your first iteration). And everything with a score of 1 you can actually ignore for your first MVP of the chatbot.

If you don’t follow this crucial rule and have too many use cases simply ‘canned’, then it’s unlikely that long-term your employee-facing chatbot will see the user adoption you want. (Which makes sense if you think about it: Colleagues just won’t get enough of a benefit from using this new work chatbot, so they won’t re-learn that the chatbot can make their lives easier.)

You could use this scoring system:

3 – The information is either available via API/database or if we’re talking about submitting a form, than that is possible via API
2 – The information exists but can only be linked to
1 – This user story is not even supported in the current desktop application

With that in mind let’s score our user stories for technical viability:

Priority score

Great! Now, if you add both columns together, each user story gets a score out of 6. This automatically gives you a good indiciation of which user stories we should pursue first:

6 – Needs doing and can be done
5 – Needs to be done as well, but may not be as easy
4 – Should be done, but perhaps simpler ‘canned’ responses suffice
3 – Technically still a good addition, but can/must wait for a later iteration
2 – Less useful, so unless you find an easy way to integrate that you needn’t bother
1 – Not the best use of your time at this point

Build up the AI training model

Chatbots need to be able to understand natural language, also called NLP. So in order to be able to ‘train’ our AI, we need to start writing down all questions and commands you can think of that people might say in order to invoke the different user stories. So for our example:

Start building the chatbot

If you’ve come this far, you already discovered that a chatbot for work that’s simple to use for the end user, could be quite challenging to get right for the creator, i.e. you.

Now, however, we start to actually build our internal chatbot. And this is where all the previous steps will make our life a lot easier.

But before we can begin, you need to decide on a platform to build the chatbot on. While we’re going to use Digital Assistant in this example, here is a list of other popular tools and what they are:

To start we first create a Digital Assistant account by going to www.adenin.com/register, which is free.

Once that’s setup and you’re logged in go to Custom Cards and then Create.

Then we simply start with the top user story from our table above; in this case Looking up your allowance.

Under Question fill in the first question we noted, then enter more questions or commands using the symbol.

Next, enter a Text Answer. This will simply be the sentence the chatbot should feed back to the user. You’ll notice the bit where it says {item.allowance}, which we will cover below. Basically this is going to be the placeholder that we dynamically mix our answer into.

The next step is that we need to make our questions smarter, by upgrading them to so called ‘utterances’. Basically the problem is this: If you ask the bot about “PTO” it doesn’t know that’s the same as “annual leave”, unless we tell it that.

So we go back to our questions and rephrase them using a certain markup to teach the AI what these synonyms are:

• Can I request any more (annual leave|PTO|time off)?
• Show me my (annual leave|PTO|time off) allowance

As you can see using parentheses ( ) denotes options and the pipe symbol | separates the alternatives. Two sentences like this alone should already make for a great foundation for our AI (of course later, as more people use it, we want to tweak the AI further).

After that, we’re good to go ahead and Save.

Data-binding

So far in this guide I always talk about how ‘canned’ responses are a crutch and, if overused, can doom your chatbot right from the start as it won’t feel useful to users.

To actually change that you need to bring in what is called data-binding. Basically data-binding puts the X in “You have X days of leave left.”

Depending on the quality of the API, data-binding can either be a 5-minute job or it can be a 5 day engagement; which is why you need to carefully consider which APIs allow you easier access than others.

In our example, thankfully, the integration is just a matter of adding the Annual Leave Card to the Digital Assistant.

Just click on the Add to Digital Assistant button, and select the service provider you use for your HR.

Digital Assistant than asks you to Install and will take you through the setup process required for your service, e.g. oAuth authorization, etc.

You could now even go back to your Card and insert a helpful direct link into the footer of your Card so users can directly jump to the HR portal in case they need to manage requests.

To do that, just head to the Link tab and then enter a direct Url and button label Text, before you hit Save.

Deploy chatbot

We’re nearly done, and this step should be relatively simple with most chatbot platforms. Channels are separate ways in which users want to interact with the bot. You are potentially looking at over a dozen of them:

1. Chatbot’s own app (If there is one)
2. Your company mobile app
3. Slack
4. Microsoft Teams
5. Workplace by Facebook
6. Alexa
7. Google Assistant
8. Integrated into SharePoint or your Intranet
9. As a handy browser extension

Not all of them will be of interest to you and, indeed, for an MVP you should either:

1. Deploy the chatbot to those channels you already use throughout the organization (i.e. as a Slack app if you use Slack)
2. Use a web app (either out-of-the-box or self-made) so you can embed analytics scripts and record how users interact with the chatbot

Depending on which platform you have chosen to build the chatbot with, some of these channels should be close to a one-click deployment.

With Digital Assistant all you have to do is head over to the Channels section and enable those channels you want to support.

Each Channel will have its own instructions to authorize the Assistant and enable the bot user for the respective application.

To test, head over to, say, Slack and add your new chatbot user and ask it “How much PTO do I have?”

Congratulations! Now we’re ready to rumble!

10. Release MVP

This part will definitely be the most enjoyable one. All you have to do is invite some beta testers from your organization to try the bot, and deliver their feedback to you. Here are some tips you could consider:

• Announce the bot through the same channels in which it’s available, i.e. on Slack if you use Slack
• Set up a survey beforehand and ask users continuously to fill it out and let them know how to reach you if anything goes wrong
• Collect user ideas and maybe even let them pick features from your existing roadmap they would most like to see implemented next
• Consider either naming your bot (i.e. Leavey the Leave Bot) or start a naming contest
• Create ‘digital signage’ that you can post like a banner in your Intranet (see example below). If it’s visually pleasing and interesting people will be sure to give it a try

Now you’ve deserved a pat on the back. Internal enterprise chatbots are the most complex form of chatbot as they need to transact data between multiple, secure systems so you have a bunch of overhead with APIs, authentication, etc. that make these pretty hard to pull off.

Hopefully this guide was helpful, and if you have any comments be sure to leave them below!

Oh and to add more use cases just repeat steps 2-10 as often as you like 😉