Some faults are genuinely one off. A cable gets knocked out, a supplier has a bad afternoon, a laptop is dropped. Those are not worth investigating.
The ones worth investigating are the faults that return. The printer that stops every few weeks. The application that hangs each Monday morning. The person whose email signature keeps reverting. Each one takes fifteen minutes to clear, which is exactly why nobody ever spends the two hours it would take to end it.
Cleared is not the same as fixed
When a fault is cleared, the symptom goes away and nothing about the system changes. A restart, a cache wiped, a profile rebuilt. The work is real and the user is unblocked, but the conditions that produced the fault are all still in place.
When a fault is fixed, something changed: a setting, a driver, a permission, a piece of hardware, a process. There is a record of what changed and why.
Both are legitimate. Clearing a fault at ten past nine on a Monday is the right call. The mistake is never coming back to it.
The three reasons a fault survives
In practice, a recurring fault usually has one of three causes behind it.
Nobody owns it. Each occurrence is handled by whoever is free. No single person has seen it four times, so nobody knows it is a pattern. This is the most common cause and the easiest to remove.
The real cause is somewhere nobody is looking. The printer is not the problem, the print queue on a server is. The application is not the problem, a scheduled job that locks a file at eight fifty five is. Investigation stops at the thing the user pointed at.
The fix is known and has not been approved. Somebody worked it out months ago, and it needs a replacement part, a licence, or an hour of downtime that nobody has agreed. So it stays cleared instead.
Start by counting
You cannot spot a pattern you are not recording. If support requests are handled by email or by tapping somebody on the shoulder, there is no list to count.
The minimum useful record is four fields: what broke, who reported it, what was done, and the date. That is enough to sort by symptom and see what repeats.
Once a month, sort by symptom. Anything appearing three or more times goes on a short list. That list, not the daily queue, is where the time savings are.
The questions that find the cause
For each item on the short list, work through these before touching anything.
- When does it happen? A fault with a time of day or a day of the week attached almost always has a scheduled cause behind it.
- Who does it happen to? If it is one team, look at what that team has that others do not. A shared mailbox, a plug in, an older device model.
- What changed shortly before it started? An update, a new starter, a moved cupboard, a different supplier. The start date is more useful than the symptom.
- What makes it go away? The workaround describes the cause. A fault cured by a restart is usually a process or a lock. One cured by clearing a cache is usually stale data.
- Does it happen anywhere else? If one machine of thirty does it, the machine is the difference. If all thirty do it, the shared thing is.
Most recurring faults give themselves up somewhere in that list. The ones that do not usually need a log from the moment it happens, which means asking somebody to report it while it is still broken rather than after they have restarted.
Put a price on it before you argue about it
A fifteen minute fault that hits four people every month is a few hours a year of interrupted work, plus the support time. Written like that, an hour of proper investigation is easy to approve. Described as a printer being annoying, it is not.
You do not need a precise figure. You need the occurrence count and the rough minutes, both of which come from the record you are already keeping.
Ask your provider for the recurrence number
If somebody supports your IT, the most useful number they can give you each month is not how many requests they closed. It is how many were repeats.
A falling repeat count means faults are being removed. A flat one means they are being cleared. Closed request volume on its own tells you neither, and can even go up while things improve, because people report more when reporting works.
A provider who tracks recurrence is a provider who expects to be judged on whether problems stay gone.
What we would do first
Pick the single most frequent fault, not the most annoying one. Give it to one named person. Ask for the cause in writing, even if the answer is that the fix needs money or downtime. Then decide.
Doing that once usually pays for itself, and it changes the conversation from clearing faults to removing them. More on how we handle this is on our IT support page, and there is related detail on managed IT. If a particular fault has outlived its welcome, describe it to us and we will say where we would look.