A customer emails with a problem. Before anybody can help them, someone has to read it.
Read it, work out what they actually mean, decide whether it is urgent, decide who in the business handles this, check whether they have written before, find their order, and only then start on the actual answer.
All of that happens before a single useful word gets written back. And it happens on every message, every time, from scratch.
The reading is the job
Count what a support message needs before a reply exists.
- Comprehension. What is this person asking? Frequently not what the subject line says.
- Classification. Is this a fault, a question, a complaint, a chase, or someone in the wrong place entirely?
- Urgency. Is anything actually broken right now, or does this read urgent because the customer is annoyed?
- Context. Who are they, what did they buy, what happened last time, is there an open job?
- Routing. Who in the business can answer this, and are they available?
Five judgements, most of them mechanical, all of them done by a person with the rest of their day waiting. On a busy morning the reading queue itself becomes the bottleneck — and a queue that is backed up on reading looks identical to a queue that is backed up on hard problems.
What it costs when reading is the bottleneck
Three things, and the third is the one that damages you quietly.
Response time goes up on everything. Including the messages that would have taken thirty seconds to answer, because they are sitting behind messages that need thought.
Easy things get expensive. The person doing the reading is frequently your most experienced person, because they are the only one who can tell what matters. So your most expensive hour is spent sorting.
The queue stops being visible. When reading is slow, nobody actually knows what is in the queue — only what has been read so far. Ask what is waiting and the honest answer is a guess. That is how a genuinely urgent message sits for a day among sixty routine ones.
Where a person genuinely has to stay
Worth being clear about, because the wrong version of this idea is a chatbot answering customers on its own, and that is a liability with a friendly tone.
The judgement stays with your team. What the customer is told, what gets refunded, what gets promised, what an unhappy person hears from you — those are decisions with consequences and they belong to a human.
The sorting is not judgement. Working out that this message is a delivery question about order such-and-such from a customer who wrote twice last week is not a decision. It is retrieval, and it is exactly what should arrive already done.
The useful shape is: everything is read, classified, routed, and drafted — and then it stops and waits for you. You read a prepared reply and a summary rather than a raw message and a blank box. You still decide every single one. You just stop doing the assembly first.
Fifteen years of queues, and what I would tell you
I started on a service desk in 2006 and ended up running the technical support team at Pantheon, a platform hosting sites that could not go down. That is a lot of mornings opening a queue and feeling the day’s shape in the first five minutes.
Here is the thing that would have saved me the most time, offered so you do not need the fifteen years. The cost was never the hard tickets. Hard tickets are the job and they are satisfying. The cost was the constant re-orientation — picking up something with no context, reconstructing who this was and what happened, then putting it down to do it again on the next one.
Fifty messages a day, three minutes each of reconstruction, is two and a half hours of somebody’s day spent getting back up to speed. Nobody ever billed for that or noticed it. Run the same arithmetic on your own volume and you will get a number that is uncomfortably specific.
Measure your own reading cost
- For one week, log the time between a message arriving and someone first opening it. Not answering — opening. That gap is your reading backlog.
- Sort last month’s messages into five buckets using the list above. If one bucket is enormous and routine, that is your candidate for going first.
- Count how many needed context from elsewhere — an order number, a past conversation, a job record — before anyone could reply.
- Ask who does the reading and what their hourly cost is. Then ask what they were hired to do.
- Check the tail. Of last month’s messages, how many took more than three days? Read those five specifically and ask what stalled them. It is rarely difficulty.
If your first-open time is minutes, your buckets are evenly mixed, and nothing tails off — you have a healthy queue and a well-staffed team. Genuinely leave it alone.
What to do next
Measure your first-open time for one week. That single number tells you whether your queue is slow because the work is hard or slow because nobody has read it yet — and the two problems have completely different fixes.
If the sorting is your cost, the comparison with a help-desk tool covers who drafts and who approves. For the wider count, map the stops across the flow.
If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.
Common questions
Isn’t this just an argument for a help-desk tool?
A help-desk tool is a real improvement on a shared inbox and worth having, so if you do not have one, start there. What it gives you is a place where tickets have owners, statuses and history. What it does not do is read the message, work out what it means, pull in the customer’s context, or draft anything. It organises the queue — somebody still works it.
Won’t customers be able to tell if a reply was drafted automatically?
They can tell when nobody read it, which is a different thing. A draft that has been reviewed and sent by a person who knows the customer reads like a person, because one was involved at the point that matters. The failure mode people recognise instantly is the generic reply that did not engage with what they asked — and that failure comes from rushing, not from drafting.
Our volume is low. Is this worth thinking about?
At low volume the cost is not hours, it is interruption, and that is worth measuring differently. Twelve messages a day scattered across the day can break up the work of your best person more expensively than forty batched ones. If the honest answer is that support is a small, calm part of the week, leave it alone.
What happens when something genuinely unusual arrives?
It should be flagged as unusual rather than forced into a bucket, and that is a design question worth asking anyone who proposes this. A system that is confident about everything is more dangerous than one that says it is unsure and hands the odd one to a person. The weird ones are exactly where human judgement earns its money.