The support queue as a system, not an inbox

A shared inbox works until roughly the point where two people are in it. After that you need a system, and the transition is usually made too late, under pressure, during a period everyone remembers badly.

Ownership. Exactly one person is responsible at any moment, and it is visible. Unowned conversations are how things get missed; jointly-owned conversations are how things get missed while everyone assumes someone else has it.

State, distinct from ownership. Waiting on customer, waiting on a third party, and waiting on us are three different situations. Only the third is your service-level clock. Collapsing them makes every report meaningless, because your response time now includes the four days a customer took to send a photo.

Priority derived, not typed. Priority set by hand becomes uniformly high within a month. Derive it: from customer state, issue class, and how long it has waited.

The item in the queue is not a message. It is a piece of work with a customer attached, and the difference shows up the moment two messages arrive about the same thing.

First response is when a human acknowledged. It is easy to measure, easy to game, and matters mostly because silence is what makes people angry.

Resolution is when the problem stopped existing. Harder to measure, far more meaningful, and the only one correlated with whether people come back.

Report both. A team optimising first response alone learns to send acknowledgements quickly and resolve slowly, which is a worse experience than a slower acknowledgement and a real answer.

Almost every queue reports a single elapsed time, and almost every queue is wrong about it, because the customer's clock and the team's clock stop for different reasons.

Start with skills and hours, not with cleverness. Route by language, product area, and who is actually working right now.

Add automation for classification only after you have a labelled history to check it against — and keep a fallback queue for anything the classifier is unsure about. An unsure classifier that guesses is worse than one that escalates.

Skills-based routing degrades in a predictable way: the skills matrix is written once, staff change, and within a year the routing reflects an org chart nobody works in.

Three properties make routing survive.

A default that is not a dead end. Every routing rule needs a fallback that reaches a person who can act, not a queue nobody watches. Most routing failures are items that matched nothing.

Time-based escalation, not just priority. An item that has waited too long changes queue regardless of its category. This catches everything the matrix got wrong without requiring the matrix to be right.

Reassignment as a first-class event. Count it. An item reassigned three times is a routing defect, and the reassignment count is the cheapest quality signal a queue produces.

Ticketing systems were designed around email, which is asynchronous and bursty. Messaging is neither. Customers expect a reply in minutes, and they will send five short messages where an email would have been one paragraph.

Two consequences:

• Group messages into a conversation, and open a ticket per issue, not per message. Otherwise your queue depth is a measure of typing style.
• Model the session window. On WhatsApp, an agent who takes six hours to pick up a conversation may find the free-reply window has closed. Your queue needs to know that, and should surface it before it expires rather than after.

Repeat contact rate within seven days, per resolved ticket. It is the cheapest available check on whether "resolved" means anything — and it is the number that makes containment-versus-resolution visible in a support context rather than an automation one.

Model work items rather than messages. Keep both clocks. Give routing a live default and a time-based escape hatch. Handle the un-sessioned nature of messaging explicitly, distinguish abandonment from resolution, and measure the first response that actually helped.