The Service Desk That Faces the Wrong Way
This is not a sign that ITIL has been done badly. It is what happens when it is done well.
When the Dashboard Is Green and the Business Is Not
The monthly service review runs to a familiar rhythm. The service desk manager walks the room through the pack: incidents logged, incidents resolved, first-time fix up two points, ninety-six per cent of priority calls closed inside the agreed service level. Every indicator on the slide is green. And across the table the operations director for the business — the person whose branches, tills, or back-office teams actually depend on the systems — sits with an expression that has nothing to do with the colour of the slide. She has spent the month fielding complaints her own numbers cannot explain, and she has stopped arguing with the pack, because the pack is unarguable. The report is true. It is also, in the way that matters most, beside the point.
Anyone who has sat on either side of that table knows the feeling, and the discipline we have built to prevent it seems only to sharpen it. We have spent the better part of a decade professionalising IT support — the single point of contact, the incident and problem distinction, the service level agreement, the configuration database that is finally, in some places, more than a spreadsheet. The books are good books. The certifications are earned honestly. And yet the more faithfully an organisation implements them, the more common that silent table becomes: a service desk hitting every target it has agreed, attached to a business that feels no better served. My argument is uncomfortable and, I think, unavoidable. This is not a sign that ITIL has been done badly. It is what happens when it is done well.
The Ticket Becomes the Atom
Follow the logic the books ask you to follow and see where it lands. To manage a service, you must agree a level of service. To agree a level, you must express it as something you can measure and be held to. The thing you can measure, at the front door, is the call and its clock: how quickly it was answered, how quickly resolved, whether it breached. So the ticket becomes the atom of the whole system — the unit in which work is counted, staff are judged, and the relationship with the business is finally settled.
The trouble is that the ticket is a very thin container. It records a category, a priority derived from an impact-and-urgency matrix, a resolution time, an open and a close. It cannot record that the ten-minute outage it dutifully logged landed during the one hour of the quarter when it truly mattered, or that the minor fault it closed inside target is the third time this month the same team has lost the same afternoon. The business need is context — timing, consequence, the weight of this failure over that one — and context is exactly what the ticket strips out on the way in.
A metric is a servant that becomes a master the moment it is the only thing the organisation is willing to reward. The service desk did not choose to serve the clock; we built a system in which the clock was the only thing that could be seen.
So the desk optimises what the ticket can hold, because that is what it is measured on and paid for, and the business need — being unmeasured — is not fought over and lost. It is simply never entered into the ledger. This is the mechanism, and it is worth stating plainly because most improvement efforts aim at the wrong target: the disconnect is not caused by a lazy desk or an immature process. It is caused by a faithful desk optimising an honest metric that was never capable of carrying the thing that mattered.
| What the pack reports green | What it cannot answer |
|---|---|
| 96% of priority incidents closed within SLA | Did the 4% that breached include the one that stopped the month-end run? |
| First-time fix rate rising | Is the same fault being first-time fixed eleven times because no one owns the cause? |
| Average resolution time down | Are we closing calls faster by closing them narrower? |
| Customer satisfaction on closed tickets high | What do the people who stopped logging tickets think? |
The Buffer That Was Sold as a Bridge
There is a second truth here that the service support volumes do not print, because it is organisational rather than procedural. The single point of contact was sold to us as a bridge — one door through which the business could reach IT, and through which IT could finally understand the business. In practice, in a great many organisations, it became something closer to the opposite: a buffer that protects IT from the business.
Watch how it works. The desk absorbs the frustrated call, logs it, resolves or routes it, and closes it inside target. The second and third lines — the engineers and specialists who could actually learn something from the pattern of pain — are shielded by design from ever hearing the raw complaint. The desk has done its job perfectly. It has also ensured that the organisation’s accumulated frustration is converted, every day, into closed tickets rather than into understanding. The reassurance flows one way. The learning never arrives.
This is why the distinction between an incident and a problem, which the books rightly treat as central, is where the whole edifice quietly fails. The incident is the instance; the problem is the cause; the discipline exists precisely so that context can travel from the noisy front line to the people who can remove the fault for good. But problem management is the perennially under-resourced function that every organisation agrees is vital and almost none actually staffs. Consider the shape of it: a recurring fault that surfaces eleven times across a quarter, each instance logged separately, each resolved inside its service level, each closed clean and green — and not one of them ever crossing into problem management, because problem management is a person and a half with a backlog measured in months. Eleven satisfied service levels. One business problem that no one owns. The system is not broken; it is behaving exactly as designed, and the design has no room for the cause.
“Incident closed is not the same as problem solved, and the distance between the two is exactly the distance between IT and the business.”
The offshoring wave now running through support functions makes this sharper still, not because distance is the enemy — good service has been delivered from a long way away — but because the further the desk sits from the business it serves, the more completely the ticket becomes the only thing that crosses between them. When the only shared language is the fields in the tool, the fields in the tool become the whole of the relationship.
“That Is ITIL Done Badly, Not ITIL”
The strongest objection to all of this is not a weak one, and it deserves to be met at full strength. It runs like this: what I have described is ITIL done badly. Done properly, service levels are written to business outcomes rather than technical thresholds; operational level agreements and underpinning contracts are aligned all the way down; problem management is funded as a first-class function; satisfaction is measured continuously rather than inferred from a survey stapled to a closed ticket. Do all that, the objection says, and the gap closes. The framework already contains the answer; the failure is in the using.
In theory this is correct, and I have seen organisations move a long way in this direction and genuinely narrow the gap. But there are two reasons it does not rescue the position, and the second is the one that matters.
The first is practical. The advice to write service levels against business outcomes founders on the same rock that created the problem: outcomes resist measurement at the desk, and where they can be measured they usually depend on things IT does not control. An agreement that IT will keep the order pipeline flowing is not really an agreement IT alone can sign, and everyone in the room knows it, so the level quietly reverts to something technical and ownable — availability, response, resolution — and we are back where we started.
The second reason is deeper, and it is the heart of the matter. Even a perfectly aligned service level is still a contract, and a contract changes a relationship. The moment the business need is written as a clause with a penalty attached, both sides begin to manage to the clause rather than to the need. IT defends the boundary of what it agreed; the business learns to phrase its suffering in the vocabulary of breach. So the standard prescription — do ITIL more thoroughly — very often means contractualise harder, and contractualisation is the disease, not the cure. You cannot resolve a problem of over-formalised relationship by adding formality. More process here deepens the very thing that opened the gap.
Turning the Desk Back Around
If the diagnosis is right, the response cannot be another maturity level reached by adding controls. It is a change in what an IT function is willing to be judged against, and it shows up in a handful of concrete choices.
- Measure the desk on problems removed, not only on incidents closed. Make the elimination of recurring causes the visible purpose of the system rather than its unfunded afterthought, and staff problem management as though you believe it matters.
- Keep one channel deliberately un-ticketed. A standing conversation between IT and the business that is not a queue, cannot breach, and exists precisely to carry the context the ticket cannot hold. If every exchange becomes a call reference, the buffer has won.
- Treat the service level as a floor, not as the definition of the relationship. The number is the minimum you will not fall below, not the sum of what you owe. An organisation that mistakes its SLA for its purpose has confused the guardrail with the road.
- Read the reopen and the recurrence before the first-time fix. The uncomfortable numbers — the calls that came back, the faults that returned — carry more truth about the business’s experience than the flattering ones, and they are usually a scroll further down in the same report.
None of this is exotic, and none of it requires abandoning the discipline that got us here. The incident and problem distinction, the single point of contact, the configuration data — these are real advances and I would not give them up. The point is narrower and, I hope, sharper: the framework gives us a superb apparatus for managing the measurable, and then leaves us to remember, entirely on our own, that the business need was never fully measurable in the first place.
The service desk was meant to be the face that IT turned towards the business. Built to the letter of the books, and measured the way the books make easy, it slowly became the face IT turned towards its own metrics — a mirror rather than a window. Turning it back around is not something an organisation matures into by adding another process. It is a decision about what it is prepared to be uncomfortable about. Until we are willing to be judged by the operations director’s unhappiness rather than by the greenness of the pack, the desk will go on facing the wrong way, and go on reporting, with complete accuracy, that everything is fine.