When the Data and the Complaints Disagree

This conflict arrives in every programme. Showing people the dashboard ends the conversation and loses the information in the complaint.

The measurement in “When the Data and the Complaints Disagree” should connect system evidence with the time required to complete real work, without turning one metric into a judgement about a person. Teams considering the time-recording overview can compare workload and project time at an appropriate group level, but should interpret the pattern alongside surveys, walkthroughs and the people doing the task.

For an independent benchmark, compare this approach with Pew Research Center; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

Why both can be right

Averages hide the complainant's experience, which the averages note covers.

The measure does not cover what they are describing. Application responsiveness is measured at launch, not during the slow report that runs at four o'clock.

Timing. The problem happens at 09:05 when everybody logs in and the daily average is fine.

The friction is not technical at all, which is the most common explanation.

Or the telemetry is wrong, which happens and should be checked before the person is doubted.

Treating the complaint as data

A complaint is a measurement of experience, which is the thing the programme exists to improve.

The useful question is not "is the dashboard right" but "what are they describing".

Ask: what were you doing, when, how long did it take, what did you expect.

Four questions, and they usually locate the issue within an hour.

The common resolutions

A time-of-day peak invisible in daily figures.

One application or one task, not the device.

A wait for a person, misattributed to the system.

An old device in a cohort that averages well.

Each has a different fix and none is "the data says you are wrong".

Checking your own instruments first

Agent not reporting. Measure defined differently from what people mean. A gap in coverage.

A complaint is frequently the first symptom of a broken measurement, and dismissing it means the measurement stays broken.

The credibility cost

A programme that uses its numbers to tell people their experience is mistaken loses the organisation.

After that every figure is contested, including the sound ones, and the programme stops being able to inform anything.

This is a practical reason, beyond the obvious one, to take complaints seriously.

Reporting the resolution

"You said it was slow. The daily average is fine and the 09:00 peak is four minutes, which is when you were trying. Here is what we are changing."

That reply uses both sources, confirms the person was right, and is believed.

Building the route

People need somewhere to report friction that is not a ticket, because much of it does not feel like an IT fault.

A short form, an email address, a question in the survey.

And it has to reach whoever reads the data, which in most organisations it does not.

What to check

When somebody last contradicted your data, what happened?

Did anybody check the instruments before dismissing it?

Do your measures have a time-of-day view?

And is there a route for reporting friction that is not a ticket?

The point

A complaint is frequently the first symptom of a broken measurement.

Check your instruments before doubting the person.

Underlying all of this

Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.