Implementation worksheet · 6 min read
A Support Ticket Routing App Specification for Small Teams
Specify routing as four explicit decisions, in order: intake (what channels arrive, what fields are mandatory before a ticket exists), classification (the small closed list of categories, each with one named owner), assignment (the rule that maps category plus tier to a person, and the named fallback when that person is away), and escalation (the condition and the clock that moves a ticket to someone else). Write the fallback and the clock down explicitly — those two are what teams leave implicit, and they are the reason tickets sit unanswered for four days with nobody feeling responsible.
Helpdesk products ship capable routing engines: Freshdesk's automation rules, for example, can assign on keywords, custom fields and company conditions, and add CC recipients — which covers the integration-owner and copy-finance examples most small teams start with. The gap is rarely capability. It is that the rules live in someone's head rather than in a specification, so nobody configures them fully, the fallback is never set, and the whole thing fails the week the one person who knows it is away. This worksheet is what you fill in before configuring a product or building a queue — the specification is the same either way.
Put it into practice
1. Name the intake channels and the mandatory fields
Email, in-app form, shared Slack channel, whatever else. For each, list what must be present before the ticket is routable — account identifier, plan, a free-text description. A ticket missing a routable field goes to a triage state, not to a person, and the person who does triage is named.
2. Write the category list, and keep it short
Six to ten categories, mutually exclusive, each with exactly one owner name. If two people could plausibly own a category, the category is wrong — split it or merge them. The list being short is the point: long lists get mis-categorised, and a mis-categorised ticket is routed confidently to the wrong person.
3. Map category plus tier to an assignee, with a named fallback
The primary rule is usually category. The overrides are usually contract tier ('enterprise skips the queue') and keyword ('refund' copies finance). For every assignee, name the fallback and the condition that activates it — out of office, not acknowledged in four hours, whatever you will actually enforce.
4. Define escalation as a condition plus a clock
'Unacknowledged for four business hours' or 'reopened twice'. Escalation without a clock is a hope. Write what happens: who it moves to, who gets notified, whether the original owner stays copied. This is the rule that turns a routing table into a service commitment.
5. Decide what closes a ticket, and who can
Resolved-by-owner, resolved-by-requester confirmation, or auto-close after silence. Pick one and say how long silence lasts. Teams that skip this accumulate a queue of ambiguous half-closed tickets, which is indistinguishable from a backlog and demoralising in the same way.
The routing specification worksheet
Copy this structure into your review document and record your observed result for each row.
| Category | Owner | Tier override | Fallback | Escalation clock |
|---|---|---|---|---|
| Billing and invoices | enterprise → direct | 4 business hours | ||
| Integration: payments | ||||
| Integration: email | ||||
| Bug report | ||||
| Feature request | n/a | no clock | ||
| Account access | all tiers urgent | 1 hour | ||
| Anything mentioning refund | copies finance | |||
| Unclassifiable | triage owner | same day |
A failure worth checking
The silent fallback. Every rule routes correctly, the owner is on leave, and the ticket sits assigned to someone who is not reading it. Nobody else feels responsible because the system says it is handled. Four days later the customer escalates publicly. The fix is not a better engine — it is writing the fallback column in, and having an escalation clock that fires on unacknowledged rather than unresolved, because acknowledgement is the thing an absent owner cannot fake.
Common questions
Should I buy a helpdesk or build the queue?
Configure first. Most routing rules on this worksheet are expressible in a mainstream helpdesk's automation builder, so the honest first step is to write the specification and try to implement it in a trial. Build only when you hit a requirement the product genuinely cannot express, or when per-agent pricing for occasional helpers costs more than the routing is worth. Our <a href="/blog/best-helpdesk-software">helpdesk comparison</a> covers the buy side, including which free offers are time-limited.
How do I stop everything landing in 'unclassifiable'?
Usually the category list is too long or too abstract. Categories should match how requesters describe their problem, not how your system is built — 'I cannot log in' rather than 'authentication service'. If triage volume stays above roughly one in five, rewrite the list in the requester's words.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.