To bot or not to bot

Everyone is talking bots these days, and they stress good points  —  new interaction options, lots of opportunities for distribution and discovery, and exciting new possibilities to deliver services to users.

While I am happy with people’s excitement with this trend, I also want to stress that bots are a means to an end, and that end is a great product or service for the end user. Done wrong, bots could be as useful as blinking text in old websites  —  a gimmick that no one remembers. There are also other means to provide great services, even over a chat interface, that are not necessarily bots.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":1938403,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"bots,business,enterprise,","session":"A"}']

Keep in mind that

• Bots are only one of several UX features in conversational interfaces
• Bots are a great hammer, but not everything is a nail
• Bots are only as wonderful as the service they expose
• As with all interfaces ,  exposing your service with a bot will not make it awesome unless it is already awesome.

Lets define a bot for this conversation. Bots are digital users within a messaging product. Unlike most users, they are powered by software rather than by a human , and they bring a product or service into a given messaging product via the conversational interface.

There are other extremely effective features within messaging products that are not bots that can be just as, or more, useful than a bot user. We have a few ways you can build an app into Slack that don’t require a bot user but can be equally or even more powerful than a bot user:

• Notifications: Post messages into channel/thread/group.  In Slack we call these Incoming Webhooks and they are great for a one directional information flow.
• Slash Commands: Run a command-line style query or task execution from within the conversational interface. In Slack we call these Slash commands and they are great for simple tasks and queries.
• Interactive Messages: Buttons in chat messages that let you perform inline actions. Check out our roadmap for more info on when this is coming to Slack.

It is all about the service

OK, so the first thing we need to ask ourselves is, what product/service do I want to build? Then we need to ask, what is the optimal way to expose this service?

It might sound silly, but many product managers and developers are so excited about bots that they try to “fit a square bot into a round hole.”

Here are some examples where you might not need to build a bot:

• News notifications
• Alerts (social alerts for example)
• Simple single line task or queries

All of these services can be provided with simple conversational interfaces such as posting messages and slash commands. There is no need for NLP, no complex conversational scripting, and no conversational back-and-forth.

Above: Simple notification do not require bots.

To date, the majority of our integrations are not implemented via bots.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":1938403,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"bots,business,enterprise,","session":"A"}']

When are bots useful?

Bots are useful in cases where it is easier, and more productive, to provide the service via a conversation with this software-based user.

Examples for services that might be exposed as bots include

• Support and help-desk
• Hiring and recruiting
• Personal assistant and team coordination

As you can see, these are more complex types of services that might be “outsourced” to bots.

Bots are useful in cases where the service would be best exposed by talking to someone, or by someone talking to others  —  a support representative, an assistant, a sales rep, a coordinator, and so forth. In these cases bots can automate (some of) these conversations. A bot can also serve as the front line or a liaison between the user and the human service provider. Check out the Xprt app on Slack as an example for that.

[aditude-amp id="medium2" targeting='{"env":"staging","page_type":"article","post_id":1938403,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"bots,business,enterprise,","session":"A"}']

Above: Bot can automate complex tasks

Bots are also useful for keeping context in a conversation — when a user talks to a bot, we can infer context, and that can help deliver the service faster and simpler.

How to test if you need a bot to provide your service

Very similar to wizard of oz prototyping in design, a simple way to test if your service is best exposed as a bot is to actually try to turn it into a conversation with an imaginary assistant. Imagine you are a VP in an important company (I hope you all are) and can source anyone at any time. Now ask yourself ,  would I want to get this service by talking to someone. If the answer is yes, that might be a good one to expose via a bot.

Above: Can you botsource your service?

Think of this interface as an evolution of outsourcing tasks, processes, and workforce. What can you botsource?

The right tool for the right task

Bots are an exciting new interface and a great way to expose some services to users, while others can be exposed via other, more traditional means.

The key point is that bots should be a new interface to an already existing vital and well-designed service, or a new well devised, useful service. In any case, you should strive to build a great and useful service and then decide how to expose it in a conversational interface.

If done right, bots can make our lives more pleasant and more productive.

[Thanks to Noah Weiss, Matt Haughey, and Slack API.]

Amir Shevat is head of developer relations at Slack.