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, because each category chooses its own clock. The default is elapsed wall-clock minutes from when the ticket was created — correct for an outage promising restoration in four real hours. Switch a category to working hours and the clock counts only your configured business hours on days you work, skipping weekends and public holidays, which is what a contract worded in working hours actually means. Pick per category; the wrong choice is silent.
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.
More we can add to your workspace
- An escalation rules engine, reassigning, promoting or paging after a threshold, so escalation stops being a rhythm you run.
- A round-robin or load-balanced assignment. Default assignee is a fixed person per category, not a rotation.
- A first-response breach notification. That target is computed and badged on the ticket, but only the resolution clock has a sweep that notifies anyone.
- An email or WhatsApp intake. In-app self-service, the tokenized staff portal and the public customer form are the three doors today; a mailbox that turns an incoming message into a ticket is the fourth.
Choosing the clock per category is what prevents contractual embarrassment, so settle it before you publish targets to customers. Note the asymmetry above too: a missed resolution target reaches the assignee and their manager, while a missed first response reaches nobody — the notification map sets out who hears about what.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsOur 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, set each category's clock to match the wording of the commitment behind it, 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?
It does if you tell it to. Each ticket category picks its clock: elapsed wall-clock time (the default), or working hours only. On the working-hours setting the clock counts against your configured business hours on days you work and stops for weekends and public holidays, so a four-hour target set on a Friday evening falls due mid-morning on Monday. On the default it expires that Friday evening. Match the setting to the wording of your contract rather than converting hours in your head. Note the boundary: this governs SLA due dates, not ageing reports, which count calendar days by convention 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.
