Manual triage is the hidden tax on a support team. Someone has to read every incoming ticket and decide who takes it, which means one person is permanently half-distracted and every ticket waits on their attention before it waits on anything else.

Routing removes that step. This guide covers the three approaches worth using, in the order you should reach for them.

1. Route at the front door

The cheapest routing happens before the ticket exists. If your panel has separate buttons for billing, bugs, and appeals, each button can assign a different role on open. No rules to maintain, no logic to debug, and the member has done the categorisation for you by picking a button.

This handles the majority of routing in most communities. Do this first, and only add rules for what it cannot express.

Keep the buttons few and obvious

Three to five buttons with plain labels beats nine precise ones. Members do not read a panel carefully; they pick the first option that looks close. Nine options means more mis-filed tickets, which means more manual re-routing, which is the thing you were trying to eliminate.

2. Rules for the exceptions

Rules are WHEN / IF / THEN statements evaluated as the ticket opens. They are the right tool when the routing depends on something the member typed rather than the button they pressed.

  • When a ticket opens, if the form field "platform" is "Console", then assign the console team.
  • When a ticket opens, if the opener has the Subscriber role, then assign the subscriber team and post the response-time note.
  • When a ticket opens, if the subject contains "refund", then assign finance and attach the refund policy.

Order matters: rules evaluate top to bottom and the first match wins, so put your narrow rules above your broad ones. A catch-all rule at the top will silently swallow everything below it.

Write rules you can read out loud

If explaining a rule to a new moderator takes more than a sentence, it is too clever. Split it into two rules, or handle it with a separate panel button. Clever routing logic is the first thing to rot, because the person who wrote it is the only person who understands it.

3. Round-robin for load, not for fairness

Round-robin hands each new ticket to the next person in a rotation. It is genuinely useful when your team members are interchangeable for a given category, and actively harmful when they are not, because it will cheerfully assign a database question to whoever is next in line.

Use it inside a specialised group rather than across the whole team. Round-robin among the three people who handle billing is good. Round-robin across everyone is a lottery.

The escape hatch matters most

Every routing setup mis-files tickets sometimes. What separates a good setup from a frustrating one is how fast a human can override it. Reassignment should be one action, visible to everyone in the thread, and it should not require an admin.

Watch what gets reassigned. A category that gets manually re-routed constantly is telling you exactly which rule to fix, and it is a better signal than any amount of planning.