Customer support in Slack works when Slack is where your team sees and talks about customer conversations, and an inbox holds the record of who owns each one, whether it has been answered and what the customer was told. Give every customer conversation its own thread, make the owner visible on that thread, have one person per shift look for threads nobody has claimed, and agree in advance when a conversation leaves Slack. Teams that drop threads have usually skipped the last two.
How much of that you need depends on which kind of Slack support you run.
Three setups that all get called customer support in Slack
The phrase covers three quite different arrangements, and each one fails in its own place.
| Setup | Who is in the Slack channel | Where the customer writes | Where it tends to break |
|---|---|---|---|
| Team backroom: customers use email or website chat, and the team asks each other for help in Slack | Your team | Email, website chat | An answer gets worked out in Slack and then never reaches the customer, or reaches them twice |
| Mirrored conversations: each new customer conversation posts to a Slack channel as a thread, and the team can reply from it | Your team | Email, website chat, Telegram and others | Threads scroll out of view unclaimed, and the customer's follow-up lands in a thread nobody follows |
| Shared channels: one Slack Connect channel per customer account | Your team and the customer's people | Slack | The number of channels grows with every account, and nothing totals up across them |
The shared channel model is mostly a B2B habit. A thread on r/CustomerSuccess started with someone who had joined a company that talks to every one of its customers, fewer than a hundred at the time, through Slack. On r/SaaS, a founder asked why one tool can't handle internal and external conversations at once. It's a fair question, and the short answer is that Slack carries the messages fine but has no notion of a question being open or answered, or of a customer who has been waiting since yesterday.
Why Slack threads go unanswered
Slack tracks unread messages per person, and a support queue needs them tracked per team. Most of the trouble comes from that gap.
Follow one customer question through a busy channel. It posts to #support at 10:02 and three people see it. One adds :eyes: meaning "I'll take a look", a second reads that as "someone has it" and moves on, and the first gets pulled into a call. At 14:30 the customer writes back with more detail. That reply goes into the thread, and Slack notifies only the people following the thread, so the channel shows nothing new. By the next morning the original message sits forty messages up and the customer has been waiting a day.
Everyone in that story acted sensibly. The thread had no named owner, and nobody had the job of noticing threads without one. The setup below fixes both.
A Slack setup where every thread gets claimed
Use fewer channels than you think. A team of five does fine with two shared channels and one private one:
#supportreceives incoming customer conversations, one thread each, posted automatically. Nothing else is posted at the top level, so anything you see there is a customer.#support-helpis for "can someone check this", for escalations to engineering, and for the warnings your tools send when a conversation has waited too long.- A private channel takes anything involving payment details, ID documents or account access, with only the people who handle those in it. Describe the data and link to the conversation instead of pasting it.
Splitting by topic (billing, bugs, onboarding) looks tidy, and on a small team it mostly creates more places to forget to check. Topic channels start to make sense once different people own different topics.
Give each reaction one meaning
Write the meanings into the channel description. We'd start with three: :eyes: means the thread is yours and you're on it, :speech_balloon: means you've replied and are waiting on the customer, and :white_check_mark: means it's finished. The first :eyes: wins. If two land at the same moment, the earlier one keeps it and the other person says so in the thread.
Handovers happen in writing. The current owner names the next one in the thread ("passing to Dana, the customer needs the March invoice resent") and Dana adds her own :eyes:. An emoji whose meaning everyone has to guess is how the 10:02 question got lost, so hold off on a fourth reaction until three clearly aren't enough.
Put one person on watch
Each shift, one person checks #support for threads with no reaction and assigns them to someone by name. The role rotates, and on a normal day it takes a few minutes an hour. Pin the rota in the channel topic so anyone can see who is watching today.
Set a target you will actually hit, for example a claim within 10 minutes and a first reply within 30 minutes during business hours, and tell the team what it is. A target nobody believes gets ignored. The first response time estimator can help you pick a starting number.
Start with one alert: no reply
Automate one warning before any others: a conversation with no reply after your target time gets posted to #support-help with the watcher mentioned. A warning for low satisfaction ratings can come second. Each extra alert makes the channel easier to mute, and once it's muted the one warning that mattered goes unread too. Skip @here on new conversations for the same reason.
Reply from the Slack thread or from the inbox?
A common rule says never answer customers from Slack. With copy and paste setups that rule was right. Someone drafts an answer in a thread, a colleague pastes it into an email, and the record of what the customer was told ends up in two places that may not match.
Once the Slack thread is wired to the conversation, the rule stops mattering. A reply typed in the thread goes to the customer and is saved in the inbox under the person who wrote it, so it makes no difference which window the agent had open. The replies to worry about are the ones that skip the connection: a DM to the customer's Slack account, an answer sent from someone's personal mailbox, or a reply typed in a channel the integration doesn't watch. Each of those leaves a hole in the history.
Sellio works this way. Each new conversation, from website chat, email or Telegram, opens a thread in the Slack channel you choose. A reply in that thread reaches the customer on the channel they wrote from, and anything posted in the channel itself stays internal, so the team can discuss a customer without the customer seeing it. Assignment, notes, tickets and reporting stay in the inbox. Discord connects the same way today, and Microsoft Teams is coming soon. The Slack support page walks through the setup, and if your team hasn't settled on a chat tool, the Slack, Discord or Teams picker compares them for alerts.
Whatever you connect, test it with a real message before telling the team it's live. Write to your own support address from a personal mailbox, check that the thread appears, reply from the thread, and confirm the reply arrives in your mailbox and the conversation shows as answered in the inbox.
Shared Slack channels with customers
Slack Connect lets people from another company join one of your channels, and Slack's customer service page says it's available on all paid plans. For a B2B company with a handful of large accounts it's a good perk. The customer gets a direct line, and your team answers in a tool it already has open.
It gets harder with every account you add. Each account is another channel that needs an owner, and none of the channels know about each other. Questions arrive wherever the customer happens to look, sometimes as a DM to the engineer they met during onboarding. Answering "what's open across all our accounts right now?" means opening every channel in turn.
If you offer shared channels, a few habits keep them under control:
- Name an owner and a backup for each channel in its topic line.
- Pin a welcome message with your hours and expected reply time, and ask the customer's people to post in the channel instead of messaging individuals.
- Copy anything that changes what you owe the customer, such as a promised fix, a refund or a deadline, into your own record that day.
- Remove the customer's people from the channel as part of offboarding when the account ends.
Keep shared channels for the accounts whose size justifies the extra work. Everyone else can reach you on website chat or email, and those conversations can still appear in Slack through the mirrored setup.
When a conversation should leave Slack
A question that gets answered in one or two messages can live happily in a Slack thread. Longer, riskier or more crowded conversations need a status, a history and one owner, which is what an inbox or a ticketing system gives them. Write your exit rules down and pin them. These are a reasonable start:
| When this happens | Move it to | Why |
|---|---|---|
| The customer has written back more than twice and it still isn't solved | The inbox conversation, under one owner | A long exchange needs a status and a history a thread can't show |
| It needs a fix from engineering | A ticket, linked from the thread and the conversation | The bug can stay open after the customer has been answered |
| Payment details, ID documents or account access come up | The private channel plus the inbox, with anything pasted deleted | Personal data stays out of channels the whole company reads |
| Two or more people are working on it | One named owner in the inbox, the others helping in the thread | Otherwise the customer gets two answers |
| The customer has waited more than a working day | #support-help, with the lead mentioned | By then it's an escalation |
| It's answered and the customer has confirmed | Closed in the inbox, with :white_check_mark: on the thread | Anyone scanning the channel can see what's still open |
Rescue good answers on the way out. When a thread produces something reusable, like the workaround for an export limit, the owner adds it to the help center or the saved replies that day. People rarely search old threads, and on Slack's free plan messages older than 90 days are hidden anyway.
When the whole team should move support out of Slack
If your conversations are mirrored from an inbox, you've already moved the queue and the record; Slack is just where people look. A setup where customer conversations exist only as Slack messages runs out of room sooner, usually at one of these moments.
A second person starts answering customers. That's when double replies and "I thought you had it" begin, and assignment in an inbox ends both. Or someone asks how fast you reply and the honest answer is a guess. First response time and resolution time need conversations with timestamps and statuses, which is what support analytics are built from. Or the intake channel can no longer be read top to bottom at the start of a shift, which usually means the watcher is skimming and threads are slipping past.
You can keep Slack after the move. Put the conversations in a shared inbox, connect it back to Slack, and the team still sees new conversations where it already works. The one case where neither Slack nor a chat inbox fits is phone support. If most of your customers call, you need a contact centre product with a voice channel.
What an inbox adds to the bill
Slack support feels free because you already pay for Slack. The cost shows up when you add a help desk priced per seat. With prices checked on 2026-09-06, a five-person team on Zendesk Suite Team at $55 per agent a month pays $275 a month, and on Help Scout Standard at $25 per user pays $125, before any AI add-ons. Our Freshdesk vs Help Scout comparison goes through two of those options at that team size.
Sellio prices per workspace instead. Mini is $20 a month with 5 seats and Essentials is $95 a month with 10. The seat vs workspace calculator runs the numbers for your headcount, and every plan is on the pricing page.
FAQ
Can I run customer support in Slack without a help desk?
With one person answering and a low volume, yes. Problems start when a second person joins, because nothing in Slack says who owns a thread, and when you want to know your response time, because Slack doesn't count replies to customers. Those two moments are when an inbox earns its place.
Do customers need a Slack account?
Only for shared Slack Connect channels. In the backroom and mirrored setups, customers write by email, website chat or another channel they already use and never see your Slack workspace.
How do we stop two people answering the same customer?
Make the claim visible and enforce it. The first :eyes: on a thread owns it, handovers are written in the thread, and the watcher assigns anything unclaimed. With an inbox behind Slack, assignment does the same job and shows on the conversation itself.
Does a reply in a Slack thread count toward first response time?
Only if the thread is connected to the conversation, so the reply reaches the customer and is saved with a timestamp. A reaction or an internal message doesn't count, because the customer saw nothing.
Can a chatbot cut down the number of Slack notifications?
On website chat it can. An AI agent that answers common questions from your help content resolves some chats before anyone gets pinged. Sellio's AI agent answers on website chat only and hands off to a person when it isn't sure, and usage past the included credits costs extra, so set a cap. Email and Telegram conversations still go to a person.
