Granularity is a decision, not a default
Almost nobody chooses their taxonomy; they inherit it. Making the level explicit turns a constraint everyone works around into something you set.
Voice of the Customer
Category abstraction levels
Categories that are too broad tell you nothing you can act on. Categories that are too fine turn reporting into a thousand rows with no signal in them. This is the setting that decides which of those you end up with, and it is worth choosing deliberately rather than inheriting from whoever configured the system.
- Set how coarse or fine your categories are
- See the same support volume at each level
- Issue types that nobody defined still appear
- Reporting that stays readable as volume grows
Every taxonomy fails in one of two directions
Too broad, and the report is unarguable and useless. “Hardware” is forty per cent of your volume; everybody already knew that and nobody can act on it on Monday morning.
Too fine, and you get nine hundred categories, most holding a handful of tickets and none large enough to justify attention. The usual result is a taxonomy set once by whoever configured the system, never revisited because revisiting means re-tagging everything behind it.
Choosing the level deliberately
Start from the decision you make with the report, not from the list of categories.
- Step 1
Start from the decision
The right granularity is whatever makes the decision you actually make. If you brief engineering on field failures, “hardware” is nowhere near specific enough.
- Step 2
Set the level explicitly
The abstraction level is a setting rather than an accident of how somebody configured the system three years ago.
- Step 3
Look at the same volume at each level
The same tickets are examined at different granularities, which makes the trade-off visible.
- Step 4
Move it as the business moves
A taxonomy that fitted two products does not fit six, and the level can change when your products do.
Three reasons this setting matters more than it sounds
It looks like configuration. It is actually a setting on your reporting.
Categories come from content, not a dropdown
Because issues are grouped by what is in them rather than by what somebody selected, changing the level of detail does not require redefining a list by hand.
Your reporting is downstream of this
Every trend report and driver ranking is a count of these categories. A taxonomy at the wrong level produces reporting that leads confidently to the wrong decision.
Why the usual approaches fall short
Each of these is a reasonable response to the problem, and each fails at volume.
A category list defined once at implementation
Fits the products you had then, and never gets revised because revising means re-tagging.
Letting each team define their own
Every team gets categories that suit them and nobody can produce a defensible number.
Free-text tags
Flexible, and they fragment immediately into six spellings of the same tag.
One flat list for everything
Readable at fifty tickets a week. At real volume it is too coarse or too long to apply correctly.
What things are called
Useful to agree on before the taxonomy conversation rather than during it.
- Abstraction level
- How coarse or fine the categories are — the setting this tour is about.
- Taxonomy
- The full set of categories a request can be assigned to.
- Clustering
- Grouping requests by their content rather than by an assigned label, which is what lets a new issue type appear without anyone defining it first.
- Long tail
- The many small categories that appear at a fine abstraction level. Individually negligible, collectively significant.
- Driver
- A category ranked by the volume or the impact it is generating.
Frequently Asked Questions
The one that matches the decision you make from it. If you allocate people by team, categories cutting across teams are too broad; if you brief engineering on field failures, "hardware" is useless. Start from the decision and work backwards rather than starting from the list.
Where this fits
Auto categorisation tour
The layer this configures: issue types applied to requests as they arrive.
Ticket intent tour
What gets read before a category is applied, and why the reading matters more than the label.
TopDrivers
The ranked view these categories feed, by volume and by impact rather than volume alone.
More Voice of the Customer tours
Voice of the Customer
Bring the report you argue about
Most teams already suspect their top-issues report is not right. Show us the one you produce today and we will show you the same volume at a level that answers the question you were asking.
Talk to us