I have spent a good part of my career staring at dashboards that were almost entirely green while the people using the service were almost entirely unhappy. For a long time I assumed that was a reporting problem. Wrong widget, wrong threshold, wrong colour. It took me longer than I would like to admit to work out that the colours were fine. The problem was the thing being measured.
We have built an entire profession on the back of the key performance indicator. We set them, we report them, we hang bonuses off them, and we defend them in steering meetings with a straight face. And yet most of the KPIs I have ever seen share the same quiet flaw. They measure what is easy to count, not what the person on the other end of the service actually cares about. They tell you the queue is short. They do not tell you whether anyone got what they came for.
This is not a rant against measurement. I am firmly in favour of measuring things. It is a rant against measuring the wrong things and then trusting the answer to be a valid proxy for the true reality of the service.
The comfort of a lagging number
Almost every classic service KPI is a lagging indicator. It looks backwards. It tells you what already happened, usually after it is too late to do anything useful about it. Average resolution time last month. Tickets closed within SLA last quarter. Calls answered inside thirty seconds last week.
There is nothing wrong with looking back. History is useful. The trouble starts when the backward-looking number becomes the only number, and when we start managing the number instead of the service it was meant to describe.
A lagging metric has a particular kind of comfort to it. By the time you are reporting it, the period is closed. The story is told. You are not standing in front of a live problem, you are presenting a tidy summary of a problem that has already resolved itself one way or another. That comfort is exactly why these numbers survive. They let everyone agree on what happened without anyone having to feel what is happening right now.
Meanwhile the person who logged a request this morning does not care about last quarter. They care about the thing in front of them, today, and whether it is moving.
Counting the easy stuff
Here is a short list of things we are very good at measuring: queue length, time to first response, tickets per agent, percentage of incidents closed within target, abandonment rate, reopen rate. All real. All countable. All sitting proudly on the standard dashboard.
Now here is a short list of things we are not good at measuring, and which I would argue matter far more: did the person understand what was going on, did they trust that it was being handled, did they feel respected while they waited, and would they happily come back to us rather than route around us next time.
Notice the difference. The first list is made of events a system can timestamp. The second list is made of human judgements. We have leaned hard into the first list precisely because it is cheap to collect and clean to display. The second list is messy, it needs people to ask other people honest questions, and the answers do not reduce neatly to a single colour. So we quietly leave it off the report and tell ourselves the proxy will do.
The proxy almost never does.
A request can meet every timing target on the board and still leave the person worse off than when they started. It was answered quickly, routed correctly, updated on schedule, closed inside SLA, and the underlying thing they needed is still not sorted. The dashboard records a clean win. The human records a loss. When that gap becomes a habit, the dashboard stops describing reality and starts actively hiding it.
What people actually want
If you sit with the people who consume a service and listen, the same handful of wants come up again and again. None of them are exotic. None of them appear on a standard SLA report.
People want a response time they can understand and plan around. Not a percentile buried in a contract. A simple, honest sense of how long this usually takes, told to them in plain language, so they can get on with their day.
People want to know where their thing is in the process. Not a status code. Visibility. The same instinct that makes parcel tracking so satisfying. I do not need my package to arrive faster, I just need to stop wondering about it. Most internal services give people far less visibility than the courier who drops a box at their door, and then we act surprised when they chase us.
People want a real commitment to deliver, and then they want that commitment kept. A date that holds is worth more than a fast date that slips. Reliability beats speed almost every time, because reliability is what lets a person stop thinking about us and trust that it is handled.
And underneath all of that, people want to be left with a good feeling. This is the one we are most tempted to wave away as soft and unmeasurable, and it is probably the most important of the lot. The feeling someone is left with is what they remember, what they tell their colleagues, and what decides whether they deal with us next time or quietly find a way around us. You can hit every number on the board and still leave people feeling ignored, talked down to, or kept in the dark. When that happens, the numbers are lying to you, gently and in green.
SLAs, XLAs, and the same old furniture
Every few years our industry rediscovers that the old metrics are not landing, and reaches for a new acronym. For a long time the answer was the SLA. Wrap the KPIs into an agreement, attach some consequences, and call it a commitment. More recently the fashion is the XLA, the experience level agreement, which at least has the decency to put experience in the name.
I am genuinely glad the conversation has moved towards experience. The framing is healthier. But I want to be honest about what I keep seeing in practice. A lot of XLA programmes turn out to be the same furniture rearranged. The same timing metrics, the same dashboard, with a satisfaction score bolted on the side and the word experience painted over the door. The underlying habit has not changed. We are still measuring what is easy and convenient for us, and we are still treating the human judgement as a nice-to-have rather than the point.
Whether you call it a KPI, an SLA, or an XLA, the test is the same. Does the measure reflect what the person on the receiving end believes to be valuable, in their terms, or does it reflect what is comfortable for us to collect and pleasant for a manager to present? If it is the latter, a new acronym will not save it. You have just bought a nicer frame for the wrong picture.
So why do we keep doing it?
This is the part I find most interesting, because the answer is not really about metrics at all. It is about people, and about fear.
Start with the obvious. Easy-to-measure things get measured because they are easy to measure. There is a real cost to collecting the human stuff, and a real risk that the answer will be uncomfortable, so the path of least resistance is to count what the tooling hands us for free and move on.
Then there is the dashboard itself. Senior people want a single screen they can glance at and feel reassured. That is a completely reasonable thing to want, and it quietly shapes everything below it. A number that can be made green is a number that gets prioritised. A truth that cannot be reduced to a tile tends to fall off the report. Over time the service starts optimising for the dashboard rather than the person, because the dashboard is what gets looked at and asked about.
But the deepest reason, the one we rarely say out loud, is that genuine transparency feels dangerous to the team providing the service.
We hide the things we could improve
Here is the uncomfortable bit. Most teams do not actually want to tell users what is really going on. I have felt this pull myself, so I am not pointing at anyone from the cheap seats.
If you show people exactly where their request is stuck, you also show them that it is stuck. If you are honest about how long something usually takes, you have just handed over a stick they could use to beat you with later. Open up the process and you invite questions, second-guessing, and people sticking their noses into work they were previously content to leave alone. Every instinct says to keep the curtain closed. Report the tidy summary. Show the green. Keep the mess backstage.
So we hide the things we quietly know could be better. Not out of malice, mostly out of self-protection. A green metric is a shield. It lets us say we are performing without ever exposing the parts we are not proud of. And for a while it works, right up until the gap between the green and the lived reality gets wide enough that people stop believing the colour at all.
That loss of trust is the real cost. Once people decide the dashboard does not match their experience, they stop trusting all of it, including the bits that were honest. You do not just lose the argument about one metric. You lose your credibility as a service.
Failure with a human face
There is a pattern I have seen often enough that I now treat it as close to a rule. People are remarkably forgiving of failure when it is given a human face, and remarkably unforgiving of failure when it is hidden behind a number.
Tell someone honestly that their request is delayed, explain plainly why, give them a realistic new date, and treat them like an adult who can handle the truth, and most people respond with patience. They have been let down by services their whole lives. What they are watching for is whether you respect them enough to be straight with them.
Bury that same delay behind a status that still says on track, let them discover the slip for themselves, and the reaction is completely different. Now it is not just a delay, it is a delay plus the sense that they were managed, handled, kept quiet. People do not rail against failure nearly as hard as they rail against being deceived about it. The green metric, the one we reached for to protect ourselves, is the very thing that turns an understandable miss into a breach of trust.
This is why transparency is not the risk we fear it is. Honesty about a problem, offered early and in plain language, almost always costs less than the problem itself. The instinct to hide is the expensive one.
A worked example, the kind you have lived
Let me make this concrete, because it is easy to nod along with the principle and still miss it in practice. Picture a person who needs a piece of access to do their job. A licence, a permission, a system account, it does not matter which. They raise the request first thing on a Monday.
Here is the version that scores well. The request is acknowledged within minutes by an automated reply. It is routed to the right queue inside the target window. It is picked up by an analyst the same day, which counts as a fast first touch. It sits waiting on an approval for three days, but approvals are excluded from the resolution clock, so the clock effectively stops. The access is finally granted on Thursday afternoon. Closed inside SLA. Every timing metric on the board is green. By the standard report this is a textbook success.
Now here is what the person experienced. They could not do a chunk of their job from Monday to Thursday. For most of that time they had no idea why, because the only updates they received were system messages that told them the ticket existed and then told them it was resolved, with three silent days in between. They asked their manager. Their manager asked someone. Nobody could easily say where it was stuck or when it would clear. By Wednesday they had found a clumsy workaround using a colleague’s access, which is its own small security problem that nobody will ever measure. When the access finally arrived, there was no explanation and no acknowledgement that the wait had cost them anything.
Same event. Two completely different stories. The dashboard tells the first one. The person remembers the second. And the gap between those two stories is exactly the space where trust quietly leaks away. Notice too that the metric design actively made it worse. Pausing the clock during the approval was a sensible accounting choice, but it also meant the three days that hurt the most were the three days the report cared about least. We had optimised the number to exclude the pain.
The fix here is almost embarrassingly cheap. A plain-language note on Monday saying this usually takes three to four working days and is waiting on an approval from a named team. A nudge on that approval. A short message when it clears. None of that makes the access arrive any faster. All of it would have changed the experience completely, and none of it shows up on the board we currently look at.
Leading signals hiding in plain sight
If the core complaint is that our metrics look backwards, the obvious follow-up is whether we can look forwards instead. We can, more than we tend to admit. The signals are usually already in the building, we just do not treat them as metrics because they are awkward.
Reopened requests are a leading signal dressed as a lagging one. A reopen is the system telling you that a closure was not real, that someone marked something done to stop the clock rather than because the person was actually sorted. A low reopen rate is reassuring. A pattern of reopens around a particular team or process is an early warning that closures are being gamed, and it is worth far more than the closure number it sits next to.
The questions people ask are a signal too. Every time someone has to chase us for a status, that chase is data. It is telling you that your visibility is not good enough, that people are anxious enough about their request to spend their own time prodding it. A team drowning in where is my ticket messages does not have a communication problem to be managed away with a canned response. It has a transparency problem that the chasing is politely pointing at.
Even the language people use is a signal. The difference between thanks, that is sorted and fine, whatever, I will manage is enormous, and it never appears on a dashboard. Frontline staff hear it all day. They usually know exactly which parts of the service are quietly failing people, long before any report catches up. One of the cheapest improvements most teams could make is simply to ask the people on the phones what they keep apologising for, and then to believe them.
None of these signals are tidy. You cannot reduce them to a single percentage without losing the very thing that made them useful. That is precisely why they get ignored, and precisely why paying attention to them is such an advantage.
Measuring what matters instead
None of this means throwing the dashboard in the bin. It means demoting it. The timing metrics are fine as health checks for the machine. They are a thermometer. They were never meant to be the diagnosis, and they certainly were not meant to be the goal.
If I were starting a measurement conversation from scratch today, I would change the order of the questions. I would begin with the person and work backwards to the system, rather than starting with what the system can emit and hoping it adds up to a happy person.
A few principles I keep coming back to.
Measure perceived value, not just activity. Ask people, in their own words, whether the thing they needed actually got sorted and whether the experience respected their time. A short, honest question asked often beats an elaborate survey nobody reads.
Treat visibility as a feature, not a leak. Default to telling people where their request is and what happens next. The discomfort of being seen is almost always smaller than the damage of leaving people in the dark.
Pair every efficiency number with a human one. If you report time to resolve, report alongside it whether the person felt the resolution was real. A number on its own invites gaming. A number next to its human counterpart keeps everyone honest.
Reward kept commitments over fast ones. Celebrate the team that gave a realistic date and held it, not just the team that posted the quickest average. Reliability is what earns trust, and trust is what lets people stop watching us.
And above all, be willing to show the amber and the red. A report that is allowed to be honest is a report people can actually believe. A report that is only ever green is a report nobody trusts, including the parts that were true.
The point of the whole exercise
I keep reminding myself why we measure anything at all. It is not to fill a slide. It is not to defend a contract. It is to know whether the service we provide is genuinely good for the people who depend on it, and to find the honest places we could make it better.
The classic KPI, and a fair few of its newer cousins, quietly drifted away from that purpose. They started describing the machine instead of the experience, and they let us feel successful while the people we serve felt let down. A green dashboard became a way of not looking too closely.
We can do better than that, and it does not take a new framework or another acronym. It takes the nerve to measure what people actually feel, the honesty to show the parts that are not finished, and enough respect for the people we serve to tell them the truth. Do that, and the strange thing is that the old numbers tend to improve anyway, because you are finally working on the real problem instead of the picture of it.
A service that is brave enough to be transparent will always beat a service that is merely green. I would rather be trusted than look perfect. In the long run those turn out to be the same choice.