Slack Connect customer support: a practical guide

The first shared channel usually starts as a favour to a large customer. Their engineers get a direct line to yours, questions get answered in minutes, and everyone likes it. Then a second customer asks for one, then a tenth. Somewhere past fifteen or so channels, a pattern sets in: a message sits unanswered over a weekend, and the first you hear of it is the customer asking why nobody replied.

This guide covers how to run customer support in Slack Connect channels so that doesn't happen, with or without a dedicated tool.

Why shared channels work for B2B support

Customers who pay for a shared channel want to reach people, not a queue. When you read what support teams and their customers say about this on forums and review sites, the same points come up again and again. People like Slack support because they know a human is reading. They resist being moved to a portal. And they don't want a bot answering them in their own channel.

For your team, a shared channel puts the customer next to the work. A support engineer can pull in the developer who wrote the feature, the account manager sees every question, and nobody forwards emails.

Those strengths are worth keeping. The aim is to add structure behind the channel, not to move the conversation somewhere else.

Where it breaks

Slack is built for conversation, not for tracking. As of October 2026 it has no built-in ticketing for Slack Connect channels, so the failures look the same from team to team:

• Nobody owns the message. Five people can see it, and each assumes one of the others is handling it.
• An emoji stands in for a status. Someone adds 👀 to mean "I'm on it", and the thread never gets resolved.
• One issue arrives as several messages. Customers often post three or four top-level messages instead of one thread.
• Notifications stop meaning anything. With every channel on, people mute them, and then they miss the one that mattered.
• Internal talk leaks. An @here meant for your team also notifies the customer.
• The channel becomes a hotline. Customers post at any hour and expect an answer, because nothing tells them when to expect one.

None of these come from lazy teams. They come from using a chat tool as a queue.

Set up the channels on purpose

Start with a convention and stick to it.

• One shared channel per customer account, named the same way every time, for example #ext-acme. A consistent prefix makes the channels easy to find and easy to filter.
• A short list of who from your side sits in each channel. Everyone in the channel looks like someone who might answer.
• A pinned message or the channel description that says what the channel is for and when your team is around.
• A separate internal channel where your team discusses customer requests. That keeps internal comments, and internal @here, away from the customer.

Decide what counts as a request

Not every customer message is work. "Thanks, that fixed it" doesn't need an owner. Turning every message into a ticket is one of the things support teams say they don't want.

A workable rule: a new top-level message from someone on the customer's side is a request until someone on your team says it isn't. Replies in its thread belong to the same request. Your own team's messages don't open requests.

The rule is simple enough to apply by hand, and it errs on the side of answering. A message that turns out to be chatter costs a few seconds to dismiss. A real question that nobody notices can cost a renewal.

Give every request an owner

"The team" is not an owner. Pick one of these and make it explicit:

• The account owner takes requests from their accounts when they're working.
• A rotation hands each new request to the next person on duty.
• Claim by emoji, if your team already does this, with one condition: the claim has to be followed by a reply, and someone has to notice when it isn't.

Whatever you pick, the owner should be visible to the whole team without opening the thread. We cover this in more depth in who owns customer requests in Slack.

Write down response targets

Customers in shared channels expect fast answers, but "fast" means different things to different accounts. Write down two numbers for each tier of customer: how long until the first reply, and how long until the request is resolved. Count them in your business hours, in a stated time zone, with holidays taken out.

Then decide what happens when a request gets close to its target. A reminder at three quarters of the way, sent to the owner and to a place the whole team watches, catches most misses while there's still time. Running an SLA in Slack channels goes through the setup step by step.

Look back every week

Once a week, look at what came in: how many requests, how fast the first replies were, which ones went over target, and which accounts were loudest. Fifteen minutes on Monday morning tells you whether the setup is working or needs another person on rotation.

How Thorpe handles it

Thorpe is built for exactly this setup. You install it in your Slack workspace, add it to your customer channels and pick a triage channel. The getting started guide lists the steps. Your customers change nothing.

• Each new customer request gets one card in your triage channel, with the customer, the first line, the owner, the status and the SLA clock. The card updates in place, and its buttons assign, snooze, set priority and close.
• AI is optional. With it turned on in Settings (Smarter request detection), it gives each new request a title and a priority, and marks the ones that may not be real requests for a teammate to check. Without it, every top-level customer message opens a request and nothing is sent to a model. AI never replies to a customer.
• Statuses follow the conversation. A teammate reply moves the request to waiting on the customer, and a customer reply moves it back.
• Response targets are set per account tier, with business hours, time zones and holidays. Thorpe warns in the triage channel and by DM to the owner at 75% and 100% of each target.
• Assignment rules can give new requests to the account owner, or round robin among teammates who are on duty. A teammate can also claim a request with 🙋, and Thorpe nudges them if the claim isn't followed by a reply.
• Replies in the card's thread are internal notes. The customer never sees them.
• A web tracker lists every request across every channel, with filters, so a lead can find the ones at risk. Replies still happen in Slack.

Apart from broadcasts you send yourself, the only thing Thorpe adds to a customer channel by default is a 👀 reaction on your team's first reply. Anything else that appears in front of a customer is opt-in. Today that's the rating prompt when a request closes, which you turn on per account tier. An off-hours note is coming, and will be off unless you turn it on. Thorpe asks for bot scopes only and joins only the channels an admin picks. The privacy and security page has the detail.