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.

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

Our product — atSpoke — 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 atSpoke 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 atSpoke 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 atSpoke 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 atSpoke, thinking they were replying to a atSpoke request, when in fact our atSpoke 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 atSpoke 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 atSpoke app.

However, the introduction of the button didn’t actually change behavior. Users were still replying to atSpoke 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 atSpoke needed to be used for more than simple back-and-forth conversation. For team members, the native atSpoke experience is incredibly rich: the team can respond to requests, collaborate privately, draw from their knowledge base, and train atSpoke 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 atSpoke. 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 atSpoke.

How we chose threads

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


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.


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 atSpoke 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 atSpoke app

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



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

The quieter version “holds” any messages you typed from atSpoke, 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 atSpoke 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 😱



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.



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.



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 atSpoke 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, atSpoke 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!

Resolve tickets 5x faster with atSpoke

Let’s get started

Are you an existing atSpoke user?