Less sorting in the IT service desk, more time for the tickets that need people

The service desk handles the same requests every day: passwords, VPN, printers, mailboxes, software and access rights. Each ticket is read, sorted, often sent to the wrong team, then answered with an article someone first has to find. AI takes over the reading, the sorting and the first draft. Your staff spend their time on the tickets that need a person, and second-level teams receive tickets that already contain what they need.

IT departments started late but are catching up. In Bitkom's 2026 survey of companies with 20 or more employees, 9% of the companies that use AI use it in the IT department, up from 2% in Bitkom's 2025 study, the steepest relative rise of any function. IT service providers are further along: in a 2025 survey by Kaseya with Foundry of IT system houses, managed service providers and IT service firms in the DACH region, ticketing and helpdesk was the most advanced AI use case, with 58.4% using AI there. The two surveys ask different groups, so their numbers are not directly comparable.

• Tickets reach the right team the first time instead of being passed around.
• Answers to recurring requests come from your knowledge base, with the article linked.
• Second-level teams receive tickets with the device, the error message and the steps already tried.
• On-call engineers find the runbook, recent changes and similar incidents in one place.
• You see the effect in your own numbers: hours per ticket and re-routed tickets, measured before and after.

The agent does the preparatory work on each ticket and hands the result to a person. The routing step itself is proven. In 2020 produktion.de reported that the IT company BTC, using SAP Service Ticket Intelligence, reached a hit rate of about 80% for work groups and 90% for priority in production, and named the problem behind it: work with “veralteten oder fehlerbehafteten Ticketinformationen”, outdated or faulty ticket information. That system predates today's large language models (LLMs), the models behind tools like ChatGPT. LLMs add the drafting, the follow-up questions and the runbook search, and that is the part we build.

• Classification and routing: category, priority and assignment group, with duplicates linked to the open incident they belong to.
• Answer drafts for recurring requests such as VPN, printers, mailboxes and software, built from your knowledge articles and solved tickets, with the sources linked so your staff can check them.
• Follow-up questions when something is missing, such as the device name, the exact error message or a screenshot, before the ticket reaches second level.
• Password and access requests: the agent checks the request against your role catalogue, prepares the change and sends it to the right approver. Password resets go through your existing self-service with multi-factor authentication.
• Runbook assistant for IT operations: on an alert or incident it finds the matching runbook, recent changes and similar past incidents, runs the read-only checks you approved and proposes the next steps.
• Knowledge upkeep: after a ticket is solved, a draft knowledge article for review, and a list of articles that keep leading to reopened tickets.

People keep every decision that changes access, systems or what a user is told. The agent prepares and your staff approve.

• Replies to users: your staff send, edit or reject each draft. Automatic replies for named, low-risk categories come only when the measured quality justifies them and you decide so.
• Access rights: the line manager or data owner approves each role or group. The agent only prepares the change in Active Directory or Entra ID, and your identity process applies it.
• Passwords: the agent never sees, sets or sends a password. A chat that resets passwords is an open door for social engineering, so resets stay with your self-service or with a person who verifies identity.
• Changes in production: by default the runbook assistant runs read-only checks. Any command that changes a system needs a named engineer's approval and goes through your change process.
• Security incidents, major incidents and anything involving a person's personal data go straight to people, without a drafted answer.

We connect the agent through its interface to the ticket system you run, for example ServiceNow, Jira Service Management, TOPdesk or SAP Service Cloud, and to your knowledge base on Confluence or SharePoint. Monitoring, the CMDB and your directory are added where a task needs them. Nothing is migrated. The ticket system stays the place where work is recorded.

• Tools with one job each: read a ticket, set a category, add an internal note, propose a group membership. Each runs under its own service account with the least privilege it needs. Where it fits we use MCP, a standard way to give an agent access to a system with its own permissions.
• Tickets are treated as untrusted input. Text in a ticket cannot change what the agent may do, and internal admin procedures never appear in replies to users.
• Hosting in your own cloud account in an EU region, or on your own servers with an open-weight model, a model whose weights you can run yourself. Tickets, knowledge and logs stay in your environment.
• One LLM gateway, a single controlled access point to all models with keys, budgets and logs, so you can see the cost per handled ticket.
• Build or buy: several ITSM suites sell their own AI features. If yours covers classification and answer drafts on your data and its hosting fits your rules, start there, and we can test it on your tickets. A custom build pays off when answers need sources outside the ticket system, such as SharePoint, file shares, monitoring or the CMDB, when data must stay on your own servers, or when one request runs through several systems and an approval chain.

Before go-live, the system runs an acceptance test on a set of your past tickets where the right category, team and answer are known. We report results per category, so you see where it is reliable and where it is not.

After go-live we measure what matters to you on your own tickets, before and after: hours per ticket, the share of re-routed tickets, the reopen rate and time to first response. The same tests run again after every change of model, prompt or knowledge base. You get runbooks for operating the agent itself, and either your team takes it over with the code and tests, or we run it.

• Routing: the share of tickets with the correct category, priority and team, compared with how your desk routes today.
• Answers: correct content, a source that supports it, and no internal-only information in replies to users.
• Safety: hostile tickets that try to give the agent instructions, requests to reset a password by chat, and access requests without an approver. The expected result is a refusal or a handover.
• Shadow mode: the agent then works alongside your desk on live tickets, its suggestions are recorded but not applied, and we compare them with what your staff did.

Tickets contain personal data: names, devices, locations and sometimes details people would rather not share. All of it is processed in your environment, and you decide what is stored and for how long, advised by your data protection officer and your lawyers. This section describes the technical side and is not legal advice.

The works council matters here for two groups: the service desk's own staff, and every employee who opens a ticket. Bitkom's 2026 guide on AI and co-determination notes that § 87 (1) no. 6 BetrVG applies when a system is objectively capable of monitoring performance or behaviour, whatever the intent. A system that could report tickets per employee or handling time per service desk agent falls under that. We design against it: no reports per person, pseudonymised IDs in the logs, agreed retention, and a short system profile your works council can read.

An IT support assistant is not among the high-risk uses the AI Act lists in Annex III, such as recruitment or credit scoring. The transparency duty of Article 50 has applied since 2 August 2026: people must be told when they are talking to an AI system, so the chat says so.

Start with one ticket stream that is frequent, repetitive and low risk, such as software requests or access requests for standard roles. That gives a clear baseline and an effect you can see.

• Export a set of past tickets from that stream, with the category, team and final answer each one received.
• Measure the baseline: hours per ticket, re-routed tickets and reopen rate.
• Agree the approval points and the logging with IT security, your data protection officer and the works council before the first test.
• Run the acceptance test, then shadow mode, then answer drafts that your staff approve.