A healthy service desk is silent. When you start hearing about it, it's rarely a good sign.
Before launching a formal ITSM audit, seven concrete signals let you quickly diagnose whether your service desk is struggling. None of them is very technical. All are observable without diving into the details of your tool.
Users bypass the ticketing system
If your colleagues prefer to directly call an IT team member rather than open a ticket, it means the formal system isn't serving them. Either the tool is too heavy, or the experience of open tickets is bad (late responses, opaque tracking, escalations that go nowhere).
Direct consequence: your overall view of the real volume of requests is distorted. You make sizing decisions on a visible subset, while most of the work happens outside the circuit.
Indicators are green, but the climate is tense
This is probably the most misleading signal. Your SLAs are met, your average resolution time is on track, and yet business directors regularly express dissatisfaction.
This is generally the symptom of indicator-driven steering disconnected from the actual service reality. You've optimised for the numbers, not for the experience. Tickets are closed quickly, but often without real resolution. Deadlines are met on formal commitments, but the real pain points aren't measured.
The same tickets keep coming back
If the same category of incident comes back every week, it means nobody is dealing with the root cause. The service desk is running in permanent firefighter mode, with no capacity to investigate recurring problems.
This is typically the sign that a real problem management practice is missing. Without it, your support team exhausts itself resolving the same incident ten times, instead of eliminating it once and for all.
The service desk has become a permanent escalation hub
Levels 1 and 2 escalate to level 3 on 30% or more of tickets. Level 1 spends its time qualifying without resolving. The added value of the front line has disappeared.
The possible causes are multiple: under-trained team, missing or outdated knowledge base, poorly scoped level 1 perimeter. But the consequence is always the same: bad allocation of skills, rising costs, lengthening delays.
A healthy service desk is silent. When you start hearing about it, it's rarely a good sign.
Your service catalogue doesn't exist or isn't up to date
If your users don't precisely know what they can ask of IT and under which conditions, two things happen: they don't ask (and figure things out outside the circuit) or they ask anything (and the service desk spends its time re-qualifying).
A current service catalogue is a foundation. Without it, everything else is suboptimal.
Change deployments regularly break production
Almost all deployments generate post-change incidents. Change management is either absent or purely formal (an approval workflow, with no real impact assessment).
This signal is particularly costly. Post-change incidents destroy business trust in IT's ability to deliver. And they consume massive bandwidth on the service desk downstream.
No regular reporting to leadership
If your IT department doesn't have a monthly dashboard readable by a non-IT executive, it means the IT service is invisible to the rest of the organisation. And what's invisible isn't recognised, so it isn't properly funded, so it degrades progressively.
Regular reporting isn't a communication exercise. It's a governance tool. Without it, budget arbitrations happen blind, and always to IT's detriment.
A few isolated signals aren't catastrophic. Three or more at once justify a formal diagnosis.
What to do if you recognise your situation
A well-run ITSM audit takes between four and eight weeks, crosses interviews, data analysis and benchmarking, and produces a prioritised ranking of pain points. From there, the action plan becomes readable.
The worst is to do nothing, telling yourself the situation will stabilise on its own. A drifting service desk never recovers spontaneously. It recovers because someone decides to look objectively at what isn't working, and commits the resources required.