Where to start with AI · First workflow No. 6

Triaging and routing IT tickets

An assistant for triaging internal support tickets, rolled out in two stages: first it suggests a triage for the technician, then it routes approved standard requests on its own.

A first AI use case doesn’t need to be spectacular. It does need to be narrow enough to test, measure, and improve.

Download the Scoping Sheet (PDF, 2 pages) View the Carousel (PDF)

Low risk, but only within a strict scope

Internal support tickets meet all four tests of a good first workflow: they come up often, they have a clear owner, they call for a clear output (a ticket correctly categorized and assigned), and they are a pain point that support staff and employees already feel.

The use case is low-risk only within a strict scope:

A written service catalog current categories, priorities, and teams.
No admin rights and no account actions taken by AI.
Password resets and standard access requests through the existing secure workflows.
Incidents, security issues, and ambiguous cases routed to technicians.

The assistant works from a service catalog and a knowledge base the company already has. The risk does not go away. It becomes more visible, measurable, and manageable once the categories, the scope, and the escalation rules are defined.

A three-step approach

Get the catalog in order

Clarify categories, the priority matrix, and teams; retire outdated articles; give each article an owner and a version date. The tool comes after.

The assistant suggests a triage; the technician decides

The assistant suggests a category, a priority set by the matrix, a team, and the knowledge base article that applies. The technician confirms, corrects, or reassigns. Every correction is logged, category by category.

The assistant routes standard requests

It routes tickets in approved categories directly to the designated team, or answers with a current article and a link to the secure self-service workflow. It escalates to technicians any incident, any urgent or ambiguous request, any security issue, and any privileged access request.

Moving from stage 1 to stage 2

The move to stage 2 should not be decided in advance. It depends on what support observes during stage 1: the accuracy of the suggested triage, the corrections needed, and the system’s ability to recognize tickets that fall outside its scope.

Accuracy of the triage and the cited articleReassignments needed, by categoryExceptions correctly routedNo significant incident within the tested scopeCurrent articles, each with an owner

Printer requests could move to stage 2 while application access stays in stage 1.

Reference architecture: how the system stays under control

Ticket classification with a confidence score, priority set by a fixed-rule matrix, hybrid search across the articles, and a suggestion drafted by an LLM instructed to cite the article used, with input and output guardrails and escalation to technicians. No action on any account. A learning loop connects the log, support review, and the evaluation set.

Click the diagram to open it full size.

The controls required before any autonomous answer:

Evaluation. A reference set of about 300 past tickets, minimized, each with the expected category, team, and priority. Metrics: triage accuracy, reassignment rate, citation accuracy, and the rate at which exceptions are detected and correctly routed. Rerun whenever the model, the catalog, or the instructions change.

Observability. Every ticket processed is logged: category, priority, suggested article, confidence score, routing decision. Since tickets can contain personal data or secrets, the log is minimized, accessible only to authorized staff, and kept for a defined period.

Identity and access. SSO (SAML or OIDC). The assistant has no admin rights: password resets and access requests go through the existing workflows, including MFA and approvals.

Data. Hosting and data transfers verified for the chosen solution; contractual terms barring use of the data for model training; encryption; log retention and access defined; documented Swiss FADP assessment before launch.

Application security. Prompt injection defenses for ticket text; attachments, if analyzed, are extracted in an isolated environment. Only four outcomes: suggest, route, answer, or escalate. No command is ever run on any system.

Corrections feed first into the articles, rules, instructions, and evaluation set. Retraining the model is neither the starting point nor a substitute for that work.

The goal

The goal is not to replace technicians. It is to cut response time on simple requests, stop the same tickets from being triaged and reassigned by hand, and focus support time on incidents that call for diagnosis and judgment.

Download the Scoping Sheet (PDF) View the Carousel (PDF)

Illustrative case: fictitious company; all figures are approximate. Sergio Castagna Consulting is a member of the OpenAI Partner Network and a registered partner in the Google Cloud Partner Network. The tool comes after the problem is defined.