The short answer
The problem is rarely volume. It is that requests arrive through several channels and some never reach a queue at all, so nobody knows what is outstanding.
One queue, consistent classification, automatic routing where the rule is clear, and time-based escalation covers most of it.
Get everything into one queue
- A shared mailbox that creates items automatically
- A simple form for the common request types
- Phone calls logged by whoever takes them, in the same queue
- Messages from client contacts forwarded in rather than handled privately
- Recurring planned work visible alongside reactive requests
The last point matters. Reactive requests look manageable until you see them next to the planned work competing for the same people.
Classify consistently
| Field | Why |
|---|---|
| Site | Drives who attends |
| Category | Drives the skill needed |
| Urgency | Drives response time, separate from importance |
| Safety flag | Changes the response entirely |
| Access constraints | When can someone actually get in |
Keep urgency separate from importance. A dripping tap in a rarely used room is important and not urgent; a blocked fire exit is both.
Where automation genuinely helps
- Suggesting a category from the request text, for a human to confirm.
- Routing to the right team where the rule is unambiguous.
- Acknowledging receipt with a realistic timeframe.
- Chasing updates on items approaching their target.
- Spotting repeat requests for the same asset.
Point five finds the real problems. The same item reported five times is an asset needing replacement rather than five separate jobs.
Escalate on time, not on complaint
If escalation only happens when a client chases, the client is running your process. Set target times per urgency level and escalate when they are approaching, before anyone complains.
That single change accounts for most of the perceived improvement when operations introduce a helpdesk.