Building bots for Slack

Share this article

Building bots for Slack

Learn the principles of Slack bot design based on our lessons from building the @pilot bot.

This article is based on a recent talk that I gave as a part of our Pilot Tech Talks series. The recording is available below if you prefer video over text.

There are only a few good reasons to build a bot. The fact that everyone has one is not one of them. Unless you’re a chat bot startup (in which case you may have other problems), the only two good reasons to consider building a bot are:

Acquiring new users 🌱; or

Improving the experience of existing users ✨.

When we decided to build our bot for Slack we decided to focus on acquisition. Our hypothesis was that because Slack’s App Directory was only just announced, being one of the first apps there would help us attract potential customers. That bet paid off.

But if I was building a Slack bot today, I’d probably focus on existing customers. The advantage of being an early-comer to the platform is mostly gone, and existing customers benefit more from having easy access to common platform features without leaving their Slack app.

Visualise what success looks like

Now that you understand the purpose of your bot, you need to decide how users are going to interact with it. The most important rule of thumb here is cognitive efficiency. What interactions that your users have with your product can be simplified with a conversational interface?

A great example of minimising cognitive efficiency is Statsbot with its Google Analytics and Mixpanel integrations. Before Statsbot, when I wanted to discuss our most recent numbers with the growth team, I had to:

Leave Slack

Sign in to Google Analytics

Find the right report.

Take a screenshot.

Go back to Slack and post it to the right channel.

With Statsbot, this entire interaction is simplified to:

@statsbot sessions last week

💥 Boom. Reducing steps required to perform an action by 75% is a great indicator that you’re on the right track with your bot.

Map out all remaining interactions

Once you’ve nailed your primary use case, you need to think about all other ways your users might want to interact with your bot.

Visualising all possible interactions as a map 🗺 will help you and your developers make sure that you have all your cases covered. This map will be the blueprint for your bot, so keep it up to date as you make changes so it’s easy for everyone to reference what your bot is capable of.

Provide examples

Walk your users through the most common cases. They installed your bot, so they clearly think it’s valuable. But if you don’t show them how to use it, they will never experience its full potential.

When we launched our bot, we didn’t have an onboarding sequence. Many users who installed our bot didn’t know how to use it, so they either removed it from their team or simply forgot about it.

Most bots today start a conversation with the user who installed it, showing him how to take advantage of what the bot has to offer.

Announce new features

If someone installs your bot, they think it can make their lives better. As your integration becomes more capable, you should teach your users how to take advantage of these new features.

Many apps send users who interacted with the bot occasional direct messages to show off new capabilities. This is a great opportunity for someone to be reminded of what your bot can do, and how it’s getting better every day.

Important caveat, don’t abuse this channel. Direct messages often trigger notifications, so people are sensitive to receiving them too often. As long as you don’t send them more often than once a month, you should be fine.

Build in a fail-safe

The last thing you want is your users to be frustrated with your bot. A common source of frustration is getting stuck in a multi-step flow because of a misunderstood instruction with no way to go back.

Make sure your users have an ‘escape’ button they can use to go back to your top-level context. This way, if they accidentally go into a flow they didn’t want to enter, they will be able to recover.

Hack something quickly

Your first bot doesn’t have to do everything. It’s tempting to bake in every possible interaction that your app is capable of. Instead, focus on one or two most common flows that can be made substantially better with a Slack app.

Successful bots usually do one small thing really well. Not spending too long on your first prototype will also help you get invaluable feedback from early users.

Cheat if you have to

You may think that you need advanced AI to compete with most bots that are already out there. You look at product shots and see these perfect, natural flowing conversations and you’re thinking—how can we hope to match that?

The truth is, you don’t. Most bots start out with something I like to call human-assisted AI. It’s a nice way of saying we’ll fake whatever we can’t automate. So behind what on the surface looks like advanced AI are often human operators, who take over controls where necessary.

Most startups start on a path where 90% or more conversations are human-operated, and improve over time as they get more data. This is how Facebook M and many other successful bots started out.

Track key metrics

Don’t forget about measuring most important metrics for your bot. When we first launched the Pilot bot we actually forgot to track how many people installed it. It took us a few weeks to realise that we weren’t able to calculate that KPI accurately.

Tweak as you go along

Right now, bots are a fertile ground for experimentation. Your users are mostly early adopters, so they will be more forgiving of missteps as long as your bot is providing them some value.

So don’t be afraid to launch with something that you’re embarrassed by. You can tweak it later. Iteration is how you get from a shitty MVP to a great product.