Evaluate the specific rule before the general one

Ordered rules in the example app
OrderMatchDestinationResult
10Meeting room + any locationWorkplace supportIf the destination has no technician, keep the ticket in triage.
20Hardware + East office + laptopService deskA specific site and device rule is evaluated first.
30Hardware + any location + any assetService deskA broader rule catches devices without a more specific match.
No matchOther combinationsTriageAn explicit fallback is better than an invisible unassigned ticket.

A match must lead to someone who can act

East-office laptop

The site-specific laptop rule wins over the broader hardware rule. The saved ticket records which rule made the assignment.

West-office printer

The general hardware rule provides a destination when the narrower laptop rule does not apply.

Meeting-room issue without a handler

The category matches, but the missing assignee sends the case to triage. A matching category is not sufficient if nobody will receive the work.

Unrecognized software issue

No rule matches the new combination. The ticket remains visible with an unmatched result, ready for a support owner to assign.

Keep assignment changes deliberate

  1. Keep rule order unambiguous

    Give each active rule a distinct order. Put the most specific exceptions before general rules and inspect overlapping combinations before enabling a change.

  2. Respect manual reassignment

    Record the new team, technician, and reason in a ticket update. Changing a routing rule should affect future intake, not silently overwrite a person’s deliberate handoff.

  3. Review fallback cases

    A growing triage queue may mean a new service category, incomplete input, or a missing handler. Fix the cause instead of adding an excessively broad rule that hides it.

This is deterministic rule-based assignment. It does not claim AI classification, skill inference, workload balancing, or round-robin distribution. Those require their own routing model and acceptance tests.

Maintain the rules when teams change

Review unmatched cases regularly. A recurring category may need a new rule, while a one-off exception may only need manual assignment. Before changing a rule, confirm the receiving technician is available and accepts that work. Try one matching case and one case that should fall through to the next rule. New rules apply to new submissions; they should not silently move tickets that somebody is already handling.

Assignment rules and exceptions

What happens when two rules match?

The matching rule with the lowest order wins. Keep orders unique and test both specific and general examples so a broad rule does not swallow a deliberate exception.

Can a ticket remain unassigned?

Yes, when no rule matches or the destination lacks a technician. The example makes that state explicit in the triage queue rather than pretending the ticket was successfully assigned.

Will changing a rule reassign existing tickets?

The initial routing process is for new tickets. Use a recorded manual reassignment when an existing case needs another owner; do not assume a rule edit changes the current queue.

How does priority affect routing?

The example calculates priority from impact and urgency and retains it on the ticket. Its routing rules use category, location, and asset class; adding priority-based destinations is a separate rule change to configure and test.

Is this AI ticket routing?

No. The rules are explicit and inspectable. Use this approach when the organization can describe its assignment policy; evaluate a specialist option when classification or workload optimization is the main requirement.

Start with the rules your triage team already uses

Test specific, general, unmatched, and missing-handler cases before applying the assignment policy to live employee tickets.

Use the routing example