AI in the ticketing system: what it can take on at the service desk
In a ticketing system, an AI can triage new requests, spot duplicates, draft replies and suggest a solution from resolved tickets. To do so it reads the ticketing system through an interface, ideally with the permissions of the person asking. Deciding, replying and closing should be left to a person. Because tickets often contain personal data, it matters where the AI runs and whether content goes to an outside provider.
What can an AI take on in the ticketing system?
A service desk writes and reads all day: requests arrive incomplete, similar questions keep coming back, and the solution is often already in an old ticket. This is where an AI helps:
| Task | What the AI does | Who decides |
|---|---|---|
| Triage | suggests category, priority and responsible group | service desk |
| Find duplicates | recognises tickets about the same problem, for example during an outage | service desk |
| Suggest a solution | searches resolved tickets and manuals for matching solutions | the agent handling the ticket |
| Draft a reply | writes a reply in plain language | the agent handling the ticket |
| Summarise | summarises long histories before handover to another group | – |
| Build knowledge | suggests a knowledge article from recurring solutions | those responsible for the knowledge base |
This applies to IT service desks just as much as to requests from citizens, insured persons or referring doctors, when these end up in a ticketing system.
What does the AI need for this?
To answer an error description that someone pastes in, the AI needs no connection. For anything that has to know the existing tickets, it does: the AI reads the ticketing system through its interface. Jira and YouTrack offer REST interfaces for this; other systems such as Znuny, which continues the former OTRS Community Edition, can also be reached through interfaces.
What matters is which account the AI reads with. In the ticketing system, not every group sees every ticket, for example HR or security incidents. If the AI reads with a shared account that sees everything, its answers can break down these boundaries. Better: it reads with the access of the person asking. Access rights for AI with documents →
Where are the limits?
- Errors: the AI can suggest a wrong solution, especially for rare problems. The source of the solution, i.e. the old ticket or the passage in the manual, should be visible so that it can be checked.
- Injected instructions: tickets come from outside. A sender can insert text intended to make the AI do something else, such as writing internal information into the reply. Read-only access and approval by a person limit the damage. Manipulated instructions in documents →
- Autonomous workflows: an agent that assigns, answers or closes tickets without checks saves time but makes errors invisible. Write actions belong behind approval by a person.
- Assessing staff: analyses of who resolves how many tickets how quickly amount to performance monitoring. That is not what the AI at the service desk is for; the co-determination rights of the works council or staff council apply in any case.
Where should the AI run?
Tickets contain names, phone numbers, device data and, in hospitals, sometimes references to patients. If the AI runs at a provider outside your organisation, this content goes there. Check where the AI model runs, whether the provider stores inputs or uses them for training, and whether a data processing agreement is in place.
How does this work with basebox?
The basebox library includes connectors for Jira and YouTrack (“Tickets and projects”) and for Zammad (“Tickets and knowledge base”); the connector for Znuny / OTRS has been announced (“Coming soon”). Connectors from the library are included in the licence. For another ticketing system with an interface, we build the connector at a fixed price; the design is free of charge.
Every access runs with the person’s own access, with a shared service account only if you want one; people see only what they are allowed to see in the ticketing system anyway. By default basebox only reads, and every connector call is recorded in the audit log. basebox also drafts replies to an error description without a connection when someone enters the text. From November 2026, AI agents in the App Builder turn a description into apps with several steps; write actions then run only after approval by a person. The AI model in basebox runs in our cloud in the Munich-East data centre or on a server at your site, and your data does not train any model.
Frequently asked questions
Can the AI answer and close tickets on its own?
Technically this is possible if the AI is allowed to write to the ticketing system. For requests from staff, citizens or patients, a draft checked by a person is the safe route: the AI can be wrong, and a wrong answer given in the name of your organisation is hard to take back.
Does our ticketing system not already come with its own AI?
Many vendors are building in AI features, such as Atlassian with Rovo. Check where the data is processed and whether the feature also reaches knowledge outside the ticketing system, such as manuals or emails. An AI platform for the whole organisation can run alongside it.
What about personal data in tickets?
Tickets contain names, phone numbers and sometimes health data. The usual rules apply: processing only for the stated purpose, a data processing agreement with the provider, and data only where you control the processing.
Sources
This article was created with the help of AI, based on the sources listed. Responsible for the content: basebox GmbH. Not legal advice, no liability. Research as of 11 October 2026.