What is AI automation within ITSM?

"AI automation" now appears on virtually every vendor brochure, and means less and less as a result. 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 assuming any one product: 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 call falls in category X, it goes to operator group 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, which is 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 a call that is mis-routed at the start takes longer to reach someone who can resolve it.

Generating

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

Predicting

The model estimates something about the future: how many calls will come in next month, which call 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 calls and at the same time raises the average complexity of what remains. You will usually 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 calls have been filed under the wrong category for years, that is exactly what it will learn.

What you need in place

1. A category structure that holds up. Not too fine-grained, and matching how the work is divided. This underpins both classification and reporting.
2. A knowledge base that is maintained. Everything knowledge-related, such as suggestions, self-service and drafts, stands or falls with this.
3. History you can build on. How much you need depends on what you are predicting and how much your figures fluctuate. For a forecast of the number of calls per month, a year is too short: you only recognise a seasonal pattern once it repeats.
4. Clarity about where the data goes. See below.

The question you will get regardless

Calls 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. That should be the first question at the first review.

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 system makes a suggestion and the operator decides. Work out beforehand how you will measure the effect, though, because not every product records which suggestions were accepted. With AI triage, for example, TOPdesk does not store which values came from a suggestion. If it does not work, 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.