What this covers
- Most operational requests are lookups across two or three systems, not problems requiring judgment.
- Routing accurately is often worth more than answering automatically, and it is the safer place to start.
- The reply has to be drafted from the live record, not from a template with the record pasted in.
- Complaints, claims and anything commercial should route to a person by rule, whatever the agent could have answered.
Open a shared operations mailbox on a Tuesday and the pattern is the same in every B2B business. Where is my order. Do you have 400 of these in stock. Can you resend the delivery note for last month. We need to change the delivery address on PO 44192. Why does this invoice not match what we agreed.
Almost none of these require thought. They require access. The answer exists in the order record, the stock table, the document store or the invoice, and the only reason the customer waits is that the person who read the email cannot see all four.
The relay, drawn out
It is worth writing down what actually happens, because the cost is invisible when each step looks reasonable.
- 01The request arrives
In a shared mailbox, addressed to nobody in particular, at 16:40.
- 02Someone triages it
Reads it, decides which team it belongs to, forwards it. This person adds no information and consumes the first hour.
- 03It queues
In a second inbox, behind that team's own work. Overnight, typically.
- 04Someone looks it up
Opens two systems, finds the answer, which takes under a minute.
- 05Someone replies
Writes the answer back, often without the context of the original thread.
- 06The customer chases
Because by the time the answer arrives the question has moved on, or the reply answered one of the two things they asked.
Step four is the work. Everything else is transport. And step six generates a second request that goes through the whole cycle again.
Start with routing, not with answering
There is a tempting order of operations that usually goes wrong: automate the answers first, because that is the visible win. The safer and often larger win is to automate the triage.
Classifying an incoming request correctly, identifying the account and the order it refers to, and putting it in front of the right team with the record already attached removes the first hour and the overnight queue without the agent committing to anything customer-facing. It is the lowest-risk step in the entire category, and in many operations it is where most of the delay lives.
One published figure exists on this site for exactly this: a European logistics company measured 40% faster ticket routing, where the agent identifies the intent of each incoming request and routes it into the right operational workflow. The customer name is confidential, and the number belongs to their operation rather than being a benchmark for anyone else's.
Answering from the record, not from a template
When the agent does draft a reply, the difference between a good and a bad implementation is where the content came from.
A bad implementation matches the question to a template and fills in a field. It produces confident replies that are wrong whenever the situation is not the one the template assumed: the order that was split across two shipments, the line that was substituted, the delivery that went to the site rather than the registered address.
A good implementation retrieves the actual state and describes it. Three of your four lines shipped on Thursday and are with the carrier under this reference. The fourth is on back order with a confirmed date of the eleventh. That is a different answer from a template, and it is the answer that prevents the follow-up email.
Every reply that does not fully answer the question generates a second request. Half-answers are not half the work, they are more than double.
What routes to a person, always
Some requests should never be answered automatically, regardless of how clearly the agent could answer them. These are rules, not confidence thresholds.
| Request type | Handling | Why |
|---|---|---|
| Order status, ETA, tracking | Answered from live data | A lookup with a factual answer |
| Stock and availability | Answered from live data | Same, with the caveat the system states |
| Document requests | Retrieved and sent | The document exists; finding it was the work |
| Change requests | Prepared, then approved | It changes a committed transaction |
| Complaints and claims | Routed, with context assembled | Commercial and relationship judgment |
| Anything about price or credit | Routed | Commercial decision, never automated |
| An angry customer | Routed, flagged | Tone is a signal the agent should act on by escalating |
The last row matters more than it looks. An agent that detects frustration and escalates rather than replying is better service than one that answers correctly and coldly. Escalation is a feature, not a failure.
What to measure
- 01First response time, measured from the customer's timestamp rather than from when the ticket was opened internally.
- 02Share of requests resolved on the first reply, which is the number that predicts follow-up volume.
- 03Share of requests that never reached a person, split between routed-only and answered.
- 04Reopen rate, which is the honest check on whether the automated answers were actually complete.
A rising reopen rate alongside a falling response time means the agent is answering fast and incompletely, which is worse than the original problem. Watching both together is the discipline.
The Customer Operations Agent sets out what is built before a deployment and what is configured against your systems, tone and escalation rules.