How Slack can increase the adoption of integrations
By: Samir Javer
Tags: User Experience, Slack, Product Management, UX, Product Design

But an existential challenge for Slack remains; if integrations are what truly set it apart from its competitors (including alternatives like email), how can Slack increase adoption of integrations by its users?

Why is this important, you ask? The answer is Retention, AKA the metric that can make or break your business.

The graph below demonstrates the power of retention; if the pink line is users who’ve enabled at least 1 integration on Slack, and the blue line is users who haven’t enabled an integration, the results speak for themselves. Just 7 days after signing up for Slack, 60% of users who’ve enabled an integration are still around, but less than 20% of the non-integration using cohort are left.

Users who use integrations in Slack are much more likely to keep using Slack, which minimizes their likelihood of churn.

In addition, Slack monetizes the usage of its integrations. On its free plan, workspaces can only install 10 third-party apps, but upgrading to the Standard plan (an extra $8/user per month) gets you unlimited integrations.

This means that Slack is incentivized to get its customers to adopt integrations, because it’s a win-win for both sides; it makes their customers more successful, and it makes them more money.

When it comes to integrations, there are 3 steps to make users successful:

Discoverability

Provisioning

Workflows

In this post, I’ll outline a strategy for each of these, to help Slack get more users using more integrations, more frequently.

In the early days, Slack was mostly used by ‘power users’; tech-savvy knowledge workers who would proactively seek out the App Directory via searches, or install integrations via recommendations from colleagues. The Apps experience lived exclusively outside of the core Slack app, and could only be found via your browser. This worked up until the point where Slack truly started to scale, in 2016.

Nowadays, with Slack catering to all types of customers, including large Fortune 500 & enterprise companies, its strategy needs to shift. It cannot rely on the tech-savviness of a small, flat user base like it could before; Slack is now used by customers of all types, who, on average, will not be as tech-savvy and invested enough in fine-tuning their workflows; they just need it to do their work. Here’s how I think Slack can solve its discoverability problem:

Discoverability

In 2018, Slack revamped its Search feature to become more of a ‘global’ search — not just messages. It could now pull on files, links, channels, and so on. In March 2020, Slack introduced its massive re-design, part of which included a top navigation Search bar, much like a web browser or inbox — to make it feel more like searching the internet or your email. From here, more things could be found in Slack — including your installed apps.

However, the limitation of this is that it only lets you search apps you’ve already installed, which inhibits the discoverability of any net new apps.

What I would propose is, in fact, not much different than how many of us use Google Chrome’s search + address bar. How many times do you use the Chrome search bar as a entry point to solve an unmet technological need; searching e.g. “best fitness apps for iPhone” or “alternative email apps for Mac”?

Now, imagine that same form factor, but applied to discovering what you can do with Slack. Imagine searching “send kudos to teammates” and discovering KudosBot, or “project management tools” and finding out there’s an Asana integration. Below is an example of how Google surfaces relevant content recommendations in its search bar.

Provisioning

From there, my proposed next step would be to allow users to install these integrations, directly from within Slack — rather than have to visit a website.

Currently, the only way to provision apps is from visiting the App Directory at https://slack.com/apps, like so:

I’d wager that most of Slack’s users use its desktop app, not Slack in a browser, and so kicking users out to a browser — where they may need to sign in again (and remember a password and/or use 2FA) — increases the friction of provisioning apps, lowering the installation conversion rate.

In addition, clicking “Add to Slack” from an integration’s page redirects you to the developer’s website, which from there, you have to find the installation steps.

Imagine if you had to do that every time you tried to install an app on the iOS App Store? Surely, many users would get lost, give up, and abandon the installation process.

What if, instead, this could all just be done with one click, inside of Slack? There’s an inherent tradeoff of these developers not getting traffic to their website then, which I acknowledge may not sit well with Slack’s developer community. But perhaps there’s alternative ways to drive traffic for them.

Here’s a great example from Figma, which lets users install plugins directly from within the desktop app:

Workflows

This is the real kicker. If Slack’s users aren’t effectively taught how to actually use the integrations from within Slack, they’ll never use them. This is where I see the biggest opportunity for improvement for Slack.

Over time, I’ve observed that the ‘aha’ moment for when Slack users discover the true power of integrations is in context; when they have a problem to solve, e.g. I need to know what time everyone is available for a meeting.

Most users won’t proactively seek out an integration just for the fun of it; they’ll want to know there’s an easier way to solve a problem that they have.

But the problem is that, because Slack’s integrations live outside in a separate App Directory, its users cannot discover them in context, at the time of need — when they’re inside of Slack.

It’s why I propose Slack builds contextual app recommendations, based on the content of your messages. This is something Facebook Messenger’s “M” bot did quite well (pictured below), though it was shut down in 2018.

For example, say Slackbot detects that a user has posted on a channel, “What time works best for everyone for a call on Wednesday?”. Normally, everyone would chime in on a thread and play an inefficient game of ‘scheduling tag’, e.g. “I can do any time before 3!”, “I can’t do between 11–2”, and so on.

What if, instead, Slack detected that there was a question being asked to request everyone’s availability, and instead suggested creating a poll using the Polly integration? It could even recommend options for the poll, based on the parameters of the initial message (e.g. “I can do 11:30, 2, or 4!”)

Or better yet, if it scanned everyone’s availability from Google Calendar and suggested a meeting time — with the ability to send an invite right from there.

Another example: imagine you @ mentioned a teammate giving them praise about their awesome work lately, e.g. “@Samir Javer, way to crush that sales demo this morning!”. Slackbot could recommend you use KudosBot to easily send kudos to your teammates, which would automatically attach a fun GIF and emojis.

Slack has recently started doing something similar when it detects external links that are supported by an integration, e.g. Google Drive, Zoom, Box.

The second pain-point I’ve observed with Slack integrations is trying to remember what the keyboard shortcut is to use it. Most Slack apps can be enabled with a slash command, e.g. /polly , but the more integrations you use, the more slash commands you have to remember!

Rather than making users type / and scroll through a long list, I’d propose Slack to show the workflows at the top of each channel, similar to the description or topic area — for integrations that are enabled on that channel.

Now, this of course gets more challenging the more integrations you have enabled per channel, but the above gives you an idea of what I’m recommending. Perhaps this could just be done for channels that are dedicated solely to integrations (e.g. #kudos, #lunch-orders).

Measuring success

Discoverability

I’d run an A/B test for all net new Slack signups (so not on existing users), showing the “discover new apps directly in Slack search” feature to ~10% of that cohort, and the remaining 90% would see the existing workflow. I’d run this experiment for ~3 months and measure what the difference in retention was between the two cohorts, after that timeframe (to allow sufficient time for measurable expansion or churn to occur).

Provisioning

I’d treat this like a funnel, e.g. viewed app listing → clicked install→ granted permissions→ successfully auth’d. I’d run two variants of the design in an experiment on three different cohorts: net new signups, existing customers with ≤ 1 integration installed, and existing customers with > 3 integrations installed. For each cohort, I’d see which variant has the highest conversion rate through that funnel, and after achieving statistical significance, if successful, enable it for all users.

Workflows

I’d want to measure the effectiveness of the app recommendations; e.g. the clickthrough rate from recommendation → installation. I’d also want to measure the relevancy of the algorithm, by asking users “Was this a good recommendation?” after either dismissing or clicking the prompt, and get them to react with a 👍 or 👎. Finally, I’d use a metric of # of integration commands used per week by users, and measure the delta in these two before and after surfacing the recommendations.

This is the first in a series of blog posts on how to improve some commonly used products. I’m on Twitter at @samir_javer if you want to say hello!