Service desk queue management: buckets, limits and escalation

In Slack Connect there is no ticket system underneath, so the queue is whatever you build from channel messages. Each shared channel is a channel in your workspace, visible to everyone you add to it, and the customer sees only that channel. Someone has to turn messages into requests, and that someone is the triage owner: one named person per shift who assigns every new request. The numbers below are my starting values unless a source is cited.

Bucket by tier first, then priority, then channel

Use three keys, in this order:

• Customer tier: contracted customers with a response promise, other paying customers, and everyone else.
• Priority: P1, P2 and P3, each defined by a test someone can apply in ten seconds.
• Channel: the shared channel or email address the message came from.

Tier outranks channel because order decides which rule applies. Zendesk’s SLA documentation says the order of SLA policies determines how they are applied, and recommends placing the most restrictive policies at the top. Put the contracted-tier rule above the channel rule in the same way.

Channel-only buckets fail quietly. A contracted customer in a small channel waits behind a busy channel of smaller customers, and the small channel looks calm, so the wait never shows up. The fix is the tier key, not more people.

Priority tests, with first reply targets:

• P1: production is down, or customer users cannot log in, and there is no workaround. 1 business hour.
• P2: a workflow is blocked but a workaround exists. 4 business hours.
• P3: a question, how-to or feature request. 1 business day.

“Waiting on customer” is a status, not a bucket. Keep it out of the active count, or the load per person looks higher than it is.

Worked example: six agents cover three shared channels, and 14 customers hold contracts with a response promise. Start with four buckets: contracted P1; contracted P2 and P3; standard P1 and P2; standard P3. Each has a named owner per shift. Add a bucket only when it needs a different person or a different clock.

How a request is formed and claimed

• Merging: messages from the same customer in the same channel within 15 minutes, with no team reply between them, are one request. The clock starts at the first. A message about a different problem is a new request even if it is one minute later.
• Claiming: the triage owner assigns the request in your tool or the sheet below. Claim in the tracker, not with a public reply, because a public “on it” could be read as the first reply. If you want the customer to see it, that message counts as the reply and must address the request.
• Visibility: put the queue view where the whole bucket sees it, and keep internal notes out of the shared channel, since the customer can read everything there.

Per-person limits and queue splits

Count load per active person, not total items. A queue with 300 items and 30 people on shift is calmer than one with 40 items and three people. An active person is someone scheduled to the bucket for the current shift, not on PTO or sick. Recount at each shift change.

Two caps per person:

• In progress: 5 items, of which at most 2 are P1. Past that, the sixth item sits unassigned in the bucket rather than waiting silently in someone’s list.
• Open active: 20 items, excluding waiting_customer.

Split a queue when any one of these holds:

• Open active items per active person average above 20 for three business days in a row.
• The queue holds two tiers.
• Its oldest unassigned item is older than its P2 first reply target.

Worked example: a queue holds 75 open active items and four people are on shift, about 19 each. Keep it. If one person is on PTO, the same 75 is 25 each, so the roster belongs in the report. The next week it holds 100 items, 25 each for three business days. Split it into a P1 and P2 queue and a P3 queue, and staff the P1 queue first.

A case study with real figures is Tipalti’s blog post, updated June 4, 2025. It reports that tickets escalated to its engineering team dropped by 67% after a dedicated engineer joined each sprint and coached support to resolve tickets without escalating. It also reports response times falling from 7 days to 2 days. It does not name the product or say how it counted, so read it as a list of changes, not a benchmark.

Three clocks, with start, stop and pause rules

Zendesk’s reply time article measures from ticket creation to the first public agent comment, and says most automated or bot actions are not counted. Slack Connect has no ticket creation, so these definitions are mine.

• First reply clock: starts at the customer’s message, stops at the first public reply that addresses the request. A reply asking for logs counts. Emoji reactions and automatic acknowledgements do not.
• Follow-up clock: starts each time the customer writes in an open request after a team reply, stops at the next team reply. Targets: P1 2 business hours, P2 1 business day, P3 2 business days.
• Resolution clock: starts at the first customer message, stops when you mark the request solved. Targets: P1 1 business day, P2 3 business days, P3 10 business days.

Pause rule: the follow-up and resolution clocks pause while the request waits on the customer. That is my choice. Zendesk’s SLA article says agent work time pauses on On-hold or Pending, and total resolution time does not pause on status changes except when the ticket is changed to Solved. The first reply clock never pauses for status, since it has stopped by then.

Reopen rule: a message within 2 business days of marking solved reopens the request. The first reply clock stays stopped. The customer’s message starts a follow-up clock, and the resolution clock resumes with the solved period not counted. Later than 2 business days, treat it as a new request with a new first reply clock.

AI exception: an agent’s public answer does not stop the first reply clock until a named person on the bucket has reviewed it in the thread. Until then the clock runs and the owner gets the warning.

Business hours: Zendesk lets you choose calendar or business hours per priority, and business-hour targets pause outside business hours. Run each clock on the calendar of the team that owns the bucket, keep one holiday list per calendar (a missing holiday counts as a working day), and write it into the SLA, for example “09:00 to 18:00 in the owning team’s time zone, Monday to Friday, excluding the holidays in this agreement”.

Worked example: a message arrives Friday at 17:40 with a one-hour target. Twenty minutes count on Friday and 40 on Monday, so it is due at 09:40 Monday.

Escalate on clock points

Targets are the first reply values above. Measure points from the customer’s message.

• If the only reply so far is an internal note, the clock keeps running.
• Each level fires once per request, so a repeated alert does not change who owns the item.
• Only the team lead on shift opens an engineering escalation from a shared channel, naming an engineering owner and a return time. The bucket owner posts that time to the customer.

Worked example: a P1 arrives at 14:10 on a Tuesday, hours 09:00 to 18:00. The warning fires at 14:40, the team-lead escalation at 15:10, the account-owner escalation at 16:10. An internal note at 15:05 changes nothing. A public reply at 15:20 stops the clock, and the log still marks the request late.

Coverage outside hours: for contracted P1, run a weekly on-call rotation of one person, and state the response time in the contract, not the calendar default. With two regional teams, each owns its buckets in its own hours, and the leaving team posts a handoff at least 30 minutes before shift end that lists every open item due in the next two hours. Weft is one tool that does this part: every customer message in a shared channel becomes a thread in one queue, and its inbox has assignment, labels, statuses and saved views.

A sheet if your tool has no clocks

One row per request: request ID, channel, tier, priority, start, owner, status (open, waiting_customer, answered), first_reply_at, first_reply_by (human or ai), pause_start, pause_end, due_at.

• Copy the Slack message timestamp into start, not the time you noticed it.
• Compute due_at with the first response time calculator, or a formula that skips non-working hours and holiday rows.
• When status becomes waiting_customer, write pause_start. On the customer’s reply, write pause_end and push due_at by the working minutes between them.
• Each morning, filter waiting_customer rows whose pause_start is over one business day old. A missed restart freezes the clock and the request never escalates.

Wording for the customer

Promise times in the owning team’s calendar and name the zone, so the commitment matches the clock.

When a request moves to engineering:

“We’ve passed this to our engineering team with the logs you sent. You’ll hear from us here by [time and time zone] tomorrow, even if we don’t have a fix yet.”

When an AI agent drafted the first answer:

“This first answer was drafted by our assistant and checked by [name] on our team. If anything is missing, [name] will reply here by [time and time zone].”

When the queue is behind:

“We’re behind on new requests today. Yours is in the queue for [product area], and a teammate will reply here by [time and time zone].”

Promise only a time the bucket can keep. If it cannot, promise the next check-in.

Weekly review

Read four numbers per bucket: first reply attainment, oldest unassigned item with its age, reassignments per request, and escalations per level.

• If a request has been reassigned more than twice, write the bucket owner into it and stop passing it around.
• If P1 attainment slips for a week, check the escalation timings and roster before adding people. A warning that fired after its target means the timings are wrong.
• If the catch-all bucket holds more than 20 items for two weeks, name an owner or split it out.