Launch HN: Unthread (YC S22) – Customer support, entirely within Slack
Here’s a quick Loom showing how it works: https://www.loom.com/share/8158371d29c84550863adbd6719bb112
Unthread was born out of a failed B2B SaaS startup that we were running for about 2 years. We found clients preferred sending bug reports and feature requests through Slack instead of email or the Intercom widget embedded in our app. This was great for us - Slack is a tool we were already using every day, it’s quick and easy to respond, and it’s less formal than composing an email. The problem is that chat != ticketing, and we struggled to keep track of what needed responses or follow-ups. We used a combination of “mark unread”, “remind me”, and DMs to try to triage, and things still slipped through the cracks.
We started building Unthread to manage our own customers’ requests inside of Slack. After piloting with other companies in our YC batch who were having the same pain point, we decided to pivot to it being our product.
Unthread automatically tracks incoming messages to a channel. We use some basic NLP to determine if it’s an issue or a friendly hello. If it’s an issue, we create a ticket, assign an owner, and send a private message to the assignee that they need to respond. We have an “inbox” in Slack where you can see all of the open conversations that are assigned to you, manage the status of each conversation, and close them out when you're done. If you’re also doing email support, you can forward emails into a Slack channel where reps can compose a response to be sent via email.
The unique approach Unthread takes is that none of this is visible to the end customer. We use a combination of ephemeral messages (only visible to your team) and DMs to keep things private. Customers don’t want to talk to a chatbot, so we help support reps provide real responses to customers by giving them the tools behind the scenes to organize and collaborate.
We also have an escalation system (think PagerDuty for Slack messages) to notify a backup person if there hasn’t been a response in time. You can configure this on a per-customer basis to set shorter SLAs for more valuable accounts, and we’re working on adding rotations of who’s the primary point of contact.
Anyone in the HN community can install the Slack app directly by using this special link: unthread.io/?referral=hn.
We’re excited to hear how this resonates with folks’ current experience using Slack for CX! I imagine there are some opinionated workflows out there :)
57 comments
[ 3.0 ms ] story [ 115 ms ] threadSo many of our support cases end up with a Slack thread to discuss, triage, get subject matter experts to chime in.
Syncing this discussion back up with the case and the customer is a real chore.
How do you integrate with ticket systems? We still need a Salesforce Case as the source of truth for a customer interaction.
With Salesforce owning Slack, you’d think they’d have some deeper integrations by now but alas they still feel totally separate.
Happens all the time with these popular services within other popular services.
The Salesforce acquisition spices things up a bit, but Slack's been great at supporting developers in the same way Apple did with the App Store
– Devtool SaaS (engineers want to debug over Slack)
– High-touch SaaS (software with a strong services component, like tax software)
– Agencies (sales & marketing agencies use Slack as primary ticketings/comms platform)
- Is there a workflow to use this for a support@ email inbox? (& which pricing tier is that a part of?)
- Is there support for customizing an auto-response to those emails?
– Yes there is. This is available for any tier
– We currently have auto-responses for Slack messages. Auto-responses for emails is on the way!
1. Does the customer have to auth the bot at all?
2. What permissions does it need?
3. How's your infosec policy? Have you gone through a SOC2 yet?
4. What about Teams?
5. What about single channel guests (our workspace and theirs)?
1. No they do not
2. We require quite a few permissions, but they're all deliberate and we only use what's absolutely necessary. We laid out some detail here: https://unthread-help.notion.site/Connecting-to-Slack-36a42b...
3. Because this derived from a previous enterprise SaaS app, our infosec policies are nicely buttoned up. Going through the fun of SOC2 now :)
4. It's coming! The first thing we're building is a relay so you can use Slack to talk to customers in Teams. Down the road, we'll consider building the same inbox functionality native to Teams, but we're waiting to see demand first.
5. Yes this works! You can even treat your team members as customers for internal ticketing systems (like IT or HR requests).
So your image of Unthread => Other apps is the reverse of where the industry is going. You need the other direction where any number of channels get funneled into Unthread.
It's true that we use a bot user in channels - we do this to help synchronize conversations that happen in Slack with other systems. We figure that conversations happen in Slack but often get shared elsewhere. Abbot only responds if customers set it up to do that.
Good luck with your launch!
You can apply this to channels and do more intelligent notifications than Slack does. Like if a Director or higher posts in your team's public channel then kick off the Pagertree notification. Or if a post has gotten 10+ replies in 5 minutes.
Can't tell you how many times I've been late on important messages because Slack's notifications are coarse and terrible.
Kind of an interesting idea to use different SLAs depending on the role of the user who posts. Or maybe exclude people who you know won't add anything to the conversation.
- Shared Gmail accounts
- Front App
- Zendesk
- Streak for Gmail
to handle customer support/customer success, I can tell you that Slack is probably not a tool that will allow you to scale!
Here's why.
When you do customer success, you usually have to have multiple people in the team handling a customer ticket.
You need to be able to quickly reference other tickets and run automation to be effective.
I use Slack daily and have used it since the early days: Searching for things on Slack sucks plainly. Threading is either you love it or you hate it. You want to flag a message to another person -so they can see it later, perhaps because they're in a different timezone GOOD LUCK.
A parallel could be this: imagine not having A/C and living in hot country like Texas... yeah not fun if you're trying to be productive now is it. (source: me, I tried. NOT FUN)
And I am not talking about the ui: there are multiple interfaces to filter/refine your search instead of being in a single localized page; additionally it would be better to be able to modify your search and view the results side by side, so that you immediately figure out if your new search params are better than the previous ones without having to go through a couple of clicks..
I am so surprised that no one has came up with better search in Slack in so many years, I could literally come up with a better search spec in less than a month - given search is something that is used AT LEAST once a day by people in our org
> +term "exact term" in:#channel1,#channel2 filter:reaction1 OR +term2 "required term" in:#channel1,#channel2 filter:reaction1
another concrete example I just ran:
> "my-store" in:#general
is gonna return 3 correct results and then a bunch of gibberish although I specifically requested for the exact term "my-store"
Now I was never in a huge huge CX environment but internally we had a thing that was like Unthread and things were findable. Ultimately this was because people were serious about typing out things so you always had multiple axes to find things (and general policy of "write out the username to identify people" etc.)
Tools should help, but it's a combo of tools and a culture of regularity that really gets people to be performant and gets away from the "digging endlessly for that one convo" flow.
And slackbot would dutifully notify every participant that the thread was archived. And there was no way to disable that "feature", even after talking to Slack's customer support about it.
And it drove me insane.
I had to have slack notifications work, because that was the primary method of communication for my workplace. And my notification stream was being constantly polluted by slackbot!
---
The lesson here? Let your users change their fucking settings!
Why is this so hard to understand? You can't decide how a company is going to use/abuse your product, and the employee working at that company probably can't either. So let them configure your product!!
Especially when it comes to notifications. Every app that makes a notification should provide settings to disable them at a bare minimum. How did we get so bad at this? It's fucking obvious, isn't it? Don't you hate having your life get interrupted by some bullshit notification you can't disable? How are you OK with doing that to anyone else?
Yet somehow this is the norm. Very few sms apps let you mute group texts. My Samsung phone buzzes at me in the middle of the night to let me know it disabled some unused apps. And I can't even disable that notification! How did anyone let that shit fly through QA?
---
Anyway, sorry for getting so upset in public. It's been years, and I'm still not over it.
Notifications suck hard, right in your face, and it's for no good reason in the first place. I'm tired. Aren't you?
This feature isn’t marketed by Atlassian. It Jira Service Desk provides the “backend” to the support experience, providing private comments, threads, the ability to merge multiple conversations that pop up in Slack, and link up support requests to active development in Jira.
The only downside is I believe JSM is limited to 5000 external users. Not a huge issue for B2B Success. Considering a external user is only created when a support request via the :ticket: emoji is used.
This system could work for any chatops style of work (Slack, Teams, GChat), incl. within the company where team A supports teams B-Z. The plethora of unmanaged threads is like a parasite and team A does not realize how much support work they really do as chat threads are just threads with 0 stats. Being able to mark ongoing/finished/stalled threads and create tickets/new issues out of these is highly valuable for managers of chat-support teams.
Would love to chat and share any learnings
At my previous employer (Chime, 1000+ employees) they built many slack tools/integrations/bots/etc to help scale their POps team.
One question - how does it deal with people sending 5 separate messages on the same "issue" - we unfortunately have a bunch of clients that seem to be allergic to Slack's thread feature...