Round robin and on-duty assignment for Slack support

Every support team in shared Slack channels has one person who answers first. They have notifications on, they type fast, and customers love them. For a while it works. Then that person is answering half of every channel, their own accounts are slipping, and when they take a week off the response times fall off a cliff.

"Whoever sees it first" isn't an assignment rule. It's a way of handing the work to the most responsive person until they burn out. This post covers how to share new customer requests on purpose: round robin, least loaded, the account owner, and the part most setups get wrong, which is knowing who is actually working.

Why first-come assignment breaks down

When every teammate can answer every message, three things happen.

• Work piles onto the fastest person. The quickest responders get the most requests, whether or not they have time.
• Everyone else waits. Others see the message, assume the fast person has it, and move on.
• Absence is invisible. When the fast person is out, nobody else has the habit of picking messages up, and requests sit.

A rule fixes all three. It decides who owns a new request the moment it arrives, so the team doesn't have to negotiate it in the channel every time.

Round robin: take turns

Round robin gives each new request to the next person in a fixed order. Ana gets one, then Marcus, then Leo, then Ana again.

It's easy to explain and easy to check. Over a week, everyone gets about the same number of requests. Its weakness is that requests aren't all the same size. A teammate who drew a two-day investigation keeps getting new requests at the same rate as someone who drew three quick questions.

Least loaded: fewest open requests

Least-loaded assignment gives the new request to whoever has the fewest open requests right now. It corrects for size on its own: someone buried in a long request stops getting new ones until they close something.

The cost is that it rewards closing. A teammate who leaves requests open while waiting on customers will look busier than they are. If you use it, make sure your team closes requests when they're done, and that "waiting on the customer" is a status you keep honest.

Neither is better in general. Teams with similar, short requests tend to like round robin. Teams with a mix of quick questions and long investigations tend to like least loaded.

The account owner first

Many B2B teams give each account an owner, a CSM or a named support engineer. For those accounts, the owner should usually get the request first, because they already have the context. The rotation then handles everything else, and anything the owner can't take.

Write the order down: "account owner if they're working, otherwise the rotation". The order matters more than which rules you pick, because it's what people will check when a request lands somewhere surprising.

On duty is the hard part

Any rule is only as good as its idea of who is working. A rotation that hands a request to someone asleep in another time zone is worse than no rotation, because now the request has an owner who won't see it for eight hours, and everyone else assumes it's handled.

For each teammate, you need:

1. Working hours, in their own time zone. Not the team's hours, theirs.
2. Holidays. Public holidays and days off.
3. A quick way to say "I'm away". For a sick day or an afternoon of customer calls, without asking a manager to edit a schedule.
4. A way out of the rotation. Team leads and people on project work may answer sometimes without taking new requests.

Then make the rule skip anyone who isn't on duty. If nobody is on duty, leave the request unassigned and visible to the whole team, rather than giving it to someone who won't see it until tomorrow.

Reopened requests go back to their owner

When a customer replies to a request you closed last week, it should usually go back to whoever handled it, because they know the history. If that person is off, the rules should run again rather than leaving it with them.

Keep claiming, with a timer

Rules don't replace people picking things up. If someone on your team sees a request they know how to answer, they should be able to take it. Many teams do this with an emoji.

A claim needs one fix: it should expire. If the person who claimed a request hasn't replied after a short time, remind them privately, with an easy way to reply, hand it back or snooze it. We go through claiming and other ownership models in who owns customer requests in Slack.

Check the spread every week

Once a week, look at how many requests each teammate owned and how many they closed. A big gap means the rules or the hours need adjusting. One week of imbalance is noise. The same person at the top three weeks running is a pattern.

How Thorpe handles it

Thorpe's assignment rules run when a request opens. Both rules are off until an admin turns them on in Settings > Team, and the first rule that finds someone on duty wins.

• 1. Account owner gives the request to the owner of the customer's account, while they are on duty. The account owner comes from HubSpot, an optional integration.
• 2. Round robin shares the rest among a group, in one of two modes: Take turns, or Fewest open requests. Leave the group empty to use everyone on rotation.
• On duty means inside the teammate's working hours, not on a holiday in the default SLA policy, and not away. Each teammate has their own days, hours and time zone, and an Auto-assign switch that takes them out of round robin.
• Away is a button in Thorpe's Home tab in Slack, I'm away and I'm back. A Slack status of 🌴, 🤒 or 🏖️ counts as away too.
• Nobody on duty, or no rules turned on: the request stays unassigned, and its card in the triage channel shows "No owner".
• Reopened requests stay with their owner if that person is on duty. If not, the rules run again.
• The activity log records why someone was assigned, for example "round robin".

Claiming works alongside the rules. A teammate who reacts with 🙋 on a customer's message takes the request. If nobody on your team replies within 30 business minutes, Thorpe sends them one DM with Reply in thread, Unassign and Snooze 1h. Only your own teammates can claim. Settings for choosing your own claim emoji and changing the reminder are coming.

When an owner is away or outside their hours, the 75% SLA alert in the triage channel says so, so someone else can step in. The ownership and assignment guide covers every setting and its default.