A judgement based on gut feeling
"Does our IT support work?" In many companies the answer depends on the latest episode. If the warehouse printer was out of action for two days last week, support is terrible; if the managing director had their laptop fixed in half an hour, it is excellent. Neither judgement says how things are going overall.
What you need is a few figures, well chosen and read together: they show where time is being lost and what keeps happening.
The metrics that matter
| Metric | What it measures | What it tells you |
|---|---|---|
| Response time | From when you open the request to when a technician actually starts working on it | Whether requests sit in the queue without anyone looking at them |
| Resolution time | From when you open the request to when the problem is solved | How long you are unable to work, which is what matters to you |
| First contact resolution | Requests closed at the first interaction, with no handovers or callbacks | How well the people answering know your environment |
| Reopened requests | Closed tickets that are reopened because the problem was not solved | Whether tickets are closed just for the sake of closing them |
| Backlog and its age | How many requests are open, and for how long | Whether the workload is sustainable, and what has been forgotten |
| Satisfaction | One or two questions to the user straight after closure | How the user experienced the work, not just whether it was finished |
| Anomalies caught early | Problems detected by monitoring before the user notices them | How far support prevents problems rather than chasing them |
The distinction between response and resolution is the most important one. The automatic "we have received your request" message does not count as a response: the response is the moment a person starts working on it. The backlog, too, should be looked at by age as well as by number: ten requests open since yesterday are business as usual, three open for a month are three colleagues who have stopped asking.
Incidents and problems: getting things running again is not enough
ITIL, one of the most widely used references for IT service management, distinguishes between two things that everyday language tends to mix up. An incident is an interruption or degradation of a service, and the goal is to restore it as quickly as possible. A problem is the cause, often still unknown, of one or more incidents, and the goal is to eliminate it so that the incident does not happen again.
If a sales rep's VPN drops every Monday while they are on the road, and every Monday a technician gets it going again, all the incidents are resolved and the metrics look good. The problem, however, is still there. Support that works well keeps an eye on recurring requests, and at some point stops restarting the VPN and goes looking for the cause. That is quicker if the environment is documented, as explained in the guide on IT that lives in one person's head.
The metrics that mislead
- The number of tickets closed. It rewards anyone who splits a request into three and closes it in a hurry.
- The average time. An average of a few hours can hide many requests solved in ten minutes and a few left open for a week. Also ask how many requests went over the expected time, and which ones.
- The SLA met on paper. Many ticketing systems let you pause the clock when a request is "awaiting user". That is fair if the technician really is waiting for a reply; it is not if the pause becomes a way of making the numbers add up.
How to read an SLA
The SLA (Service Level Agreement) is the agreement that sets service levels, and the first thing to look at when you outsource IT. Before signing it, check four things.
- Priorities defined by impact: the whole company without email or the ERP system is not the same as a printer down in an office that has two others. Each level should come with concrete examples, so it does not have to be argued over every time.
- Response and resolution kept separate: a short response time is useful, but on its own it does not tell you when you will be back at work.
- Coverage hours and pauses in writing: if the service covers weekdays during office hours, a fault on Friday evening is picked up on Monday, and the clock starts from there. The same applies to the cases in which the clock stops.
- Consequences of missed targets: penalties, a service review, or nothing. An SLA without consequences is a statement of intent.
What to ask your provider
More than a dashboard, you need a periodic report that can be read without a technician sitting next to you: how many requests there were, how their times compared with the SLA, how many were reopened, which are still open and for how long. Plus two lines that few providers include: the five most frequent causes in the period, and what is being done to eliminate them. That is where you see whether support just answers calls or actually reduces them.
- I know how much time passes between my request and the moment someone starts working on it;
- the SLA priorities are defined by the impact on work, with examples;
- I know which problems recur most often, and who is dealing with them;
- some anomalies are caught by monitoring before I notice them myself.
In short
To tell whether support works you need a few figures read together: response and resolution times, first contact resolution, reopened requests, backlog by age. The count of closed tickets and averages on their own are misleading. An SLA only means something if priorities follow the impact on work, and a good provider does not just close tickets: it reduces the ones that keep recurring.