Why ‘push’ chatbots in Slack are awesome but ‘pull’ chatbots are more common

Businesses have a million systems of record used for information storage and retrieval. In part because of the influx of niche SaaS solutions, they have so many systems that it’s difficult to organize them and annoying to move between them. It’s not how our brains work and, frankly, moving between applications is often cumbersome. Your comments and conversation on one app aren’t displayed on the other, and if you ever want to move to a different system, have fun with what’s going to be a tedious and manual process.

I won’t cover why Slack has succeeded, but it would be fair to say that email has a terrible user experience. When teams have moved all their conversations to a single place with a decent user experience, it makes sense to aggregate the extraneous notifications and application triggers there. But how do you do that without ruining the efficiency that makes Slack valuable? Slackbots that automate conversations can help, but how do you implement them? How can they make Slack more powerful, and what does “more powerful” mean?

There are 561 chatbots in the Slack app directory and thousands more on other aggregation sites. Chatbot guides are published as often as Donald Trump incites controversy. Yet I’m not convinced there’s any consensus about what makes Slackbots valuable, especially in light of how they usually help users.

There are two types of chatbots on Slack. “Pull” bots require that you initiate getting information; “push” bots are pushy. They initiate the conversation. The pull style bots are well­-suited to Slack, because they help you keep down the noise and notifications that distract from actual work. Unless the information being pushed is something urgent or something you’d otherwise go out of your way to check on quite often, the argument for it being on Slack is weak. That said, as bots proliferate and as larger companies use Slack, tinkering with notifications is going to be increasingly important, which might make users revisit this point.

As a quick example, one of the first integrations our team at Tasytt used is the one Trello provides for Slack. I chose to ignore that channel right away and turned off notifications because I didn’t need to be pulled away from my work each time someone commented on a card. When our team later started using Trello for our agile sprints for software development, we used another channel just for that board, which meant fewer notifications but more important ones. I chose to keep the notifications on for those.

The first Trello integration still has value — at the end of the day I can easily get a sense for what everyone is working on. I don’t have to leave Slack or, if I do, I head directly to the piece of information that I need, the relevant comment rather than navigating through Trello’s notification board. The savings here are mere seconds, but when teams communicate conversationally rather than with something asynchronous like email, those seconds matter.

Truthfully, the mental switch involved in navigating to an external app now feels cumbersome and distracting. It’s like walking into a room and forgetting what you needed to get. It may sound pathetic, like the most millennial problem ever, but the efficiency our team has gained from using Slack is worth solving the problem — especially when bots make it so easy to solve.

When push chatbots help

That said, what most of us really want are push bots that do the heavy lifting for us. We want thinking bots that provide information when we need it. We want chatbot integrations like PagerDuty or anything customer-service related to grab our attention right away.

What we don’t want is a Twitter bot that sends you sports scores or endless GIFs to let the signal get lost amid irrelevant (albeit amusing) noise. If they’re muted, but the curated information is there when you need it, great. Otherwise, overly chatty bots risk diminishing the value of team communication.

Pull bots face none of these concerns. I don’t want Uber or Taco Bell messaging me about an Uber or a taco when I’m not interested — and they don’t. For pull bots, the hurdles are about simplicity and figuring out what a user wants.

Within this subset, there are more or less two kinds of bots. Smart ones with A.I., natural language processing (NLP), and machine learning (ML) that improve over time and can understand any query even if they aren’t designed to act on it. Then there are the unintelligent bots, the Ubers and Taco Bells. These bots might have NLP, but they’re designed to usher a user down a narrow path or two.

So far, the unintelligent bots have the upper hand because unless the brain behind an intelligent bot can handle pretty much anything, it’s like autocorrect in its infancy — funny when it screws up the first time, but annoying when the predictions are wrong more often than not. The problem is when a user wants something specific from a chatbot, they don’t want to start over every time the bot gets confused. In those cases, using a web app would be simpler. When a bot is trying to fake A.I., it’s quite obvious when it fails.

Yet, to justify conversational UI’s superiority, chatbots must incorporate A.I. A bot that takes explicit instructions, makes use of buttons, and offers a few prescribed paths is not that different from an app. It’s novel, but when the novelty wears off I’ll probably go back to ordering tacos on a website. Ideally, the backend A.I., ML, and NLP will catch up before then. With strong interest from giants like Facebook, Google, and Microsoft, it’s a probably a safe bet this will happen soon.

To be fair, implementing A.I. and NLP isn’t simple. Buttons are a great way to bridge this gap, and useful even with stellar NLP. And it still stand that a well-­structured dumb bot is more useful than one with faulty A.I.

Pull bots are well-­suited to straightforward requests that allow a user to remain in their workspace — doing our scheduling, expense reporting, making org charts, and so on. When our team was designing Obie, we assumed the pull features would be the most helpful. We thought the ability to search a company knowledge base or a cloud drive from Slack would be compelling. To our surprise, we found that while people understand pull functionality immediately and use it often enough, they ended up liking push features more.

Get used to the pull bots for now

Given that many push bots are simple, hyper-­curated newsfeeds, it seems ironic that they work, but users like them more when they handle more complex problems for us. One example: It may take more time to develop, but a robust reminder push bot is more useful than an emoji leaderboard that requires the user to reach out and use it.

Our Obie bot sends what we call Flows, which are task lists users can complete in Slack (it’s like email marketing for user training). To find value, a team leader has to create a Flow, attach resources, and assign it to someone.

Trello and PagerDuty both use buttons that work within Slack. They don’t wait for the user. These bots break the rule found in all the style guides that a bot shouldn’t be in your face, it should only speak when spoken to, and it should minimize itself into the background. However, when they provide more value, a little intrusiveness is OK.

We’re just getting started with bots, and we’ve only gotten a glimpse of their possible structures and potential. When the push bots add value, we will use them. Until then, there will be a higher percentage of less-useful pull bots.