Your first line gets 30 to 50 tickets a day, and it feels like two thirds of them are the same frustration — forgotten password, printer offline, missing access to folder X, Outlook won’t start. This page describes how to automate triage far enough that your team has time again for the tricky 20 percent — while a human stays in the loop where it counts.
Does this sound familiar?
- The person on first line spends 70 percent of their time on the same loop — classify, assign, type a standard reply, escalate to second line or resolve it themselves. The same routine, fifty times a day.
- Tickets land in the shared mailbox or the ticket system and sit there for four hours because nobody happened to be triaging. The person who submitted them assumes nobody cares.
- There are three standard replies that have been copied so often they now exist in six slightly different versions — each with its own typos.
- Urgent tickets get lost because they look exactly like routine tickets. Management hears that “IT is overloaded”, when the real problem is the process.
- When someone on first line is off sick or on holiday, the queue visibly backs up — there is no stand-in, and the knowledge of what goes where isn’t written down anywhere.
Why now — and not later
- Headcount grows, the IT team doesn’t. Mid-market IT teams run lean. Every additional employee generates tickets on average, but nobody hires an extra first-line person because of it. At some point the ratio tips.
- Good people quit when all they ever do is reset passwords. First-line work is an entry point, not a career. If you want to keep good people there, you have to keep the routine off their desks.
- LLM-based classification is now reliable enough for mid-market production use. Three years ago this was experimental; today it’s proven, operational technology — if you know its limits.
What this would look like at your company
Step 1 — Analyse the ticket history (weeks 1–2)
We look at the last 6–12 months of your tickets: what the most common category is, what the most common resolutions are, where things snag between first and second line, what gets misclassified and causes loops. The result is a map of which ticket types can be automated, which can be partially automated, and which have to stay human.
Stack: the API of your ticket system (Jira Service Management, Zammad, OTRS/Znuny, Freshservice, ServiceNow or Microsoft Dynamics 365 Customer Service — depending on what’s running at your company). Analysis in Python, delivered as a compact report for management and IT leadership.
Step 2 — Build the classifier (weeks 2–4)
We build a classifier that assigns each incoming ticket to a category (password, hardware, software, permissions, other), estimates its urgency (standard, urgent, critical) and suggests who it should go to. The classifier runs on a language model using your own category schema — not a generic off-the-shelf “IT classes” taxonomy.
Stack: Azure OpenAI in your own Azure tenant, a classification prompt with few-shot examples from your real tickets, optionally fine-tuned through evaluation runs.
Step 3 — Auto-assignment and suggested first responses (weeks 4–6)
For clear-cut categories, the ticket is automatically assigned to the responsible group and a suggested first response is generated — based on existing knowledge-base articles or similar tickets that have already been resolved. Important: in the first weeks, the first response does NOT go out automatically. A human reviews the suggestion and either hits send or corrects it. Human in the loop is the standard, not the exception.
Stack: a webhook or trigger in your ticket system, processing via Azure Functions or Power Automate, response generation via Azure OpenAI, optionally connected to your internal knowledge base from the RAG search.
Step 4 — Escalation logic with judgement (weeks 5–7)
Tickets the classifier is unsure about (low confidence) go back into the human queue and are NOT assigned automatically. Better to handle one ticket manually than to have ten misassigned ones wandering through every team afterwards. We calibrate the confidence threshold so that wrongly automated cases stay the exception.
Stack: confidence score from the classifier, a fallback rule in the trigger, logging into a dashboard view for IT leadership.
Step 5 — Trial one category, measure, expand (weeks 6–10)
We start with a single category — say, password resets and standard access requests — and measure for four weeks: how many tickets were pre-classified correctly, how often the suggested first response had to be edited, how fast the turnaround was. Only when the numbers hold up do we extend to further categories. The goal is not “automate everything” but “recognise the routine and handle it cleanly”.
What to look out for
- Ask to see the human-in-the-loop concept before anyone proposes “fully automatic” reply sending. An AI that communicates directly with end users without human approval during rollout is a reputational risk. A poorly worded reply to an already annoyed end user is worse than a slowly answered ticket.
- Clarify how misclassifications are handled. No classifier is 100 percent accurate. What matters is that wrong assignments become visible quickly and feed a correction loop — not that they get swept under the rug.
- Be wary of vendors selling you a ready-made “IT helpdesk AI” without ever having seen your ticket history. Your categories, your language, your standard resolutions are specific to you. An off-the-shelf classifier rarely matches your reality well.
- Make sure your ticket system is API-capable in the first place. If it only works via email or a rigid web form and offers no webhooks or API triggers, the automation gets more involved than expected. Sometimes the first step isn’t automation but replacing or upgrading the ticket system.
What realistically changes afterwards
- First line spends considerably less time sorting and typing, and more time on the tickets that genuinely need attention.
- End users get a faster first response — even when nobody is actively triaging, because the automatic note “Your ticket has been assigned to group X, expected handling by Y” goes out immediately.
- Urgent tickets are recognised as urgent and moved to the front of the queue instead of being buried in order of arrival.
- Standard replies become consistent — no more six variants of the same text with different typos.
- IT leadership gets solid figures, for the first time, on the most common ticket causes — and with them a basis for deciding where it pays to fix the problem at the root instead of answering the same tickets over and over.
What you contribute
- Access: read access to the ticket history (anonymised where personal data is sensitive) and administrative access to the ticket system to set up the triggers.
- Stakeholder time: the person who runs or leads first line today — an estimated 4–6 hours during the analysis phase, then 1–2 hours per week during the first trial weeks. Without that knowledge the classifier turns generic, and generic means bad.
- Works council and data protection: AI-supported processing of employee tickets is relevant for co-determination and data protection. We provide the technical documentation; you take it through your internal bodies.
- Willingness to consolidate your standard replies. The AI can suggest answers, but only based on what’s already well written at your company. If good templates don’t exist yet, the first deliverable of the project is, paradoxically, a tidied-up knowledge base.
Risks & when it does NOT fit
- If your ticket volume is under 10 per day and the routine share is small. Then the investment doesn’t pay off — a small improvement to your templates or a clearer triage protocol is the better lever.
- If the ticket system is a black box with no API access. Then sort out the system first, automate second.
- If the expectation is that AI replaces the entire first line. It doesn’t. It takes the routine off their plate and makes the job more interesting. Anyone planning to save money by cutting roles should be honest enough to say so at project start — not claim afterwards that “the AI decided”.
- If your data protection framework for AI-supported processing of employee requests isn’t in place. That can be sorted out, but not in two days — and not by IT alone.
How the conversation starts
A free 30-minute initial conversation, by video or phone. What we clarify: which ticket system you run, how many tickets per day, how first line is staffed, which topics feel like they repeat most often — and what triggered the question right now (staff shortage, complaints about response times, growth)? From that picture it becomes clear whether a classifier project is the right next step, or whether something else — tidying up the standard replies, for instance — would deliver more first.
Remote response is immediate during service hours. An initial conversation can typically be arranged within 3–5 working days; we confirm the next available slot as soon as you get in touch.
Frequently asked questions
What if the AI misclassifies a ticket? In the early weeks, that will definitely happen. That’s why a human reviews the classifications during the first weeks, corrects obvious errors, and those corrections flow back into the tuning. Only once the hit rate is stable above 90 percent for a category do we relax the human-in-the-loop requirement for that category. All other categories remain under human supervision.
Will Microsoft or OpenAI be reading our tickets? With Azure OpenAI in your own Azure tenant, Microsoft’s enterprise terms apply: your data is not used to train models and stays in the Azure region you choose. Tickets with particularly sensitive content (HR matters, health data) can be filtered out or anonymised before AI processing.
Do we need a new ticket system for this? No — not if the existing one supports APIs or webhooks. Picture a 100-person company running Jira Service Management or Zammad: both can be connected without replacing the system. If, however, your team still works out of a shared mailbox, that’s worth a conversation of its own: ticket system first, triage automation second.
How long until we notice it in daily work? In the first 4–6 weeks the changes are small and closely monitored — deliberately so. Noticeable relief typically arrives in the second to third month, once the classifier runs stably for the most common categories. Anyone promising “game-changing efficiency gains” after just two weeks either has no human in the loop or no realistic understanding of the mid-market.