Home › Insights › More grip on ITSM
More grip on ITSM without buying a new tool
· Reading time: about 6 minutes
When service delivery runs into problems, people often look at the tool first. The thinking is that TOPdesk does not do what the organisation wants, so perhaps it is time to move to something else. In practice the cause tends to be something that has not been configured or recorded, or that nobody can see.
So you can often get much further with what you already have.
The tooling is rarely the problem
TOPdesk, ServiceNow and Jira all handle incidents, changes and activities perfectly well. The usual problem is a configuration that was set up for a situation that has since changed, and that nobody has looked at again.
Before you consider a migration, which can easily take months and does not improve your processes by itself, work through the four points below.
Four things that are often missing
1. A category structure somebody actually uses
Categories tend to accumulate. One is added for a project and somebody later creates a variant of it. Three years on there are forty, and only eight are actually used. Filtering by category then no longer tells you much.
Cleaning up takes patience, but afterwards filtering by category tells you something useful again. As a rule of thumb, if you cannot say which decision depends on keeping two categories apart, you can merge them.
2. Routing that matches how work actually flows
Take a look at how often incidents move from one operator group to another. If incidents in a particular category start at the first line and are then escalated to the same second-line operator group every time, the first line is only forwarding them and no real triage takes place. Each handover costs time and some context is lost, and nobody notices because the delay is hidden in the overall resolution time.
3. Recording what happened to an incident
Most organisations know who has an incident at the moment. Far fewer can see which operator groups it passed through and how long it stayed with each one. Yet that route is where the room for improvement lies. It is not about working faster, but about waiting less.
For incidents, the route is available in the TOPdesk reporting feed. For changes, as far as could be checked, there is no source you can read outside TOPdesk: not in the REST API and not in the reporting feed. The route of changes is therefore the only thing on this list you cannot fix retroactively. Any part of that route you do not record now will still be missing three months from now.
4. A set time to look at it
Without a fixed routine, people soon stop looking at the figures. Half an hour a month on the same four charts, with one person responsible for asking what stands out, is more useful than a dashboard full of charts that nobody opens.
Automate routine work first
Before you start optimising, clear out repetitive work such as password resets, standard hardware requests and recurring incidents about the same system. It soon saves you time, and your figures get cleaner because the work that remains needs someone’s judgement.
Automating routine work does not have to be a large project. A few standard forms with the right fields and a fixed route are often enough.
Make it measurable, then improve
Get a clear view of what is happening before you change anything. If you start improving without a baseline, you cannot tell afterwards whether it helped. Many improvement plans stall for that reason.
For every incident you need to know when it came in, which operator groups had it and for how long, when it was resolved and whether the target date was met. Most of the questions management asks can be answered with those four pieces of information.
When the tool is not enough
Sometimes you do find that something is missing. In most cases it is the layer on top of the ITSM system, the part that makes things visible. TOPdesk is very good at recording and has its own reporting module and dashboards. Presenting what has been recorded in a clear overview takes different skills. Whether TOPdesk’s own options are enough for that depends on the organisation and the question.
That is a much smaller step than a migration. You keep your processes, your configuration and your history in TOPdesk. You make visible what TOPdesk already records. Some of it, such as an overview of the route of changes between operator groups, you build up from the moment you start.