Customer support queue: routing, escalation and double replies

A support queue is the list of customer conversations your team has not finished, with an owner and a waiting time on each. In a Slack Connect setup the shared channel is where the customer writes, and the queue is a separate view built from those channel messages, so you can see which threads are waiting on you without reading every channel. It has to answer three questions about every thread: whose it is, how long it has waited on your side, and whether the customer has already had an answer.

Key the queue on one attribute

A queue can be keyed on the shared channel the message came from, the customer tier, or the issue type. Only one should decide which queue a thread lands in. The other two become labels you filter and report on.

• Key on channel when each shared channel has one owner who knows the account. It stops working when one person covers many channels, because the queue turns into a set of personal inboxes.
• Key on customer tier when a few accounts need senior handling. Rule: if an account’s contract includes a named success manager, its threads go to the senior queue whatever the channel or topic.
• Key on issue type when you have specialists. Rule: if more than one in five requests needs a specialist, issue type becomes the primary key.

One platform rule affects who can be in the queue at all. Slack’s Slack Connect help article requires a paid Slack plan from every organization in a shared channel, yet it also says an organization without one can be invited to try Slack Connect for free. The article does not spell out what a free-plan customer can do after that, so plan rules may have changed since I read it. If a customer is on a free plan, have your own paid workspace create and own the channel and send the invitation, and check Slack’s current plan rules before you tell the customer Slack Connect is unavailable. Fall back to email only if the invitation cannot be accepted.

Worked example with made-up numbers. A team of six agents has 40 Slack Connect channels: 5 enterprise and 35 standard. Two agents can read API logs. Keyed on tier, the 5 enterprise channels go to the two senior agents, and the 35 standard channels split by issue type so API questions reach the two agents who can answer them. Keyed on channel alone, an API question from a standard account waits for whoever owns that channel.

Failure mode: keying on all three at once. Fix: one primary key, and a thread’s queue is decided by that key alone.

Choose an assignment method

• Round robin gives each agent an equal share of new threads. It is fair on count and blind to difficulty. Use it when requests are interchangeable.
• Skills-based routing sends a thread to someone tagged for its topic. A stale tag sends a billing question to someone who no longer handles billing, and the thread sits.
• Load-based routing gives the next thread to the agent with the most spare capacity. Zendesk’s capacity rules article gives a maximum of 500 open email tickets per agent and 20 messaging tickets per agent. Those are Zendesk’s own ceilings for its ticket channels. They show the mechanism, not a number to copy.

My default is a skill filter first, then the eligible agent with the fewest open threads. If nobody eligible is under the cap, the thread waits in the unassigned view for a lead. My starting cap is 8 to 10 open threads per agent, a rule of thumb for threads that stay open for a day, not a measured figure.

Zendesk’s article says pending and on-hold tickets are not counted towards capacity. I deliberately count them. In a shared channel the customer can see the thread and is still waiting, so a parked thread is still your work, and agents who park threads to get under the cap would otherwise empty the cap of meaning. Report parked threads separately so they stay visible.

Setup you can start this week. Keep a sheet or script with three columns: agent, skill tags, open threads. When a thread arrives, filter agents by tag, pick the lowest open count, break ties by the agent who last handled that customer, and assign. Recount open threads (waiting on us, waiting on customer and parked) at the start of each shift. If your tool has an API, a short script can do the same count; if not, a saved view per agent gives you the number.

Escalate on a business-hours clock

A thread is either waiting on us or waiting on the customer, and only waiting on us ages. Start the clock at the customer’s latest message that moved the thread into waiting on us. A customer who writes back two days later starts a new wait, not a 2-hour overdue one. The first response time guide has the definitions.

Business hours. Define them once, in the SLA, as a window in one named time zone, for example 09:00 to 18:00 Monday to Friday in the time zone of the customer’s contract region, not the agent’s. Hours outside the window do not count; a message sent on Saturday starts counting at 09:00 Monday. Keep one holiday list per support region and apply it to the account’s region. Where an account is covered 24 hours, count calendar hours instead and say so in the contract.

These are starting values; tie them to your first response target. An emoji or an automatic acknowledgement does not stop the clock.

Worked timeline. The customer writes Thursday at 16:30 in the contract time zone, with the window closing at 18:00. At 18:00 the thread has waited 1.5 business hours. The clock resumes Friday at 09:00 and reaches 2 hours at 09:30, so it turns urgent Friday at 09:30. At 11:30 the thread has waited 4 business hours and the lead is notified. The lead sees Priya is in a workshop, reassigns it at 11:40 and writes: “We have brought in our integrations engineer. Expect her reply in this thread by 3 pm your time.” The reply goes out at 13:10, so the full wait was 5 business hours and 40 minutes.

Decision rule: if more than 10 percent of open threads are urgent at any moment, the threshold is wrong or the team is short of people. The 10 percent is my rule of thumb. Do not add a fourth tier to absorb the overflow.

If your tool has no timed escalations yet (the inbox described below lists them as not yet available as of 2026-11-11), run it by hand: a saved view of waiting-on-us threads that a lead opens at the start of each business hour.

Get customer messages into the queue, not the noise

Slack puts Slack Connect channels and DMs into the External Connections section of the sidebar by default. That does not keep internal chatter out of the channel. Treat every message in a shared channel as read by the customer.

• Create queue threads only from messages by people at the customer’s organization. Your own team’s messages do not create threads.
• Keep internal discussion out of the shared channel. Name channels so the difference is obvious, for example “ext-acme-support” and “int-acme-support”.
• The help article says only the organization that owns a channel can invite other organizations or remove them. If your team created the channel, you manage who is in it; if the customer created it, ask them to remove a stray member.

If you build your own feed from Slack events, the message.channels reference says to tell public channel messages from other message.* events with the channel_type field, and it requires the channels:history scope. The reference does not mention private channels, so confirm which event covers yours. The help article does not state a retention rule, so check retention with your Slack admin before you promise a record period.

Weft’s home page says every channel becomes a thread in its inbox, and that replies go out under the agent’s own name and avatar, not a bot account. Notes are listed as part of the inbox.

Several people from one customer. Pick a customer of record per account, usually the contact named in the contract. Threads belong to the account, not to the person who typed. When different customer users write, the clock follows the thread: any customer message that asks something new starts a wait. Two people asking the same question go in one thread, and the reply names both.

One owner per thread, and what to do after a double reply

Make the assignee the only person who posts customer-facing replies. Before every reply, check the assignee field. If it names someone else, ask them in an internal note, and if they are away, take the thread by reassigning it to yourself. Handover wording: “Priya is picking this up from here and will reply in this thread by 3 pm your time.”

Recovery after a double reply. The assignee sends the correction, because the customer has already seen two voices. If the answers agree: “Two of us replied at once. The answer above from Dan stands, and I will handle anything further here.” If they conflict, the assignee works out the right answer first, then writes: “Two of us replied and the answers differed. The correct answer is X. Please ignore the earlier message from Dan.” The second person deletes nothing, since the customer has read it. Log it for the weekly count.

Reopens, absences and AI agents

Reopen rule: when a customer writes in a closed or pending thread, move it back to waiting on us and start the clock from that message. Give it back to the previous assignee only if they are on shift and under the cap; otherwise the lead assigns it within the same business hour.

Absence rule: the lead reassigns an agent’s open threads before they leave. Four agents at a cap of 8 hold 32 threads. One is out, so three hold 24 and 8 wait in the unassigned view, which is the signal to bring in cover or raise the cap for the day.

AI agents are drafters, not owners. A named person holds the assignee field and approves any draft before it goes into the channel. Count AI-drafted threads against that person’s cap, and treat an AI reply as not a human reply for the escalation clock. Hand over when the customer asks for a decision or exception, or has written twice without getting the answer; the “twice” threshold is my starting rule.

Measure whether the rules hold

Count weekly. These alarms are my numbers, not benchmarks.

• Double replies: replies from someone other than the assignee at the time. More than 2 per 100 threads means the one-owner rule is not followed.
• Mis-assignment: threads reassigned within their first hour, divided by new threads. Above 10 percent usually means stale skill tags.
• Parked threads: pending or snoozed as a share of open threads.
• Escalations by tier: the count at 2 and at 4 business hours. Review every one that reached 4.

What the inbox lists as live, and what you set up yourself

As of 2026-11-11, from the Weft home page. Where a row says not listed, I found no mention on the page; ask the vendor before relying on either answer.