Alex Knight

Onboarding is the first set of messages users receive when they start using your bot, the process of preparing first-time users to be successful with your product.​ It’s a promise of the value that the product will provide to the user.

In this article, we will face the onboarding message in a collaborative platform used by multiple bots and users in the same chatroom — ChatOps.

First and foremost, What is ChatOps? ChatOps is defined as conversation-driven collaboration with multiple users and bots in the same chatroom.

When users practice ChatOps, they perform tasks and interact with IT systems and services without needing to login and interact with them directly.​ 
They do it through bots that can gather data, execute commands, use machine learning and analytics to increase employee productivity.

The goals for onboarding are:

· Introducing the bot
 · Explaining why it is worth using- value
 · Overview of the bot’s functionality
 · Drive into action

As regular products facing one type of onboarding scenario (and a difficult one), in ChatOps I realized I need to face two; one is when the user download the bot to the platform (Slack/Microsoft teams/skype etc.), which I will call private onboarding, and the second occurs in a chat-room, when the users meet the bot for the first time, which I will call public onboarding. This is because in most cases in ChatOps, one user downloads the bot for all other users in the team.

Private onboarding:

​Your private onboarding should be a guided experience for your users in which they learn how to use your bot, by using it.

The first and most basic type of onboarding is the private onboarding, it comprised out of 3 sections:

Introduction — The chatbot greets the user & explains why it is worth using.
Commands — This section should be used to communicate your bot’s functionality & commands.
Help — This section of the message gives an option to “expand” the commands section.

Imagine if you were to meet a magician in real life.

Credit: Nikolay Ivanov

This is probably how it would go:

Magician: Hey there Dan! I’m George & I’m a magician, I can do all kind of tricks that will blow your mind! 
I can pull a rabbit out of a hat,
I can grab a coin from your ear,
I can guess which card you chose from a deck!
Want to give one a go? I can do many other things too, want to know more?

ChatOps example:

It is important to choose the most common/relevant/popular commands in the command section. We want the user to think less and do more.

Public onboarding:

Your public onboarding should be a short introduction experience for your users in which they learn what the bot is, what it can do & encourage taking actions. ​​

The biggest difference between the two scenarios is the way the bot performs the introduction, here we add a ‘thank you’ section & the value of having it in a chat-room with multiple users.

In private, the bot explained its value to a single user, but in a channel it presents the value of having it in collaboration with multiple users.

Now, in this scenario I had some difficulties. In ChatOps, you have a chat-room for major incidents that escalated, users and bots get invited, some aren’t relevant and leave, some are invited later on etc.

Let us compare it to a bonfire event with friends, and friends of friends.
Not all are acquaintances. Some join late, some leave. It’s all very dynamic.

We are 12 people sitting around the fire, Mike just joined, I invited him.

Mike: Hey all! I’m Mike, Keren’s friend, nice to meet you.

Everyone responds with a “hey” & “welcome”, and after Mike sits down, some guys sitting near him start introducing themselves with a generous handshake & initiate a conversation.
 When Dan joins later on, he does the same as Mike by introducing himself to everyone. He doesn’t know Mike, and by missing his introduction 10 min ago, he will have to ask him personally if he is interested.

Of course, this scenario can go in all kind of directions, but after running so many in my head, I thought this is ideal for ChatOps. I’ll explain why:

• In the channel, users keep being invited in, the bots might already be in the chat-room, so imagine if every time user gets invited to the room, the bot introduces itself all over again, for all to see. It’s just clutter and noise in the room.
• Scrolling in history will be a reasonable case for our users, as they need to have a look at which commands took place before they came in and their results, therefore, they might see the bot’s onboarding too.
• Users can always ask for the bot’s help to understand what it does.
• The users can see the names of the participants in the chat-room, including the bot’s.

So, I decided the bot will publicly onboard itself once, no matter if some users will join later on without seeing it.

ChatOps example:

If one of the users continues by selecting the help button, we remember that it is a chat-room with multiple people, and provide the help in a thread/system message or a private message. In order to keep ChatOps collaboration and transparency goals, we should provide a “post to conversation” button in the end of the command input that the user executed (‘help’ leads into action).

Last words

ChatOps’ value for the user eventually isn’t the chit chat and NLP with a bot, it’s the commands library and a simple syntax to execute them. The ability to execute commands in a channel for better collaboration, transparency, documentation and efficiency.

The onboarding starts way before the first messages of the bot, by a marketer and a great guided e-mail on ChatOps and its installation.

But the bot must prove its utility down the road. The introduction message is a promise. And if you are in a beta stage or mvp of some kind (we somehow always are), this message holds the opportunity to let the users know it, to be honest with them, and by that, they will be forgiving.