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, conversations go unanswered because everyone assumed someone else had them, response times include the four days a customer took to send a photo, and the same problem appears as three tickets because it arrived as three messages. The move from inbox to system is usually made too late, under pressure. This piece describes what the system has to model, how to measure it, and where messaging channels break the assumptions of email-era tools.

The work item, not the message. The thing in the queue is a customer problem with a customer attached. Three WhatsApp messages about one late order are one item, not three.

Ownership. Exactly one person is responsible at any moment, and that is visible. Unowned items get missed; jointly owned items get missed while everyone assumes someone else has them.

State, separate from ownership. Waiting on the customer, waiting on a third party, and waiting on us are different situations. Only the last runs your service-level clock.

Priority, derived not typed. Priority set by hand becomes uniformly "high" within a month. Derive it from customer status, issue type and how long the item has waited.

Most queues report a single elapsed time, and most are wrong about it, because the customer's clock and the team's clock stop for different reasons.

Within those clocks, measure two events:

• First response: when a person (or a disclosed assistant) gave a useful reply — not an automatic "we got your message". It matters because silence is what makes people angry.
• Resolution: when the problem stopped existing. Harder to measure, far more meaningful, and the one linked to whether people come back.

A team optimising first response alone learns to acknowledge quickly and resolve slowly, which is worse than a slower first reply that actually answers.

Start with skills and hours, not cleverness: route by language, product area and who is actually working now. Add automatic classification only once you have labelled history to check it against, and send anything the classifier is unsure about to a general queue. An unsure classifier that guesses is worse than one that escalates.

Skills-based routing decays predictably: the skills matrix is written once, staff change, and within a year routing reflects an org chart nobody works in. Three properties keep it alive:

1. A default that is not a dead end. Every rule needs a fallback that reaches someone who can act. Most routing failures are items that matched nothing.
2. Time-based escalation. An item that has waited too long moves, whatever its category. This catches what the matrix got wrong without requiring the matrix to be right.
3. Reassignment counted. An item reassigned three times is a routing defect; the count is the cheapest quality signal a queue produces.

Ticketing tools were designed around email: asynchronous, one long message at a time. Messaging is neither.

• Bursts. Customers send five short messages where an email would be one paragraph. Group them into a conversation, and open one work item per issue, not per message — otherwise queue depth measures typing style.
• Expectations. People expect replies in minutes on messaging, hours on email. Set targets per channel.
• The session window. On WhatsApp, free-form replies are only possible within 24 hours of the customer's last message; after that you need an approved template. An agent who picks up a conversation six hours late may find the window nearly closed. The queue should show time left in the window and raise items before it expires.
• Channel switching. The customer who gets no reply on chat phones in. Without cross-channel identity, that is two items and two agents.

A customer sends five WhatsApp messages over ten minutes about a damaged delivery, then calls two hours later.

• Inbox behaviour: five unread messages appear as one thread nobody owns; the call creates a separate ticket; two agents work the same problem; the customer explains twice.
• System behaviour: the five messages become one work item, routed to the deliveries team in the customer's language and owned by one agent. The call is matched to the same customer and attached to the open item. The agent asks for a photo; the state changes to "waiting on customer" and the team clock pauses. The photo arrives the next morning; a replacement is ordered; the item is marked solved. Seven days later, no new contact about the same order: counted as resolved.

Repeat contact within seven days, per resolved item, across channels. It is the cheapest check on whether "resolved" means anything. Report it next to resolution time, and separate abandoned (the customer stopped replying) from solved — they are different outcomes and should not share a status.

• Does the tool group consecutive messages into one conversation and let me create work items per issue?
• Can it match one customer across WhatsApp, SMS, email, chat and voice?
• Does it store customer and team clocks separately, with pause reasons?
• Does it show the time left in each channel's reply window, such as WhatsApp's 24 hours?

Next in this track: containment is not resolution, about automation in front of the queue. The window rules are explained in the 24-hour window; for connecting a support tool to other systems without merging them, read federating without merging.