Restoring is not the same as solving
The goal of incident management is to get the business working again – not to find the root cause.
A workaround that lets thirty people get back to work is the right decision even if the fault remains. The root cause is handled separately, in problem management.
That separation is harder to maintain than it sounds. A technician who has found something interesting would rather keep digging while users wait.
Prioritize by impact and urgency
Priority should be set by how many people are affected and how urgent it is – not by who gets in touch.
A manager with a broken keyboard is low priority. A finance system down the day before month-end close is high. Upholding that principle is one of the hardest and most valuable things a service desk does.
Build a simple matrix with three levels of impact and three of urgency, and let the system calculate the priority. When priority comes from a rule rather than from a phone call, it also becomes defensible.
The flow
Registration. Everything is registered, including what takes two minutes to solve. Unregistered tickets make your statistics useless and hide recurring faults.
Categorization. Keep the list short. The category is what later shows you what to automate or fix at the source.
Prioritization. According to the matrix, automatically.
Assignment. To the right queue based on category and skill, not to a named person who may be away.
Action and updates. The user should know what is happening without having to ask.
Closure with a cause code. This is where the input for problem management is created.
Major incidents need their own routine
When something large is down, it is rarely the technology that determines how well it goes. It is who decides and who informs.
Appoint an incident manager who does not troubleshoot personally. Communicate at a fixed interval even when there is nothing new to report – silence is always read as nothing happening. Document the timeline as you go, because nobody remembers it afterwards.
The metric that says the most
The share of tickets resolved in the first line. If it falls, that is a sign your knowledge base is not keeping up – not that the first line has got worse.
Also track the share of reopened tickets. A high number means tickets are being closed too early, which looks good in the statistics and bad for users.
Automate what repeats
Assignment, prioritization and escalation should be handled by rules. Alerts from monitoring should become tickets automatically, with the right client and contract from the start.
More on how the workflows are built under automation, and how the process fits with everything else under ITSM.
