Are You Measuring the Service, or Just the Activity?

All of that information has value. You need it to understand workload, capacity and whether the operation is functioning as expected.

But I think there is a danger in assuming that because we are measuring a lot of things, we must have a good understanding of the service.

A dashboard can be full of green numbers while customers are still chasing, repeating themselves, being moved between teams or struggling to get a straightforward answer. From an operational point of view, the service might appear to be performing well. The customer can be having a completely different experience.

That is why I think we need to look beyond activity and ask what the numbers are actually telling us about the service.

SLA performance is a good example.

If a team consistently responds and resolves work within its agreed targets, that is useful information. It tells you that the operation is working within the standards the business has set.

The difficulty comes when the SLA becomes the main definition of good service.

A customer may technically have received a response within the agreed time while still feeling that nothing really happened. They might then have to chase for an update, speak to somebody else, repeat the issue or wait while work moves between departments.

The SLA was achieved, but the customer still had to work hard to get the outcome they needed.

I would not stop measuring SLA. I would want to understand what is happening around it.

Are customers having to contact us again after we respond? Are they receiving useful updates? Are cases genuinely being resolved, or are they simply moving through the workflow within the required times?

Those questions give the metric context.

Average handling time is another measure that can tell two very different stories.

If handling time falls because employees have better systems, clearer processes and easier access to information, then you may have created a genuine improvement. The employee can complete the work more efficiently and the customer gets an answer more quickly.

If handling time falls because people are rushing conversations, transferring work before it is fully understood or closing cases too soon, then the improvement is much less convincing.

The customer may simply come back.

That is why I would always want to look at efficiency alongside what happens afterwards. If handling time falls while repeat contact and complaints also fall, you have much stronger evidence that the service has improved. If handling time falls but repeat contact starts increasing, I would want to understand what has changed.

Efficiency matters, but it needs to lead to a better outcome rather than simply a faster interaction.

I think repeat contact is one of the most useful things a service team can look at because it immediately encourages you to think beyond the individual interaction.

If somebody contacts you once and gets what they need, that is very different from somebody who has to contact you three or four times about the same issue.

Internally, those contacts may not even look connected. The customer may start with self-service, complete a form, call the Service Desk and later speak to an Account Manager. Each interaction may sit in a different system or be owned by a different team.

The customer does not experience them as separate interactions. They experience one problem that still has not been resolved.

That is where repeat contact becomes useful. It helps you start asking why the customer needed to come back.

Perhaps the first answer was unclear. Perhaps the customer did not know what would happen next. Perhaps another team failed to complete an action. Perhaps the website did not contain the information they needed. Perhaps self-service appeared to resolve the query but did not actually give the customer enough confidence to stop contacting you.

Those are service-design questions, and they can easily be missed if you only look at the number of contacts handled.

Complaints can add another layer of understanding.

The number of complaints received is useful, but I would be far more interested in what customers are complaining about.

If several customers are raising concerns about poor communication, that tells you something. If they repeatedly mention delays between teams, unclear ownership or having to chase for updates, those themes should be looked at alongside the operational data.

Perhaps the SLA reports look healthy because every team is completing its own part of the process within target. The complaints might reveal that the customer is still getting lost between those teams.

That is why I think complaints should be treated as service insight rather than simply cases that need to be closed.

The same principle applies to service recovery. If the same type of complaint keeps appearing, the business should be asking whether anything has actually changed as a result of the previous ones.

The value comes from connecting the information.

Customer satisfaction is useful because it gives customers a simple way of telling you how they felt about an interaction. It can highlight teams or journeys that are performing particularly well and help identify where attention may be needed.

But I would be careful about treating the headline score as the whole story.

Response rates can vary significantly. The people who respond may not represent everybody. A customer may rate an individual employee very highly even though the wider process was difficult, or give a poor score because of a problem elsewhere in the journey that the employee could not control.

That does not make CSAT less useful. It means you need to look at what sits behind it.

The written comments are often where the real insight is. I would look for recurring themes and compare those themes with complaints, repeat contact and operational performance. If a particular journey consistently produces poorer feedback, there is probably something worth investigating.

Used that way, CSAT becomes a way of finding where to look rather than simply another number for the monthly report.

Customer effort is one measure I think businesses should pay much more attention to, particularly as more services become automated.

How hard did the customer have to work to get what they needed?

That effort can show up in lots of ways. A customer might have to repeat information, wait without knowing what is happening, move between teams or try several different routes before reaching somebody who can help.

They may still receive a resolution within SLA and still come away thinking the service was difficult.

This is why customer effort adds something that traditional operational measures can miss. It helps you understand how the journey felt rather than simply how quickly each internal stage was completed.

There is also a strong operational benefit to reducing effort. Customers who do not need to chase create fewer contacts. Clearer journeys reduce confusion. Better handoffs reduce rework. Better information reduces unnecessary calls.

Improving the customer experience can reduce the cost of delivering the service at the same time.

Not every important signal will appear neatly in a dashboard.

The people delivering the service every day often know where the problems are before the reporting does.

They know which process causes customers to call back. They know the knowledge article that keeps creating confusion. They know the system that has introduced another manual step. They know which handoff regularly results in somebody having to chase another team.

If the same thing keeps coming up in team meetings or conversations with frontline employees, I would pay attention to it.

You may not have enough data yet to quantify the problem, but that does not mean the problem is not there.

Frontline teams are often your earliest indicators of service friction. Their feedback can tell you where you need to investigate before a small issue becomes a much larger one.

The strongest service reporting combines that operational knowledge with the formal data.

I think one of the easiest ways to improve service measurement is to start with the outcome rather than the metric.

If the goal is to make it easier for customers to get help, then customer effort and repeat contact matter.

If the goal is to reduce avoidable demand, you need to understand what is driving that demand and whether it disappears after the improvement.

If the goal is to improve retention, complaints, service recovery and the health of the customer relationship become important alongside the traditional service measures.

If the goal is operational efficiency, handling time and automation still matter, but you also need to know whether the quality of the outcome has changed.

Starting with the outcome helps you choose measures that actually tell you whether the service is moving in the right direction.

It also makes reporting much more useful.

Instead of asking why a number is red or green, you start asking what the information means and what you should do next.

For me, that is ultimately the value of good service reporting.

A dashboard should help the business understand what needs attention.

If repeat contact is increasing, where is it coming from and why? If complaints are rising, what themes are appearing? If CSAT has fallen, which journeys are contributing to it? If SLA performance is strong but customers are still chasing, what is happening between those SLA milestones?

Those are useful conversations because they lead towards improvement.

Reporting becomes much less valuable when it turns into a monthly exercise in explaining why numbers changed without anything happening as a result.

The point of measurement is to help the organisation make better decisions about the service.

That means joining operational data with customer feedback, complaints, employee insight and the wider business impact.

When you do that, you start to see the service rather than just the activity taking place inside it.

A good set of measures should help you understand whether customers are finding things easier, whether employees are spending less time on rework, whether the same failures are still happening and whether improvements are actually having the effect you expected.

That is a much more meaningful definition of performance.