Routing & Escalation: Getting a Ticket to the Right Desk First Time
A ticket that reaches the wrong desk does not just get answered late — it teaches the requester that the system is slower than walking over. How routing actually works when the category carries the policy, why priority does not move the clock, and what escalation means when nothing pages anyone.
The fastest way to kill a helpdesk in its first month is to route badly. A request lands in a general queue, sits for a day, gets forwarded to the wrong department, comes back, and is eventually solved by the person the requester would have walked to in the first place. After three of those, everybody goes back to WhatsApp and the helpdesk becomes a place where tickets go to be ignored.
Routing is therefore not an administrative detail. It is the thing that determines whether the system is faster than the informal channel it replaced, which is the only comparison your colleagues are actually making.
The category carries the policy
This is the design decision to understand before configuring anything, and it is the one people most often get backwards. In AWRA OpsHub, the ticket category is what carries the service policy — the target for first response, the target for resolution, the default department and the default assignee.
Priority exists on a ticket, and it is useful, but it does not set the clock. Priority orders the queue; the category decides what is promised. Which means a badly designed category list produces bad routing and meaningless targets no matter how carefully agents set priorities afterwards.
| Set on the category | What it does |
|---|---|
| First response target, in minutes | Stamps a first-response due time from when the ticket was created |
| Resolution target, in minutes | Stamps a resolution due time from the same anchor |
| Default department | Routes the ticket to a desk when none was chosen |
| Default assignee | Puts a named person on it when nobody is assigned |
The defaults only fill blanks
Category defaults apply where the ticket has no department or no assignee — they do not overwrite a choice somebody already made. That is what makes it safe to set a default on every category: a deliberate assignment always wins over a default.
Designing categories you can route on
Since the category does this much work, its design deserves more than five minutes. The failure modes are predictable and there are only two of them.
Too few categories
- Everything lands in "General" and is triaged by hand
- One target applies to a password reset and a system outage
- Routing defaults are useless because the desk varies
- Triage becomes a person, and that person becomes a queue
Too many categories
- Requesters cannot find the right one, so they pick the first
- Your data is precise and wrong
- Targets multiply until nobody knows what was promised
- Maintaining the list becomes somebody's unwanted job
The workable middle is to name categories after the desk that handles them and the kind of thing they are — eight to fifteen for most organizations. The test: read a category name and you should be able to say which team owns it and roughly how quickly it should be answered. If you cannot, it is either too broad or too clever.
Read a category name aloud. If you cannot immediately say which team owns it and roughly how fast it should be answered, it is the wrong category — and no amount of triage discipline will fix that later.
What the clock actually measures
Be precise about this before you write a target into a customer contract. The due times are computed as elapsed wall-clock minutes from when the ticket was created. There is no business-hours calendar, no weekend awareness and no public-holiday exclusion.
A four-hour resolution target on a ticket raised at 6pm on Friday is due at 10pm on Friday, not at midday on Monday. If your service commitments are written in working hours — and most contractual ones are — the numbers you configure must be converted into elapsed time, and you should expect that conversion to be imperfect around weekends.
The one thing that does move the clock is the pause. Where a ticket is waiting on the requester, the pause is stamped, and when it comes back the resolution due time is pushed forward by the paused span. That is what makes a target fair — you are not held to a clock that ran while you waited for the information you asked for. The full treatment is in SLAs that mean something.
Escalation without an escalation engine
Here is the honest position. There is no rules engine that reassigns a ticket after two hours, no automatic promotion to a manager at 80% of the target, and no paging. What exists is notification and visibility: assignment notifies, replies notify, status changes notify, watchers can follow a ticket, and a breach produces a notification.
Which means escalation in practice is a human rhythm supported by a filter. That is less impressive than an engine and, run properly, gets to the same place.
-
Name the second line before you need it
For each category, who is the next person if the first cannot resolve it. Written down, not assumed. Most escalation failures are not delays — they are genuine uncertainty about who to hand it to.
-
Run a queue review at a fixed time
Once or twice a day, five minutes: unassigned tickets, tickets past their first-response due time, tickets untouched for two days. The same three filters every time.
-
Use watchers as the escalation mechanism
Adding a manager as a watcher on a ticket that is going badly is lightweight, visible to everyone and creates no ambiguity about ownership — the assignee still owns it.
-
Treat unassigned as the alarm
A ticket nobody owns is the one failure mode that guarantees a breach. Category default assignees exist precisely so this number stays near zero.
Where the requests come from
Routing quality depends on intake quality, and intake is where most helpdesks quietly leak. A request that arrives as a WhatsApp message to an agent's personal phone is invisible to every queue, every target and every report — and it will be the one that goes wrong.
Tickets can be raised by staff who log in, by customers or colleagues through a tokenized portal that needs no login, and by agents on somebody's behalf. The last one matters more than it sounds: when a colleague corners an agent in a corridor, the agent raising the ticket themselves — in front of them — is what gradually moves the culture. Worth knowing plainly: there is no WhatsApp Business API integration, which in this market is the intake channel people most often assume exists.
What we do and do not do
What AWRA OpsHub does today
- Category-driven routing — default department and default assignee applied where the ticket has none.
- Category-driven targets — first response and resolution due times stamped from creation.
- A real pause — waiting on the requester stamps a pause, and the resolution due time is extended by the paused span on return.
- Notifications on submission, assignment, replies, status changes and SLA breach, with watchers able to follow any ticket.
- Tokenized public intake, so people can raise and follow a ticket without an account.
- Priority on tickets for ordering the queue, independent of the SLA clock.
What it does not do
- No escalation rules engine. Nothing reassigns, promotes or pages after a threshold — escalation is a rhythm you run.
- No business-hours calendar. The clock is elapsed time from creation; weekends and public holidays are not excluded.
- No round-robin or load-balanced assignment. Default assignee is a fixed person per category, not a rotation.
- No WhatsApp intake. Email, portal and in-app are the channels.
The business-hours gap is the one that causes contractual embarrassment, so settle it before you publish targets to customers. Contract language saying "eight working hours" will not match a clock that runs through Saturday.
Our take
Spend an hour on the category list — it carries the routing and the promises, so everything downstream inherits its quality. Set a default assignee on every category so nothing sits unowned, convert your working-hours commitments into elapsed time deliberately, and run a five-minute queue review at a fixed time each day. That review is your escalation engine.
See ticket queues and routing
Categories that carry routing and targets, default departments and assignees, watchers, notifications and tokenized intake without a login.
Explore ticket queuesFrequently asked questions
Does priority change the SLA target?
No — and this catches people out, so it is worth stating twice. The category sets both the first-response and resolution targets; priority orders the queue for agents deciding what to pick up next. If you need faster targets for urgent work, that is a category with tighter targets rather than a high-priority ticket in a slow category.
Does the clock stop overnight and at weekends?
No. Due times are elapsed wall-clock minutes from when the ticket was created, with no business-hours calendar, weekend awareness or public-holiday exclusion. A four-hour target set on a Friday evening expires that Friday evening. Convert any working-hours commitment into elapsed time before you configure it, and be careful about contract wording that promises "working hours" — the system will not interpret that phrase for you.
Can a ticket be automatically escalated if nobody responds?
Not by a rules engine — nothing reassigns or promotes a ticket after a threshold, and nothing pages anyone. What you get is a breach notification, watchers who can follow a ticket, and the ability to filter for overdue and unassigned work. In practice a five-minute queue review at a fixed time each day covers the same ground, provided somebody genuinely owns that review.
How many categories should we have?
Eight to fifteen for most organizations. Too few and everything lands in a general bucket that has to be triaged by a person, who becomes the bottleneck; too many and requesters pick the first plausible option, giving you data that is precise and wrong. The test is whether reading a category name tells you which team owns it and roughly how fast it should be answered.
Can tickets be balanced across a team automatically?
No — the category default assignee is a fixed person, not a rotation, and there is no round-robin or load-based distribution. The usual pattern is a default assignee who acts as the desk's triager and reassigns, which works well up to a point and becomes a bottleneck beyond it. If genuine load balancing matters at your volume, raise it as a requirement rather than an assumption.
