A report comes in: a user can't log in, a printer isn't working, a server is throwing error messages. Someone at the service desk turns that into a ticket, chooses a category, and determines the urgency. Can AI take that over? Largely yes, with one important exception that varies by company.
Three axes are decisive: volume, room for judgment, and customer contact.
The volume is high. A service desk processes dozens to hundreds of reports daily, and many of them are variations on a small number of known problems: forgotten password, no access to a share, laptop won't start. With high volumes and repetition, a task is by definition suited to automation, because a model learns from patterns that recur frequently.
The room for judgment is limited. Urgency and category usually follow from a decision tree: how many users are affected, is there a workaround, which system is involved. That is exactly the kind of work text models are good at: reading a report, extracting the characteristics, and matching them against a categorization model. What AI can handle today is text — the reports themselves, often typed in free-form wording by the user, and translating that back into a structured ticket.
The customer contact is functional, not relational. A user reporting a disruption mainly wants it to be picked up, not to have a conversation. That is different once things go wrong or become sensitive — see also how communicating a disruption to users is handled, because that is a different task with a different profile.
The physical component plays no role: this is administrative work at a screen, not a hands-on action with equipment. The cost of errors is average. A misprioritized report rarely leads to direct damage, but for systems that fall under compliance — a financial system, a patient record — that is different, and the compliance axis therefore scores higher than average here. A disruption in an environment with a statutory reporting obligation requires a documented reason for the classification, not just a label.
The weak spot is creativity, and that is precisely why this is not a full takeover. A report that doesn't fit the known pattern — a new combination of symptoms, a system failing for the first time, a user describing the problem unclearly — requires someone who thinks rather than classifies. That calls for oversight: AI proposes a category and urgency, a human approves or adjusts it, with a reason. That is a different setup than full takeover, and it is also the most common practice among companies already working with this.
At a company with a small, well-organized application landscape and a few hundred users, ninety percent of reports are a repeat of something that has already happened a hundred times. There, a model with a good categorization model can handle most of the intake independently, with a human only seeing the exceptions.
At a company with many legacy systems, custom software, and a history of mergers, the pattern is less predictable. Reports are more diverse, the categories are less sharply defined, and the chance that a report falls outside the known pattern is greater. There, a larger share of the work remains with a human, not because AI wouldn't want to do it, but because the input is too unstructured to reliably automate.
The precondition, then, is not the technology but the intake: structured intake forms and a well-developed incident categorization model largely determine how much of this work is already transferable today. Without those two, most of the work remains manual, with AI as an aid rather than an executor.
This is not personnel advice and not a basis for shrinking a service desk team. Whether and how an organization draws personnel consequences from changing work is up to the employer, and its own statutory requirements apply there; for the diligence that goes with that, see the points of attention when cutting positions. This page describes only what happens to the task itself.
It is also useful not to view this task in isolation from the rest of IT operations. Incident registration is connected to work such as monitoring system performance, which often gives the early signals before a report even exists, and to management tasks such as performing and checking backups or keeping master data up to date, which share the same combination of high volume and limited room for judgment. Anyone who wants to know where the shift already lies for an entire IT department is best served by looking at all tasks together, not at a single ticketing process.
The outcome for your own service desk depends on how much of your reports fall into recognizable patterns and how well your intake is already structured. This differs by company and cannot be captured in a fixed rule of thumb.
The free quickscan from FTE TO AI offers a first indication: twelve questions, no account needed, with an indication of what share of the hours in your profile can be taken over by AI today. The full work scan, which calculates the work of an entire company task by task into FTE capacity, is still under construction.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.