Streamlining ITSM processes in five steps

Most ITSM problems are not tooling problems. The tool can do it; it was simply never decided how it should work, so everyone does it slightly differently. The result is familiar: the same ticket in three places, figures nobody dares steer on, and a backlog whose contents nobody can quite recall.

Below is a five-step plan we follow in practice. It is deliberately not exhaustive — it is the order that produces a visible result soonest.

Step 1: Analyse and prioritise

Do not start by improving; start by looking. Map which processes exist, who runs them, and where work gets stuck. Not on the basis of the process description, but on what actually happens — those two diverge more often than anyone finds comfortable.

Three things to look for specifically:

• Duplication. The same question arriving through two channels and being logged twice.
• Handovers. Every time work passes from one person or department to another is a place it can stall. Count them, and see how much lead time is lost at each.
• Work outside the system. If a substantial share of questions is resolved outside the tool, your figures are wrong and every decision based on them is guesswork.

Then prioritise on business value, not on how much something annoys someone. A bottleneck that occurs fifty times a week and costs three minutes is worth more than one that costs an hour every month.

Step 2: Automate sensibly

“Sensibly” here means: automate what happens often and predictably, and leave the rest alone. The biggest risk in automation is making a bad process faster.

The order that usually returns the most:

1. Routing. Tickets that send themselves to the right agent based on category, location or type of reporter. This saves the most in nearly every organisation, because it sits at the front of every chain.
2. Confirmation and feedback. Automatic messages to the reporter on logging, on a status change and on closure. This measurably reduces the number of “any update?” calls.
3. Escalation. A signal when a ticket approaches the agreed resolution time, rather than finding out in the monthly report.
4. Standard requests. Password resets, account requests, access to a shared folder. Work that requires no judgement and therefore no person.

In TOPdesk you configure this with Events and Actions. It is work you do once and that pays back every week. Our experience is that the first four or five actions deliver the bulk of the gain, and that complexity rises steeply after that without the return following.

Step 3: Integrate tools and data

Once the basics are in place, the next gain lies in removing double entry. Every place where a person retypes data from one system into another is a place where it goes wrong.

The integrations that return the most in practice:

• HR system. Joiners, movers and leavers automatically creating the right tasks. Leavers matter most, because the absence of that integration is a security risk: accounts that persist because nobody passed it on.
• Identity management. Users, departments and groups synchronised with Entra ID or an equivalent source, so personal data is maintained in one place.
• Monitoring. Outage alerts creating a ticket automatically, so the service desk knows before the first user calls.
• Asset sources. Equipment and licences from a purchasing or management system, so your CMDB stays current without manual work.

This runs through the TOPdesk API. One important decision up front: determine, per data element, which system is the source of truth. Without that decision you get two systems overwriting each other, which is worse than no integration at all.

Step 4: Make communication transparent

This step is skipped most often and accounts for the biggest gap between “the figures are good” and “people are satisfied”.

Concretely: a self-service portal where a reporter can see the status of their own request without calling. A knowledge base answering the questions that come up most. And closing feedback that explains what was resolved, not merely that it was.

A portal nobody uses is a common outcome, incidentally. That is nearly always because the portal takes more effort than sending an email. The test is simple: if reporting an issue through the portal takes more than three actions, people will not use it.

Step 5: Improve continuously

Step four only matters if somebody looks at the result. Without a fixed moment at which the figures are discussed, nothing changes — not even with a perfect dashboard.

What works: one fixed review a month, with a fixed agenda. What happened, what stood out, what will we tackle next month. No longer than an hour, and with someone present who can decide.

The figures that belong in it are fewer than you might expect:

• Tickets in and out — is the backlog growing or shrinking?
• Resolution time as a median rather than a mean — one three-month outlier distorts an average entirely.
• Reopened tickets — the best antidote to steering on speed alone.
• Workload per agent — not to hold people to account, but to see whether the work is fairly spread.
• Reporter satisfaction — the only one that measures whether it works for the organisation rather than for the department.

Where it usually goes wrong

Three patterns we see again and again:

Wanting everything at once. An improvement programme that tackles five processes simultaneously produces five half-finished processes. Do one, finish it, and use the result as the argument for the next.

Making the process heavier than the problem. A change process with four approval steps for ten changes a month gets circumvented within a quarter. Weigh the weight of the process against frequency and risk.

Improving without an owner. If nobody is tasked with maintaining it, every improved process drifts back to where it was within a year. That is not obstruction; it is what happens when something is nobody's job.