Build an AI chatbot for your team in 10 steps

Building a chatbot has become relatively easy with many dedicated tools, but to make an internal chatbot for work can be a tall order. Of course it needs to be ‘smart’ and personalized, but crucially it must overall become a tool that employees prefer to use over the ‘old’ way to get a task done.

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:

Use case🍕 Order pizza
User stories📞 Making a new order
⏰ Checking on the delivery status
🗯️ Complaining if it wasn’t right
💰 Getting deals

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.

Chatbot use cases can be broken down into phases of a life-cycle

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

A) Anytime

  • What are the relevant policies? Typical annual leave and leave that’s mandated by the government, like Jury Duty, could have different policies. For example, Canadian public holidays, maternity leave, or religious holidays could all just affect a part of your workforce. You should collect all these and check if some of them are only relevant to some employees.

B) Before request

  • How much leave do I have? HR or Shift-planning software usually has a tally of how much allowance everybody has. Find out what applications are used.
  • Who can I speak with if I have a question? Depending on the stage of the employees’ request or the nature of their question they may need to speak to HR, or their supervisor, or to IT. Find out who would be responsible at each stage.

C) Making a request

  • Where is the form? Is there one central form or different ones depending on the type of leave? Get the direct link(s)
  • Can the form be submitted via API? This can sound technical, but for outside applications like a chatbot to be able to make new submissions, the HR portal needs to accept ‘incoming’ requests. Check if your application has an API. For example, if you have Workday you can google “Workday API” to find out.
  • If you know there isn’t an API, there is a good chance that by updating a respective application, you would add one.

D) After the submission

  • Can requests be changed after submission? This again comes down to whether the HR software allows edits to requests.
  • Can the employee check the status of their request? Does the HR Portal show at which stage a request is?

E) After the decision

  • How will the requestor be informed about the outcome? Would it be possible to forego email notifications in favour of an Assistant delivering a notification? (Reduces email overload.)
  • What’s the procedure for processing requests? Will there be Out of Office messages, answer machine announcements and calendar events created to notify colleagues and clients about an absence?
  • Will relevant work be accessible to a substitute?

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:

User storyUsefulness score
Asking about different policies2
Looking up your allowance3
Filling out a new leave request form3
Finding out who the right contact is3
Changing the request after submission1
Check the status of on-going requests1

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.

Graph showing relationship between static responses and user happiness for chatbots

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:

User storyUsefulness scoreFeasibility
Asking about different policies23
Looking up your allowance33
Filling out a new leave request form32
Finding out who the right contact is33
Changing the request after submission11
Check the status of on-going requests12

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:

Combined scoreUser storyPossible questions/commands
6Looking up your allowance– How much PTO do I have left?
– Can I request any more leave?
– Show me my annual leave allowance
6Finding out who the right contact is– I’ve got a question about annual leave
– I need help with leave policies
– Who can I speak to for questions about leave
5Filling out a new leave request form– Request 2 days off for me
– Start a new leave request

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:

Microsoft Bot Framework

An entire chatbot platform (named LUIS) geared towards supporting customers. Most people start with the QnA Maker that transforms FAQ sections from your website.

Plus symbol Easy to get started
Plus symbol Supports Microsoft channels (Skype, Teams, etc.)
Minus symbol Little support for non-Microsoft chatbots


Formerly known as this product is made by Google and it’s conversational skills are pretty good. It can be deployed to most non-Microsoft products quickly, e.g. Slack, Cisco Webex.

Plus symbol Best Natural Language understanding
Plus symbol Supports many channels
Minus symbol Harder to teach false positives compared to Microsoft LUIS is owned by Facebook and it’s generally considered to be a more conversational bot offering even GUI that can visualize different ways a conversation can flow.

Plus symbol Easy to create ‘natural’ feeling conversations
Minus symbol Consumer-first platform, thus enterprise sources could be a challenge


Botpress is a very popular, as open-source alternative to the ‘big brand’ chatbot platforms.

It’s got a lively community and is packed to the brim with features.

Plus symbol Installable on-premise (important for many companies)
Minus symbol Steeper learning curve as it’s developer-oriented

adenin Digital Assistant

Note: This is our own product.

Digital Assistant is made specifically to handle many intents, offer easy NLP configuration and fulfil requests through API calls.

Plus symbolSpecifically made for employee-facing applications
Plus symbol Installable on-premises

To start we first create a Digital Assistant account by going to, which is free.

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

Creating custom Cards in Digital Assistant's admin view

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

Creating a QnA Card in Digital Assistant

Under Question fill in the first question we noted, then enter more questions or commands using the Add-Digital-Assistant 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.


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.

Connecting your business applications to Digital Assistant takes only a couple of clicks

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

Creating a QnA Card in Digital Assistant

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
Example signage for a new chatbot in a SharePoint intranet
Example for digital signage for the chatbot. Photo: adenin

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 😉

Related Posts
A cockpit showing instruments
Read More

10 best SharePoint integrations

Having always been a popular Intranet platform, in recent years SharePoint has become ubiquitous. In part thanks to…