Replying in Slack while maintaining a distinct product identity

The Slack ecosystem is an incredible place to interact with a large set of devoted users: millions are already there and engaged. The downside? Well, they don’t want to leave! And that poses near-existential questions for companies that are, or aspire to be, more than a Slack-only bot.

Spoke gives teams like IT, HR and Ops a modern interface for managing workplace requests.

Our product — Spoke — was built from the ground up to power the on-demand workplace by delivering immediate access to knowledge and support. We use AI to answer repetitive questions, or find the appropriate team to help, so that the interaction is focused on valuable and personalized help.

One of the ways users interact with Spoke is via Slack. Initially, we started with the basics: let users create new requests from Slack (since those users are already in Slack) and keep them notified of updates to their requests (because it’s faster than email). Yet the minute we introduced Slack functionality, our users began shouting for more! Suddenly, one of our best selling points (our Slack integration) felt like it could be the unraveling of Spoke as a standalone product. After all, if people only engaged with us through Slack, how would they understand our broader product vision, or form a standalone mental model of what Spoke is?

Our early Slack integration allowed users to create requests and ask for common resources.

Every business that integrates with a powerful platform has to choose between these competing priorities: distribution and standalone functionality. That’s true of Slack, but also Salesforce, Facebook, and even Amazon. These ecosystems can provide enormous tailwinds to get a product or brand off the ground, but there is a constant tension. Inherently, platforms pose an existential risk because they can build native functionality (or sell white-label products) that competes with what you’ve built…except they have an undeniable advantage when it comes to distribution.

Inherently, platforms pose an existential risk because they can build native functionality that competes with what you’ve built.

This is a story of how we evolved our product strategy to find an appropriate balance in light of one of the most frequently requested features: replying to requests from Slack.

Where do you draw a line?

When feature requests for “reply from Slack” came in, we spent a fair amount of time in denial. IT and HR managers told us their employees were creating duplicate requests in Spoke, thinking they were replying to a Spoke request, when in fact our Spoke bot thought they were filing a new request. But did users need to reply from Slack? Maybe they just didn’t know to come to Spoke to respond. If that were true, then we could address the problem by making the UI more intuitive.

So, the first thing we did was add a big “Reply” button at the end of notifications.

The first “solution” was to add a big reply button that opened the Spoke app.

However, the introduction of the button didn’t actually change behavior. Users were still replying to Spoke notifications in vain. Duplicate requests were still created. And the requests just kept on coming.

This is when we stepped back and had a difficult conversation: when do we get to “require” users to come to our product, instead of staying in Slack?

And we came to the (somewhat obvious) conclusion that you have to earn your right to a user’s attention, brand recognition, and willingness to engage. Earning our right to do this with casual requesters meant that Spoke needed to be used for more than simple back-and-forth conversation. For team members, the native Spoke experience is incredibly rich: the team can respond to requests, collaborate privately, draw from their knowledge base, and train Spoke to automatically resolve future questions.  We simply haven’t gotten to that level of richness for requesters to overcome the friction of opening a new tab.

When do we get to “require” users to come to our product, instead of staying in Slack?

That said, we still want to be thoughtful about each piece of functionality that we bring to Slack. Our current framework is that simple and conversational interactions can live in Slack, while more involved or complicated workflows fit better in Spoke. From there, it’s on us to have more and more engaging reasons for a user to leave the comforts of Slack to come to Spoke.

How we chose threads

Once we embraced the reality of users wanting to stay in Slack, we started exploring how best to achieve this.

Z-channels

Intercom, Drift, and Olark all spin up new channels denoted by #z-some-channel-name for you to continue the conversation from Slack. The reason they do this is that notifications are coming into a single channel, so there has to be a way to figure out which ticket or conversation you’re replying to. However, having used this ourselves, we found ourselves jumping back-and-forth across channels, and easily forgetting where a particular conversation was happening. The last thing we wanted was more Slack channels.

Reply from a dialogue

Next, we thought about letting that “Reply” button open a modal for the user to type in a reply. Zendesk has a version of this where you can attach an existing message to a ticket via a message action and modal. However, after using a quick internal prototype, we found it jarring to “reply” in a notifications channel, where notifications across multiple requests got jumbled with replies written by the user.

Threads

Finally, we turned to threads. In some ways, threading was an obvious choice: you can neatly sync the whole conversation and organize all the updates on a request under one parent message. What held us back for so long was that (1) companies have very different levels of adoptions of threads and (2) thread notifications are simultaneously loud (more on this later) and hidden. And what we wanted to avoid was going one step forward, and two steps back.

Making threading “work” for our users

At first blush, creating a 2-way sync via threads seemed pretty straightforward, but we quickly realized that this would be a case of threading a very small needle 😅Aspects like user expectations, sensitivity to notifications noise, and different notification configurations all made it much more complex. How should we give requesters a seamless way of replying to their Spoke request, without inundating team members with too many notifications, or worse, not notifying them of important updates?

1. Sync every update across a Slack thread and the Spoke app

In an early iteration, we synced every single message across a Slack thread and Spoke.

Pro:

Con:

Solution: Group updates that you sent and only send it when someone else replies

The quieter version “holds” any messages you typed from Spoke, and picks up again when someone else replies to your message.

To reduce this noise, we now hold on to any updates you post from Spoke and only post it to your thread when someone else replies (i.e., when you are notified). This way, you only get 1 redundant notification instead of 1 for each reply. Users who like to hit ENTER after every half sentence really benefited from this bundling 😱

Pro:

Con:

2. Automatically subscribe the user to the thread and start the thread for them

In our first version, we @mentioned the user and started a thread, inadvertently sending them two notifications for every update.

One thing we wanted to avoid was any regressions in the notifications experience. With Slack threads today, users are only “subscribed” to a thread (i.e. get notifications) if they have replied to a thread, or are explicitly @mentioned. Separately, we wanted to make it super easy to just reply to a thread, instead of hovering over the “…” to start a thread.

Pro:

Con:

Solution: @mention the user in the parent message, and use UI to inform them about threading

The updated version now only mentions the person in the parent message, but requires them to start the thread.

Pro:

Con:

What we’ve learned

Along the way, we did 2 rounds of user interviews (ahead of release), and 2 rounds of user surveys (after each release and iteration). One of the biggest learnings is that when designing for something as dynamic as notifications, it’s hard to “fake it” with prototypes. The feeling of noise, the different sensitivities users have, not to mention the various configurations of notification settings make it hard to be confident up front how something will be received.

We also built a Slack survey! This allowed us to send a short little in-Slack survey using Slack’s dialogues (forms) to users who had received a Spoke request notification. 90% of users preferred the threaded experience after our first release, and after we stopped starting the thread, 100% of new users told us they preferred this experience.

On matters of identity

This particular journey we went on was fruitful, no doubt. If anything it confirmed that our main purpose is to build a product that is useful and delightful to our users. To hear the feedback we got deeply validated this belief. In fact, our goal is never to stand in the way of our users, but rather to carefully consider the strategic choices that meet users where they are and draw them more deeply into our product. Where Slack brings them real-time engagement, Spoke brings them an organized calm, and a bridge to the people and information they seek.

If any of these are also questions you and your company have wrestled with, I’d love to hear about what you’ve learned. Drop me a note at hello@askspoke.com!


See if Spoke is right for you

Get immediate and personalized access to internal knowledge and support.

StockX's IT, HR, and Ops teams auto-close 35% of all tickets with Spoke