The evolution of the SoapBox Slack bot 🤖
(From the guy who built it)
This month marks a big milestone for us here at SoapBox. Two years ago this month, we started building our Slack bot. As a startup focused on being the manager’s toolkit for better one-on-ones, team meetings and company-wide discussions, we knew that a well-made Slack bot had to be part of our product roadmap from the very beginning.
Here’s a look back at how the SoapBox Slack bot originally took shape — and how we’ve leveraged new Slack features to evolve our bot over time.
Starting out
At the very beginning of SoapBox as we know it today, Slack was a foundational component. There was no way to create an account other than through the SoapBox Slack bot. That’s because at the beginning, we didn’t want to worry about building out an email system for notifications. We wanted to keep it simple: you install the bot, make an account, invite the bot to a channel, it makes accounts for all the people in the channel, and done. You’re using SoapBox.
I started building the bot when I had been at the company for only a couple months. Our CTO, Graham McCarthy, gave me high-level direction and the words we wanted to say, and I just kind of went with it. And I’ll tell you — Slack knows what they’re doing. When I first started, I knew almost nothing about JavaScript, which is the language Slack uses, and I was still able to build a bot. If someone who knows almost nothing about the language can build a bot, there’s something there. It’s super intuitive. Of course, things to got way more complex pretty quickly…
Mastering onboarding
At the very beginning, the only API calls we needed were to get user and channel information. I figured we would need to fetch user information a lot from the Slack API, so I implemented a Redis caching layer to cache the user and channel data locally, so if I ever need that user or channel data again, I would just need to fetch it from the local cache instead of asking the Slack API for it again.
We also needed to get channel data. When I first built the bot, there were two API endpoints to get channel data from: one for public and one for private channels. Luckily, they have since created a single endpoint for this, which reduced the amount of logic I had to implement to get channel information.
Once I built the first iteration, I started going through the onboarding. Like, a zillion times. Then I would sit down with Graham and our CEO, Brennan McEachran, and they’d say, “We don’t like it yet. Change this, change that.”
And the onboarding did need work. It had a lot of words — it was very long. Emojis definitely helped with that, and made our voice a little more fun, but we’re always looking for ways to shorten the copy. And we had to figure out the sweet spot of how many questions is too many. How many onboarding questions could we ask them before they’d just stop? And at a certain point, what value are they getting out of the process?
Once you added the bot, the first thing it would ask you if you wanted to set up a one-on-one, or a team meeting. If you picked team meeting, the bot would tell you to add it to a channel and what to do next. If you picked one-on-one, it would show you the command to meet with someone.
But even then, it was complicated. Because when we asked certain questions, we saw the user’s fear of the unknown emerge. If a user chose one-on-ones, the next question was “Are you a manager?” — and if they said no, it would say “Who is your manager?”
People hated that question. One of the anxieties a person has when they install the bot — or really any bot — is that they don’t know what’s going to happen. They don’t know what the bot’s going to do. Will the bot message my manager? Will the bot message the whole team? There are so many unknowns. That’s why now, if you go through the flow and you say you’re not a manager, it asks who your manager is and if it can message them.
It was a matter of combining simple messaging with efficient processes. For example, after the user completed onboarding, we encouraged them to create a SoapBox team channel. To accomplish this, the user invited our bot to one of their Slack channels. When our Bot was invited to a channel, it created a SoapBox team channel in our app, then invited all the users from that Slack channel to our SoapBox team channel.
It’s worth noting here that when fetching channel data from the Slack API, that channel user list only contains the Slack user IDs for the users. Since we needed to create SoapBox accounts for all the invited users, we ask the Slack API for the user data of each user in the channel. Caching was very useful here; if we already had the user data, we wouldn’t have to ask the Slack API for it a second time. Our Slack app only contains mappings between Slack IDs and SoapBox IDs — specific user data like names and profile pictures, for example, are always fetched from the API, then cached so it’s always up to date with what Slack has for that user.
Adding the web app
Other things came up along the way, too. After a while, users gained the ability to sign up and make channels via our web app, not just through Slack. That meant people were creating channels on the web and wanting to link them to Slack channels. So, we had to write a flow to do that.
But then we ran into issues with Slack channels connected to SoapBox meeting channels. What if a user was in the right Slack channel but not in the SoapBox meeting channel? Or visa versa? Should people be automatically added to one channel if they’re already in the other?
We landed on yes — some of the time. If you add someone to a Slack channel that the SoapBox bot is in, they’ll be automatically added to the connected channel in SoapBox. But not the other way around.
Complex? Yes. But it was really about getting a sense for what makes the most sense for our core user — how do we think they’d want the app to work. And then iterating on that like crazy.
Building the Slack Brain đź§
Something technically unique about our bot architecture is that early on, we made the decision to keep the Slack business logic separate from our main application logic. Meaning that if we make a change to our Slack bot, it won’t directly affect the web app. It was a good way to ensure we didn’t break everything at once, but it also meant we had to do a lot of mapping. We have to constantly map Slack IDs to SoapBox IDs. All. The. Time.
So we created a layer in the middle that we call the Slack Brain. Basically the web app tells the Slack Brain to do something, and it tells the Slack bot to tell the user. It’s a go-between mapping layer that handles translation. (Why is it called the brain? When we started this project, we divided the project into two parts: the brain, which does all the thinking, and the Slack bot, which says the words.)
Growing with Slack
It’s amazing to see how much Slack has changed since we started building our bot two years ago.
For example, when we started out, the experience was limited to commands and buttons. Now, there are a bunch of things you can add, like Gifs and drop-down menus. We’re just now starting to play with adding some of that stuff in. So much is going on in Slack now — we’re subscribed to all their newsletters in our developer channels, so every time a new change comes in I see it right away. Each time, I think, can we use this? Can this make our Slack bot experience better? And if it seems like it might, I send it to Graham to get his thoughts.
A great example of something I’m keen to add to the experience in the future is commenting on agenda items right within Slack. When we first wrote the bot, there were no threads in Slack. You couldn’t reply to a message. When that Slack feature shipped, I got really excited. Because you can comment in the web app, but we haven’t made that a seamless integration with the Slack bot. And it would be amazing if when you get a notification in Slack that someone has commented on an agenda item, you could click on it and see what they said. It would be so natural.
One of the next features we’ll be adding to our bot is trying to make it more of a personal assistant and less of an interface just to use our app. Since SoapBox helps you with your meetings, our bot should let you know what meeting you have coming up today. But more on that later…
Our latest addition is the “Add to SoapBox” button. I think it’s probably one of the best things we’ve ever added. Basically, you can turn any message into an agenda item in a couple clicks: click “more actions” beside the message, then click “Add to SoapBox.” Then you can choose what meeting to add it to, and you’re done.
It came about when Slack released a fantastic UI that would let our users add items directly from their Slack conversations right into their SoapBox agenda with minimal effort. On our end, all we had to do was get a list of all the user’s SoapBox meetings and display them in a dropdown in the message action dialog, then display the message that was selected from the channel in an editable text box.
When the user clicks the “Add to SoapBox” button, we take that item and that SoapBox channel ID and create the item in their SoapBox channel for them. The bot notifies them when the item is created, with a link to that item in our app.
This function was a great step forward for our app because it’s moving us more towards a graphical user interface (GUI) and away from a terminal-like interface.
Plus, it’s a real time-saver. Because otherwise you have to be in a channel where the SoapBox bot has been added, and then you have to write the command and then type out the agenda item.
Of course, either option is still faster than switching out of Slack, going to the web app and adding the item to your meeting. But we want to remove as many steps as possible, and to help people keep using the tools they love. That’s what everyone wants, right?
The future of our Slack bot
Pssst….here’s a little sneak peek into the future of the SoapBox Slack bot:
We’re going to be adding AI to the Slack experience in 2019. We want our Slack bot to essentially act as a manager’s personal assistant. The bot will use AI to suggest categories or questions that you should be asking in your meetings and one on ones, based on the content in your meetings. The bot will also try to figure out the sentiment of conversations and determine if it positive or negative.
We can also use machine learning to do things like try to figure out when the best time to send manager notifications. Like, we see that things tend to be quiet for you right around 9:15 each morning — so that’s the perfect time to send you a run-down of the meetings you have coming up that day. It would be so natural.
And I mean, that’s the goal with this whole thing, right? That’s what we’re all about at SoapBox as a whole: make it natural and easy to be a great manager.
With every new launch we ship, we’re trying to do that a little bit better. From the very beginning, our Slack bot has played a pivotal role in making that happen — but we’re always looking for new ways to take things up a notch.
Stay tuned…
Want see for yourself how we’re seamlessly integrating meeting management into the Slack experience? Install the SoapBox Slack bot.
