This post originally appeared on Medium.
Buttons open up a world of possibilities to make interactions simpler for users in Slack. Commands that require typing two, three or four words can now be replaced with one press. Action URLs can be packaged in a user-friendly button.
Some of the mocks of how buttons were going to be used by other products recreated button experiences that existed in their web-apps. Others allowed users to take discrete actions on the dashboard from Slack.
Immediately, we had a unique idea for using buttons in our onboarding:
Onboarding is a crucial part of the customer journey. Users want to give your product a shot, but they aren’t fully aware of the world of awesome features awaiting them. You want them to use everything because you know it’s awesome, but how can you possibly educate your user on all the useful things they can do? Not to mention, many modern approaches to this problem, like “guided” product tours, don’t translate to mobile.
Slack buttons give us a unique way to expose each feature, one at a time based on what they found most interesting, across devices. Instead of conforming users to an onboarding process we thought they’d find most interesting, the interactivity buttons enabled a “choose your own adventure” experience.
We think this is just the beginning for how bots will teach users to use them, and develop a path to creating more engagement later on. By placing CTAs to configure Troops in the correct places, we knew we could achieve two goals:
1. Detail each features
2. Get people set up to actually use them
For reference, here’s what our onboarding message in Slack looked like at the time (with two features):
You can see how, with just a few more features, this message was not sustainable over time.
Just a few days after the announcement, our VP of Product, Aditya, had mocked this up:
and sent our product team this message (with a link to the above):
I was up for owning it.
Armed with our perspective on buttons and a desire to work on something creative, I dove headfirst into this project. I knew this was going to be a challenge; buttons are a fresh interaction, sure, but it also means users are not used to using them in Slack.
To really drive this idea of teaching users what Troops is all about with these messages, we began calling Slack onboarding a different name: self-serve learning.
Here is the end result of this mini-project that makes up our current self-serve learning (multiple revisions in between sketches and final!):
As you can see, there were not a ton of changes from V1 to what we put out in the end.
Above all else, we wanted to keep things short and sweet, with a celebratory vibe and nudge to press the buttons. As you’ll see, we’ve stuck with the “introductory emoji” throughout Self-Serve Learning and the rest of our bot interactions. In this case, it’s a 🎉
Using @username in the greeting quickly makes the interaction feel personal, and we transitioned from referring to our bot as Troops Bot, and instead telling the user “now you’re ready to use Troops!” because our product is more than just a bot in Slack.
As for the fun factor, we settled on this specific giphy (which you can see in action below), because who doesn’t like Minions? We also added emojis in our buttons as a subtle way to inject color, especially because Slack’s button styling is limited. To keep things light, we decided against making the bars any color other than gray, otherwise they get a bit too busy.
Finally, we emphasized consistency by keeping our feature names consistent between our marketing site and buttons.
For Salesforce Search, we expose the two Troops commands that allow you to quickly query SFDC and then ask users to configure the feature. In V1, there were 3 CTAs: (1) configuring the feature in our backend and (2) giving it a trying in Slack and (3) continuing self-serve learning.
After a little back-and-forth, we decided to kick out the second CTA to try in Slack as it required the first action to be taken, and in some sense “breaks” the flow of the self-serve learning. Asking your users to do too much is never a good thing.
As users go along through the feature buttons, we only show buttons they haven’t pressed for them to continue through, with a prompt to keep them going.
Personally, Digital Gong is my favorite feature. Gifs for won deals are an incredibly fun way to get your team to celebrate together, no matter where they are, so it was important that we picked a good one (we picked this one of Amy Poehler dancing).
Another nice touch is using the user’s username again as having won the deal. If you can make your user feel like a winner or envision themselves having that experience — do it.
At the end of the message, we give a final encouraging push for the user to finish self-serve learning by displaying the last button.
Conceptually, this may be our most difficult feature to grasp. There’s an underlying assumption that the user actually has Salesforce reports set up, and can imagine a world where they are sent to them in Slack. In the first line, we hinted at the fact that those reports can also be scheduled.
We also have three slash commands for users to call and choose the report they want, which can be cognitively taxing.
With this in mind, we aimed to solve for the second issue, as that is more in line with improving engagement. As users can either call all reports and pick the one they want, or directly call the report they’d like to see, we knew it’d be important to make the distinction (hence the admittedly heavy-handed “OR”).
We thought it’d be nice to end the self-serve learning process with a congratulatory closing message. This appears after a user has pressed the third feature button, and showcases a couple of victory emojis and a triumphant gif.
Of course, we want our users to configure each of our features, so it was important to reiterate all three and have the handy links from before that take them to the Troops’ dashboard where they can configure each.
Reminder Messages (Experimenting)
Much like a re-engagement email drip campaign, we toyed around with the idea of surfacing reminder messages if a user had dropped off during the process.
There was a lot of debate on what the best spacing would be for these message? 24, 48, and 72 hours? Only have two reminder messages and go with 24 hours and 1 week?
It’s an interesting dilemma. No one wants to be the bot that is messaging its users so much that some start considering it spam and just turn it off out of annoyance. Yet, messaging is a whole new paradigm to play in, and with it comes unwritten social permission that does not exist with email, such as an overall faster pace.
In the end, we decided to punt on reminder messages entirely for some of the reasons mentioned above, and so we could get this out the door faster. When in doubt on a non-critical feature, go with the decision that allows you to ship.
Now that we’ve launched, we have numbers around usage of this feature 🙌
Though I can’t share absolutes, here are some relevant percentages for insight into how this feature has done:
So, of all the users who received our Welcome Message, 55.3% actually pressed one of the buttons. At first, this seems like a low number. But I would argue that if you’re thinking about it like an email campaign, you’re thinking wrong.
55.3% does not reflect “open rate” in this case; instead, a better way to think about it would be click percentage.
Subscriber gets an email, and clicks the link to go to your blog / landing page / etc.
User gets our Welcome Message, and clicks a link to continue self-serve learning.
See the similarity?
Here’s the a further breakdown of users who engaged:
There is some room for improvement here. Of the people who tried the mini-feature, over half only pressed one button and dropped off. 17.5% pressed two buttons and 25.3% completed the entire process.
Finally, here’s a pie chart that combines the two above for a better overall picture:
It’s still the early days of bots and messaging as a platform, but user education will continue to be as important as it is with any product.
Self-serve learning for our bot, in its current form, is not perfect. Initial metrics are decent, but there is significant drop off when users enter the flow and there’s no getting around that. Some of this can be attributed to the newness of the experience, but as a product team it’s up to us to overcome that and keep on improving.
As far as iterating on what we have, here are some improvements we may be making going forward:
1. Increasing the value of our “body” messages (Salesforce Search, Intelligent Reports and Digital Gong)
Right now, Salesforce Search is the most pressed button with 76.7% of those who engage with self-serve learning having pressed it. We can improve that message by including a sample search with mock data to show the user what the output would be like in Slack.
The same can also be done with Intelligent Reports by adding a mock report. You could also make the case that Digital Gong should be the first button because of its delight factor. With some light testing, we can glean whether or not Salesforce Search is the most pressed button simply because it’s first, or because it’s the most interesting feature to users.
2. Measuring dashboard actions and product usage relative to onboarding
As a team, we’re actually okay with someone not finishing self-serve learning…as long as it means they configured a feature and are consistently using Troops. If they don’t need us to teach them how to use the product because they find it intuitive, then we’ve done our job anyway.
Measuring what dashboard actions are taken as a result of pressing a CTA link, and subsequent overall product usage, would give us valuable insight into whether or not self-serve learning translates into engagement.
3. Reminder messages
Now that we have some baseline metrics at volume, turning on reminders and tracking the difference in completion makes a ton of sense. Though we may need to do testing around the frequency of those reminders, I’m confident that we can re-engage users without turning any of them off to our product.
We’re excited to keep revising self-serve learning until it results in active and happy users. This little case study is meant to share insight into how we think about product at Troops, and the creative avenues building on Slack gives us.
Thanks to Scott Britton, Aditya Pandyaram, Yelena Reznikova, and Melody Spencer for helping with this post and scoping out + executing this feature.
What do you think about self-serve learning? How would you improve it? Let us know in the comments below!