Most monthly IT reports open with a number of tickets closed and a pie chart of categories. It looks like accountability. It rarely is, because ticket volume tells you how busy somebody was and nothing about whether your organisation is in better shape than last month.
A useful report answers a different question: what is getting better, what is getting worse, and what needs a decision. Five sections cover it.
One: volume, with a direction
Volume still belongs in the report. It just needs context. The useful form is this month against the last six, split by the part of the organisation the requests came from.
A rising count is not automatically bad. It often means people have started reporting things they used to tolerate, which is progress. A falling count is not automatically good either, because it can mean people have given up. Read it alongside the other sections rather than on its own.
What you are looking for is concentration. If one team raises three times as many requests as a team the same size, something is different about their equipment, their software or their working pattern, and that is worth an hour of somebody’s attention.
Two: recurrence
This is the number that matters most and the one most often missing. How many of this month’s requests were repeats of something already seen?
A report that tracks recurrence shows whether faults are being removed or only cleared. If it falls over a few months, prevention is working. If it stays flat while volume rises, you are paying for the same fixes repeatedly.
If your report does not contain this, it is the first thing to ask for. Any system that records requests can produce it, and a provider who resists is telling you something.
Three: how long things took, as a spread
An average resolution time hides the cases that hurt. Twenty requests closed in ten minutes and one that took nine days produce a comfortable average and an unhappy user.
Ask for the spread instead. The typical case, the slowest few, and what made the slowest ones slow. Often the answer is not the provider at all. It is a part waiting on approval, a supplier, or a user who could not be reached, and each of those has a different remedy.
The slow cases are also where agreed response times get tested. If there is a target in your contract, the report is where it should be shown against reality rather than asserted.
Four: what changed
This is the section that separates a report from a log. One line for each piece of work done to stop something happening again.
A firmware update rolled out. A permission structure tidied. A backup job that had been failing quietly, now fixed. A licence removed from somebody who left in March.
If this section is empty for two months running, all the time is going on reaction. That may be the right arrangement for a small organisation, but it should be a choice rather than a surprise.
Five: what is at risk
The forward looking section. Devices out of warranty or too old to run what is coming. Software approaching end of support. Anything unpatched and why. Certificates and licences expiring in the next quarter.
Support dates are worth a standing line here, because they arrive on a fixed calendar and the work they create is entirely predictable. Microsoft publishes its dates years in advance, so there is no reason for one to be a surprise.
The risk section is what turns a report into a planning document. It is also the section that justifies budget, because it converts a vague worry into a dated list.
What a good report is not
It is not thirty pages. It is not a raw export of every ticket. It is not a dashboard nobody opens between meetings.
Two or three pages, the same shape every month so trends are visible at a glance, with anything needing a decision marked as such. If it takes more than ten minutes to read, it will not be read.
How to ask for a better one
You do not need to renegotiate anything. Send the five headings and ask whether the current system can produce them. Most can. Then agree a date each month and treat the first one as a draft.
Give it three months before judging. A single report shows a moment. Three show a direction, which is the whole point.
Our reporting is described on the managed IT page, and the day to day side is on IT support. If you would like a second opinion on the report you get now, send us a recent one and we will tell you what we would add.