Who owns customer requests in Slack?
Who owns customer requests in Slack when five people can see every message? Ownership models that work in shared channels, and how to keep claims honest.
A customer posts a question in your shared channel mid-morning. Four people on your team see it. Two of them add a 👀. Nobody replies. In the afternoon the customer asks again, a little less politely, and in the retro each person says the same thing: they assumed someone else was handling it.
This is the most common complaint about running support in Slack, and it isn't about effort. Everyone saw the message. The problem is that seeing a message and owning it look the same in a channel.
Why ownership goes missing in shared channels
A help desk has an assignee field. Slack has a channel full of people, all of whom can answer.
- Everyone can see it, so everyone waits. The more people in the channel, the more likely each one assumes another will step in.
- An emoji is ambiguous. 👀 can mean "I'm on it", "I saw this" or "someone should look at this". It never expires.
- Handovers are invisible. When the person who usually answers is out, nothing tells the rest of the team.
- Time zones split the day. A message that arrives at the end of one person's day and the start of nobody's sits until the morning.
Pick an ownership model
There is no single right model, but there has to be one. These four cover most teams.
The account owner. The CSM or support engineer assigned to the account takes its requests. Customers get continuity, and the owner already has the context. The weakness is holidays and busy days, so it needs a fallback.
A rotation. New requests go to the next person on duty, in turn. It spreads work evenly and doesn't depend on any one person. The weakness is context: whoever is next may not know the account.
Least loaded. New requests go to whoever on duty has the fewest open requests. It works well when requests vary a lot in size, because a person stuck on a long one stops getting new work.
Claim. Whoever picks it up first owns it, usually signalled with an emoji. It's fast and fits how teams already behave. The weakness is the one in the story above: a claim with no follow-through.
Most teams combine them: the account owner if they're working, otherwise a rotation, with claiming allowed on top. Write the order down, so nobody has to guess.
Only assign to people who are working
Whatever the model, a request should never go to someone who is asleep, on leave or at a conference. That means each teammate needs working hours in their own time zone, and a simple way to say "I'm away".
A Slack status is a good signal. If someone sets a holiday or sick status, treat them as away until they clear it.
When nobody is on duty, leave the request unassigned and visible, rather than giving it to someone who won't see it until tomorrow.
Make claims expire
If your team claims with an emoji, keep the habit and fix its one flaw. A claim should start a short timer. If the person who claimed it hasn't replied when the timer runs out, remind them, privately, with an easy way to reply, hand it back or snooze it.
Pick a claim emoji that means only one thing. If 👀 already means "seen" on your team, use a different one for "mine".
New users get sent back to the sign-in page after SSO.
Make the owner visible
The owner should be visible without opening the thread. A list of open requests with an owner column, or a card per request in an internal channel, works. Anyone on the team should be able to answer "who has this?" in a few seconds.
Show unowned requests just as clearly. "No owner" on a request is a call to action. A missing field is easy to miss.
Keep internal discussion out of the customer's channel
Ownership often needs a conversation: "Is this the bug from last week?", "Can you take this, I'm in calls all day?" Have it somewhere the customer can't see. An @here in a shared channel notifies the customer too. A thread under an internal copy of the request keeps that discussion attached to the request it's about.
How Thorpe handles it
Thorpe gives every customer request an owner field and a set of rules for filling it.
- Assignment rules, in the order you set: the account owner if they're on duty, then round robin among teammates who are on duty, or least loaded. With no rules, requests stay unassigned and visible.
- On duty means inside the teammate's working hours, in their time zone, and not away. Teammates can mark themselves away in Thorpe's App Home, and a Slack status such as 🌴 or 🤒 counts as away too.
- Claim with 🙋. A teammate reacting with 🙋 on a customer message takes the request. If there's no reply after 30 business minutes, the default, Thorpe DMs them with buttons to reply, unassign or snooze for an hour. Only your own team's reactions count.
- The owner is on the card. Each request's card in the triage channel shows the owner, or "No owner". The activity log records why someone was assigned, for example "round robin".
- Alerts name the owner. SLA warnings go to the owner by DM and to the triage channel, and say when the owner is away.
- Internal notes are replies in the card's thread in your triage channel, so your team can discuss a request without the customer seeing it. The card's Discuss button starts that thread.
- A morning DM lists each owner's open requests, sorted by when they're due.
The getting started guide covers installing Thorpe and choosing your triage channel.