AI ticket triage for technical service: schema, thresholds, controls

AI ticket triage means that an AI agent reads every incoming email, portal submission and phone note, classifies it against a fixed schema with a confidence score per field, and routes it to the right team with the relevant context attached. Customers keep writing to the same service inbox and your engineers keep answering; the agent works between the inbox and the ticket system.

It follows the same mechanics as any agentic workflow: intake, context, proposal, release, write-back. The agent reads the text and the attachments, pulls customer, asset and contract data, sets category, priority and assignment group, and drafts a reply for routine cases. A person releases, and the agent then writes the result back to the ticket system. The page on service triage covers the whole workflow, including release stages and metrics.

An AI service desk in this sense is not a chatbot. A chatbot talks to customers, whereas the agent prepares work for the people who talk to customers. No statement about an asset, a response time or liability therefore leaves the building before an engineer has read it.

Keyword rules break because they match words, not cases. ‘Urgent’ appears on a reorder of wear parts just as it does on a breakdown report from a stopped line, and ‘complaint’ appears in the signature of every email sent from a department called Complaint Management. Email classification that reacts to terms routes both the same way.

Every exception adds a rule, until one person maintains the rule set and nobody can say which rule overrides which. Misrouted tickets then bounce between teams, and each hand-over adds to the time to first response. A language model reads the whole case the way an experienced dispatcher does and can state why it classified it as it did. These are the patterns that regularly defeat simple routing:

A workable schema has five fields, each with a closed list of values and a defined source: type, urgency, product or asset, customer and contract, and language. Closed means the agent may only assign values from the list, and ‘other’ is an explicit value rather than an error.

Urgency shows the difference from keyword rules most clearly. The agent derives it from the described state of the asset and the response time in the service contract, so a standstill at a contract customer ranks above a scheduling request even when only the scheduling request says ‘urgent’ in the subject line.

Values follow the teams that act on them, not the organisation chart. If spare-parts requests and maintenance bookings land with the same team, routing needs one category, even if reporting wants two. Test the schema before the agent gets it: two experienced dispatchers classify the same sample of historical tickets independently. Where they disagree, the schema is ambiguous, and no model will make it clearer.

The language model receives the request with its attachments, the schema definitions and examples per category, and returns a value and a confidence score for each field as structured output that the ticket system takes over directly. What happens next is decided by a threshold per category, not by the model.

A confidence score is only as good as its calibration. A value of 0.9 means something once nine out of ten tickets with that score were classified correctly in the test set, so every score is checked against real tickets labelled by people. Thresholds differ by category: a documentation request can be routed automatically at a lower confidence than a breakdown on an asset whose contract promises, say, a four-hour response.

Below the threshold the agent writes no draft. The ticket goes to a dispatcher's queue with the two categories the agent was torn between and the context it has already pulled, so the person decides instead of searching. The guide to human in the loop covers how to set these release points.

Before go-live the agent runs in shadow mode for several weeks. It classifies every ticket in parallel while dispatchers route as usual, and the comparison shows the misrouting rate per category. Thresholds are set from that comparison, not from an estimate. Because the model reads content rather than matching words, the same classification works for German, English and Italian requests, provided the test set contains all three languages.

Classification decides who gets the ticket; enrichment decides how quickly that person can answer. The agent attaches asset history, contract and open orders before a person opens the ticket, which replaces the search across CRM, ERP and archive that otherwise comes before the reply.

It writes a draft only above the threshold and only in categories released for drafting. Every statement in the draft points to its source, such as the report from the last field visit or the relevant chapter of the operating manual. If a detail such as the serial number is missing, the agent drafts a question to the customer instead of a reply, and a person releases that as well. For a technical service ticket the agent typically pulls four kinds of context:

An AI service desk does not need a new ticket system. It needs an agent that reads through the existing interface and writes back within narrow limits. ServiceNow, Jira Service Management, Zendesk and SAP Service Cloud all document APIs for reading and updating tickets, and in each system roles and permissions govern what a technical user may do.

The agent sets category, priority and assignment group, adds an internal note listing its sources, and attaches a draft reply in categories released for drafting. It cannot send, close or change other fields, because the rights of its technical account and an integration layer that passes on only the released fields prevent it. When a request arrives by email, the agent reads the ticket the system created from it, including photos, PDF service reports and spreadsheets in the attachments.

In a Workflow Build this integration is built in your own cloud tenant and repositories, with a test set, shadow mode and logging, and without an additional platform or licence.

Complaints, safety issues and contract questions always go to a person, regardless of confidence. The agent still classifies and enriches these cases but drafts no reply, and the routing to the named role is fixed rather than dependent on a threshold. Complaints reach the claims team with the case file prepared; the guide to the complaint management process describes how that process is built.

The rest of the control set covers permissions, logging and escalation. The agent reads the CRM, ERP and documentation and writes only to the ticket system, and there only to the released fields. For every case it logs the input, the sources pulled, the proposal, the confidence and the release, with name and timestamp. When the agent escalates, it states the reason in the internal note, such as ‘safety issue detected’ or ‘unknown sender’, so the monthly review shows which rule fires how often. These cases never run automatically:

Four KPIs show whether triage works, each measured against a baseline from before the agent: misrouting rate, time to first response, share of drafts released without edits, and reopen rate. The ticket history of recent months provides the baseline, and a Workflow Assessment measures exactly these values before anything is built. The workflow check tells you in ten questions whether your service inbox is a good first workflow.

Measure the workflow, not individual engineers. In Germany, evaluating these numbers per person engages the works council's co-determination right over technical devices designed to monitor the behaviour or performance of employees (section 87(1) no. 6 of the Works Constitution Act). Annex III, point 4(b) of the EU AI Act also lists as high-risk the AI systems that allocate tasks based on individual behaviour or that evaluate the performance of workers. An agent that routes tickets to teams by content is not built for that, but the classification still belongs to your compliance function.