The Perception Gap

This is not a survey and it is not a benchmark study. It is a practitioner report. Since 2014 we have run independent, consultant-led ITSM assessments across UK enterprise IT organisations. What follows is what we consistently see. Where we describe a pattern as common, that is our professional judgement from twelve years of doing this work, not a statistic. Individual organisations vary significantly, and no client is identified. We are independent of every tool vendor and every framework body.

1. The question we ask first

There is a question we ask at the start of almost every assessment.

We ask IT leadership to estimate how mature they believe their service management is. Then we ask the same question of the people doing the work.

The gap between those two answers is, without exception, one of the most revealing things we see.

Leadership consistently rates it higher. Not because they are wrong about what exists. The processes exist, the tools are in place, the policies are written. They are right about all of that. They are simply insulated from how those things function on a Tuesday afternoon when someone is off sick and a change has gone wrong.

They see the framework. Practitioners live the reality.

This is not a failure of leadership. It is the natural consequence of distance from operations, and it is structural rather than personal. But it has consequences, and those consequences have become considerably more expensive in the last two years.

2. Five patterns we see everywhere

Pattern one: Problem management in name only

Almost every organisation we assess has a problem management process. Very few have problem management.

Problem records are raised after major incidents. Investigations begin. Then they stall. Root causes are never formally confirmed, workarounds are logged but never communicated to the service desk, and the same incidents recur three months later. The problem record eventually closes, not because the problem was solved, but because it got old enough that nobody remembered to chase it.

Leadership sees a problem management practice with an owner and a process document. The service desk sees the same incidents coming back.

The tell: ask to see the last five problem records that were closed with a confirmed root cause and a change that resulted from it. The answer tells you everything.

Pattern two: Knowledge that lives in people's heads

Critical knowledge about systems, workarounds and edge cases exists in the minds of specific individuals. Everybody knows who those individuals are. Frequently there are only two or three of them.

When those people are on holiday, resolution times spike. When they leave, capability leaves with them. The knowledge base exists, was populated during a tool implementation, and has not been meaningfully reviewed since.

This is the single most reliable predictor of fragility we encounter, and it is almost never visible in reporting, because it does not show up in any standard metric until the person is gone.

The tell: what happens to your service quality during the summer holidays? If you know the answer without looking it up, that is your answer.

Pattern three: Inconsistent incident categorisation

The same type of incident is categorised differently depending on who logged it, which team handled it, or what time of day it arrived.

This looks like a housekeeping issue. It is not. It undermines every piece of trend data you produce, makes SLA reporting arguable, and renders problem management analysis close to worthless because you cannot reliably identify patterns in data that was inconsistently classified in the first place.

It has also become the single most consequential data quality issue in enterprise IT, for reasons we come to in section four.

The tell: pull a hundred recent incidents and look at how they were categorised. You will either find consistency or you will find catch-all categories absorbing everything ambiguous, and re-categorisation happening at volume after the fact.

Pattern four: Change management bypassed for speed

A formal change process exists and is presented as mature. Governance is in place. There is a CAB.

In practice, a significant proportion of changes bypass it entirely, particularly in development and infrastructure teams. Change-related incidents are then attributed to other causes, because attributing them accurately would require admitting the change was never registered.

The organisations where this is worst are rarely the ones with weak processes. They are the ones with processes so heavyweight that following them is genuinely slower than working around them. The people who comply are perceived as slower than the people who do not, so the bypassing continues and spreads.

Every unregistered change is a process failure. But when teams bypass a process at scale, the problem is usually the process, not the teams.

The tell: compare your change volume to your deployment volume. If they do not roughly reconcile, you have your answer.

Pattern five: Metrics that measure activity, not value

Dashboards show ticket volumes, response times and SLA compliance. They are produced monthly, reviewed in a governance forum, and filed.

Ask what any of it means for the business and the room goes quiet.

This matters more than it appears to, because it determines whether IT can defend its budget in language the business understands. An IT function that can only describe its performance in ticket volumes is an IT function that will be assessed on cost, because cost is the only dimension the business can evaluate.

The tell: could your CFO explain, from your reporting, whether IT service quality improved or declined last quarter, and what that was worth?

3. Why these patterns persist

Discipline scores tell you what is broken. They do not tell you why it stays broken. Four cross-cutting themes appear in almost every organisation we assess, and addressing them is what separates an improvement programme that works from one that produces a report nobody implements.

Ownership without accountability. Somebody is named as the owner of Incident Management. That person has no dedicated time, no authority to enforce standards, and no quality targets. Having an owner and having effective ownership are not the same thing, and the gap between them is where most improvement programmes quietly fail.

Silos that predate the process. IT operates in functional towers. Incident, change and problem management are owned by different teams who rarely collaborate. Each team's process is locally sensible and collectively incoherent.

Culture that treats process as bureaucracy. Workarounds are celebrated as pragmatism. This is rational behaviour: practitioners who have watched three improvement initiatives come and go without lasting change have earned their scepticism. Resistance to ITSM improvement is almost never irrational, and treating it as something to be managed rather than understood is the fastest way to guarantee it continues.

The report that gathered dust. A previous assessment produced a detailed roadmap. It was presented, approved, filed and never implemented. Two years later the same gaps reappear. This is the single most common reason organisations hesitate before commissioning another one, and it is a reasonable hesitation.

4. Why the gap has become expensive

The perception gap has always existed. What has changed is the cost of getting it wrong.

Organisations are making significant investments in AI-enabled service management: intelligent automation, virtual agents and self-service. Almost every one of those investments quietly assumes foundations that are more capable than most organisations realise they need to be.

AI amplifies what is already there. It does not repair it.

• Inconsistent incident categorisation produces unreliable AI triage. The model learns patterns from data that was classified inconsistently, so its recommendations are frequently wrong, agents override it, and within weeks it becomes something people work around rather than with.
• An unmaintained knowledge base produces confident, incorrect answers at scale. An AI that surfaces a workaround that no longer works does not merely fail to help. It actively damages user confidence in the service desk.
• An out-of-date service catalogue means AI self-service fails at first contact. Users who encounter an assistant that cannot help with their actual request do not try again. They pick up the phone.
• Absent problem management means predictive analytics has nothing coherent to detect. Recurring incidents that were never investigated look identical to emerging new problems.

Automating a poor process delivers a poor outcome faster. That warning is not new. What is new is the size of the budgets now being committed on the assumption that it does not apply.

The organisations getting genuine value from AI in service management share one characteristic: they fixed their foundations first, then deployed into an environment where the inputs were reliable. That sequence takes longer to show results. The results, when they come, are real.

5. Why we built a platform to close it

The perception gap is not a new observation. Every experienced consultant has seen it. What is new is what we decided to do about it.

Standard assessment methodology asks one set of questions and gives one group the microphone, usually leadership, because leadership commissions the assessment and leadership is easiest to access. The resulting report reflects what the organisation believes about itself. It rarely captures what the organisation actually does, because the people who could tell you that were never systematically asked.

We built the Clarity Assessment™ platform to close that gap by design, not by accident.

Every assessment we run uses stakeholder-specific question sets. Leadership answers a different set of questions from IT management, who answer a different set again from the practitioners doing the work. Every discipline is scored independently against evidence, not against opinion. And where leadership's view of a discipline diverges sharply from what practitioners report, the platform surfaces that divergence explicitly, as a finding in its own right, not as noise to be averaged away.

That divergence is frequently the most important line in the entire report. An organisation that believes it is Managed and operates as Initial has a different, harder problem than an organisation that is honestly Initial and knows it. The first organisation is not planning to fix anything, because nothing looks broken from where they sit. The second is already halfway to a solution, because they have stopped arguing about the diagnosis.

We are independent of every tool vendor and every framework body, and now, deliberately, we are independent of the frameworks themselves. Our question set was built from twelve years of running these assessments, not adapted from someone else's model, so it asks what we have learned actually matters rather than what a framework says should matter. Where ITIL, SIAM or ISO 20000 provide useful language, we use it. Where our own experience diverges from the textbook, we follow the experience.

The platform does not tell you what you want to hear. It tells you where your leadership team's view and your practitioners' reality stop agreeing, and by how much. In our experience, that single number, more than any individual discipline score, predicts whether an improvement programme will actually change anything.

6. What to do about it

Ask the two questions. Ask your leadership team to score your service management maturity. Ask your practitioners the same question. Do it independently and compare. You do not need a consultant to run this, and the gap itself is diagnostic before anyone scores anything formally.

Look at the tells, not the documentation. Every pattern above has a test that takes under an hour and cannot be answered from a process document. Run them.

Fix categorisation before you buy AI. It is unglamorous, it is the least interesting item on any roadmap, and it is the single highest-return preparation you can do. Consistent categorisation improves problem management, makes reporting defensible, and is a precondition for every AI capability worth having.

Be honest about the last roadmap. If a previous assessment produced recommendations that were never implemented, understand why before commissioning another. The reason is almost never that the recommendations were wrong.

Get an outside view, from someone with nothing to sell you. The perception gap exists because proximity makes objectivity difficult. That is not a character flaw, it is a structural feature of being close to the work, and the only reliable correction is an independent one.

A practitioner report based on consulting experience across UK enterprise IT. Not a survey and not a published benchmark study. Individual organisations vary significantly and no client is identified.