Six IT service desk metrics a small team can use

Six measures that are enough

First response

How long someone waits until a person replies. Measured in business hours, not counting automatic acknowledgements.

Resolution time

How long from arrival to resolution, leaving out pauses while you wait for others.

Deadlines met

How many out of 100 tickets were resolved within their deadline.

Open-ticket age

How many tickets are older than a week, or older than a month.

Common topics

Which categories account for the most tickets.

Satisfaction

Thumbs up or thumbs down after resolution.

How to calculate them

Take five tickets with resolution times of 1, 2, 2, 3 and 40 hours. The average is 9.6 hours and the median is 2 hours. The median describes the typical case, and you look at the 40-hour ticket separately.

If 199 of 212 resolved tickets met their deadline, that is about 94 out of 100, which is easier for management to read than a percentage with a decimal point. At the end of the month, count open tickets by age: under a week, one to four weeks, older. If the oldest group keeps growing, something is being left that nobody wants to touch.

Always state whether times are in calendar hours or business hours, and whether pauses are included. Otherwise you cannot compare months reliably.

Traps to avoid

Many tickets do not always mean a lot of work: five password resets take less effort than one server migration. A quick resolution is not always a good one. Closing tickets without fixing the problem improves the figure and worsens the service, so watch reopened tickets and thumbs down. Comparing people is misleading, because whoever takes the difficult tickets has fewer and slower ones: workload per person shows overload, not performance. And every metric should support a decision, such as a second position, a maintenance contract, a guide or training.

IT in [month]:
[count] tickets, [x] out of 100 deadlines met.
First response after [time] on average, resolved after [time].
Method: [median/average], [business/calendar hours].
Biggest topics: [topic 1] [count], [topic 2] [count].
Satisfaction: [number] thumbs up, [number] thumbs down.
What we will change: [one sentence].

The last line matters most, because it shows that the figures lead somewhere. Printers account for a quarter of all tickets? A maintenance contract or a different printer is worth considering. Ticket volume has been rising for a year, and resolution time with it? That is a case for a second IT position. The same question comes up twenty times a month? Time for a guide.

Start with an honest baseline

Before you set targets, measure for three months without changing anything, and count the requests that arrive in the corridor as well. That is your baseline. Many IT teams are surprised by how many tickets there really are, and by how fast they already are. Both are good news: one explains why the day is so full, the other shows what already works.

Then set at most two goals at a time, and check once a month whether you are getting closer. A goal should be achievable and point in a direction. "First response within an hour on average" is a good goal if you are at two hours today. "100 out of 100 deadlines met" is not, because it is only reachable with overly generous deadlines.

What the figures do not show

Some work never appears in ticket totals: projects that run alongside tickets, such as an office move, a new phone system or a server replacement; preventive work such as updates, backup checks and tidying up access rights, which means fewer tickets when done well; and advice, such as talking to purchasing about new software before it is ordered. Mention this work in one sentence in the monthly report, otherwise an IT team with few tickets looks like an IT team with little to do. Creating recurring tasks as tickets makes part of it visible.

Starting without a tool

You do not need a system to start. A tally sheet kept for one week answers the first question: how many requests arrive, through which channel and about what? For each request, note the time of arrival, first reply and resolution, with the time zone. After a week you have a first baseline, which is better than any gut feeling.

Spend ten minutes a month as a team on what stands out and what you want to change. Look at topics, not people. If a topic is rising, look for the cause together: new software, an old printer, a missing guide. Record one action and check next month whether it worked. That turns figures into tools instead of instruments of control. Good figures deserve a mention too: if first response has been getting faster for three months, the team should see it.

Industry benchmarks for resolution times or tickets per employee deserve caution, because every company counts differently. Compare yourself with yourself three, six and twelve months ago. That is more honest and shows whether your changes work.

What 404desk currently reports

Pulling the figures by hand from a mailbox means doing it twice and then never again. A ticketing system calculates them as you go. In 404desk, these metrics appear in Analytics, with CSV export. First response and resolution time are currently shown as averages in calendar time, so they include nights, weekends and waiting periods. Analytics does not yet show a median. The age of open tickets is shown for the current backlog in five groups, from up to 14 days to older. The SLA deadlines themselves are calculated from your business hours.

Every month, an IT service report goes out as a PDF to the recipients you choose, such as management. See Analytics and the IT service report. If you want reports per person in Germany, also read ticketing and the works council.