What is AI automation within ITSM?

Reading time about 6 minutes

"AI automation" now appears on virtually every vendor brochure, and means less and less for it. For anyone running an ITSM environment the practical question is simpler: which actions can a computer take over, with what confidence, and what is then left for people?

This article sets that out without product names — what holds true applies as much in TOPdesk as in ServiceNow or Jira Service Management.

Two things often lumped together

Automation and AI are not the same, and the distinction is useful.

Rule-based automation is an agreement you write down yourself: if a ticket falls in category X, it goes to team Y. Predictable, explainable, and when it goes wrong you know immediately which rule to change.

AI predicts from examples. You write no rule; you let a model infer the patterns from what has happened before. That works where a rule cannot be formulated — nearly always because the input is free text.

In most organisations the balance is lopsided: there is far more to gain from rules that were never set up than from AI that is not there yet. It is tempting to reverse that order, because the second sounds more interesting.

Three kinds of application

Classifying

The model assigns a label: this is an incident, not a request; this belongs with network management; this is more urgent than the caller indicated. This is the most mature application within ITSM and usually the most useful, because mis-routing at the start of the chain determines the whole resolution time.

Generating

The model writes text: a summary of a long ticket, a draft reply to the caller, a knowledge article based on a resolved ticket. Useful, provided a person checks it before it goes out.

Predicting

The model estimates something about the future: how many tickets will arrive next month, which ticket will breach its SLA, which device is about to fail. This is the application with the most promises and the least evidence — it needs a lot of good-quality history, and that is often missing.

What it is not

Three misunderstandings keep coming back.

It is not a replacement for your service desk. A chatbot that catches simple questions lowers the number of tickets — and raises the average complexity of what remains. You will not need fewer people afterwards, but different ones. That is a good outcome, but it is not a saving.

It does not fix a bad process. If nobody knows who is responsible for what, smarter routing only moves that problem somewhere less visible.

It does not work without data of reasonable quality. A model learns from your history. If tickets have been filed under the wrong category for years, that is exactly what it will learn.

What you need in place

A category structure that holds up. Not too fine-grained, and matching how the work is divided. This underpins both classification and reporting.
A knowledge base that is maintained. Everything knowledge-related — suggestions, self-service, drafts — stands or falls with this.
History you can build on. A year of reasonably recorded tickets is the minimum before prediction is worth attempting.
Clarity about where the data goes. See below.

The question you will get regardless

Tickets contain personal data: names, phone numbers, sometimes medical or financial context in the description. The moment that text goes to a language model, the question is where that model runs and what happens to the input. For healthcare and government organisations that is the first question at the first review, and rightly so.

What to establish before you start: where the model runs, whether input is used for training, how long it is retained, and who is accountable if it goes wrong. If that is not written down, the feature is not ready for use — however well it works.

A reasonable first step

Pick one application where a mistake costs little and the effect is measurable. Category suggestions fit well: the suggestion sits next to the dropdown, the agent decides, and you can count how often the suggestion is accepted. If it works, you see it in the figures. If it does not, you switch it off without anything having gone wrong.

That is less spectacular than the brochure, but it is the only way to find out whether it works in your environment rather than in the demo.