Skip to content
Sections
All notes

All notes · Measuring

Ticket Data You Already Have

The richest unused source in most organisations, and why the category report hides what the free text shows.

Measuring · Analysis

Every service desk accumulates a detailed record of what goes wrong. Almost all of it is reported as category counts, which is the least informative view available.

The friction described in “Ticket Data You Already Have” becomes easier to prioritise when the team can separate active work from waiting and repeated handling. An organisation evaluating the reporting guide can record time against the affected workflow and compare the effort before and after a change, while ticket and device records remain the evidence of the technical event itself.

For an independent benchmark, compare this approach with Atlassian IT service management resources; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

Why categories mislead

Categories are chosen at ticket creation for routing, not for analysis.

"Password reset" and "access request" absorb an enormous range of underlying problems.

And agents pick whichever category closes the ticket fastest, which is rational and destroys the data.

A category report tells you how tickets were filed, not what happened.

Reading the free text

Take a hundred tickets at random from one month.

Read the description and the resolution, not the category.

Group them yourself into whatever themes emerge.

An hour, and it produces a picture that the category report does not contain. This is the single highest-return analysis in this field and almost nobody does it.

What usually emerges

A small number of root causes generating a large share of tickets.

Repeat contacts from the same people about the same thing, which the ticket system counts as separate incidents.

Requests that are really process complaints: "I need access again" means provisioning expired.

And tickets closed without the underlying problem changing, which is the pattern described in the friction note.

Measures worth tracking

Repeat contact rate: how often the same person returns with the same issue.

Reopen rate.

Time to resolution, split by whether the fix was technical or required somebody else.

And tickets per hundred users per month, by department — variation between departments usually reflects a local problem rather than local people.

What tickets do not show

Friction nobody reports, which is most of it.

People work around problems rather than raising them, especially small recurring ones.

Which means ticket volume understates friction and understates it unevenly: confident users raise tickets and others do not.

Combining with telemetry

Tickets say what people noticed. Telemetry says what happened.

The interesting cases are where they disagree: a device with poor telemetry and no tickets is somebody suffering quietly.

That cohort is worth finding and is invisible to either source alone.

Before you buy anything

This analysis costs an hour and no procurement.

Do it before a platform demonstration, because it tells you which questions you actually have and makes the demonstration a comparison rather than a presentation.

What to check

Has anybody read ticket free text this year, or only the category report?

Do you know your repeat contact rate?

Does ticket volume vary by department, and do you know why?

And are there devices with bad telemetry and no tickets?

The point

Categories are chosen at ticket creation for routing, not analysis.

Reading a hundred ticket descriptions takes an hour and is the highest-return analysis in this field.

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.