Use case assessment

Is AI ticket routing worth building?

Usually not. A rules engine does most of this better, and you can read why it made each decision.

Enterprise ITSM · support operations
Verdict Usually automation with a label

Most ticket routing is a classification problem with a small, stable set of categories and an existing routing table. That is what rules are for.

What it usually means

An incoming support ticket is read and assigned to a queue, a team or a priority. The proposal is normally to replace a rules engine, or to replace a human triaging a queue.

Is it genuinely AI?

Usually not, and the test is quick. Look at how many distinct destinations a ticket can go to, and how often that list changes.

If it is twelve queues that have been the same for two years, a rules engine routes on keywords, requester group and product area and gets most of it right. More importantly it tells you why it routed each ticket, which matters the first time someone escalates a misroute.

The case for a model appears when the destination depends on meaning rather than vocabulary — when two tickets using entirely different words need the same queue, and no keyword list closes that gap. That happens, but far less often than the proposals suggest.

What the simpler version looks like

A rules engine on requester attributes, product area and a keyword set, with a default queue and a weekly review of what landed in it. The default queue is the important part: it is your list of the cases rules do not cover, and after a month it tells you whether you have an AI problem or a rules problem.

That review costs an hour a week and answers the question the pilot was going to answer in a quarter.

What it costs to run

The inference cost on ticket classification is small — short inputs, short outputs. What is not small is everything around it: an evaluation set that someone has to label, monitoring for drift as products and terminology change, and a fallback path for low-confidence classifications.

A rules engine costs a config change when routing changes. A model costs a re-evaluation, and someone has to notice it is needed.

Where it sits under the EU AI Act

Internal ticket routing is not normally an Annex III high-risk use. It becomes one if the tickets concern access to essential public or private services and the routing materially affects who gets served.

If the system communicates with the requester — an acknowledgement, a status update — Article 50 disclosure applies, and that has been enforceable since 2 August 2026.

When it is worth building

When the default queue stays full after you have tuned the rules. When routing depends on meaning rather than words. When volume is high enough that a few percentage points of accuracy is a real number of hours.

Not when the current pain is that nobody maintains the routing table. A model will not fix that; it will hide it.

Common questions

Does ticket routing need AI?

Usually not. If the set of destinations is small and stable, a rules engine routes on requester attributes, product area and keywords, and explains each decision. The case for a model appears when routing depends on meaning rather than vocabulary.

How do you know whether rules are enough?

Tune the rules, add a default queue for anything they cannot place, and review that queue weekly for a month. What lands there tells you whether you have an AI problem or a maintenance problem.

Is AI ticket routing high-risk under the EU AI Act?

Not normally. It can become an Annex III high-risk use if the tickets concern access to essential services and routing materially affects who gets served. If the system messages the requester, Article 50 disclosure applies regardless.

Seen in practice

Cutting enterprise change requests 15 to 7 minutes — an enterprise ITSM agent where the scope cut, not the model, is what moved the numbers.