Issue category distribution

Issue category distribution is the breakdown of reported issues by type, shown as the percentage each category represents of the total. Rather than knowing only that 500 issues came in last month, you know that 35 per cent were billing queries, 22 per cent were login problems, 18 per cent were feature requests, and the rest spread thinly across smaller categories. That breakdown is the map of where your support and engineering effort is actually going.

The distribution matters because effort and impact are rarely evenly spread. A handful of categories almost always account for the majority of volume. When you know which ones, you know where a single fix, a clearer help article, or a product change will remove the most future work. Without the distribution you treat every issue as equally likely and spread attention thinly across all of them.

The analysis is most useful when tracked over time. A category that jumps from 5 per cent to 20 per cent of volume in a month is a signal: a release introduced friction, a pricing change confused customers, or a competitor campaign sent a wave of comparison questions. The headline issue count can stay flat while the mix underneath it shifts completely, and only the distribution reveals that movement.

For each category, divide the number of issues tagged to it by the total number of categorised issues, then multiply by 100. The result is that category share of the whole. Do this for every category and the shares sum to 100 per cent, giving you the full distribution.

A worked example: in a month with 500 issues, 175 are billing, 110 are login, 90 are feature requests, and 125 are spread across smaller categories. Billing is 35 per cent, login is 22 per cent, feature requests are 18 per cent, and the remainder is 25 per cent. Sort the categories from largest to smallest and the priorities become obvious. Track each share month over month so a rising category is caught while it is still small.

1. 1

   A defined category set

   An agreed list of categories that is mutually exclusive and collectively exhaustive, so every issue has exactly one home and nothing is double counted.

2. 2

   Issues tagged per category

   The count of issues assigned to each category in the period. Accurate tagging at intake is the input that makes the whole analysis trustworthy.

3. 3

   Total categorised issues

   The sum of issues across all categories. Exclude untagged issues from the denominator or they quietly distort every share.

4. 4

   Category share

   Each category count divided by the total, as a percentage. The full set of shares is the distribution itself.

A distribution shows you what is arriving, but not why one category dominates. A metric tree decomposes a large category into the underlying drivers, so you act on the cause of the volume rather than just routing more agents at the symptom.

There is no universal target distribution, because the right mix depends on your product and customers. What does generalise is the shape: a healthy distribution is concentrated enough to act on but not so concentrated that one category signals a serious defect. The rough guide below describes how to read the shape rather than prescribing exact percentages.

Improving the distribution does not mean forcing categories to be equal. It means shrinking the categories that represent avoidable work and keeping the tagging clean enough that the analysis stays trustworthy.

1. 1

   Letting the other bucket grow unchecked

   When uncategorised or other issues swell past 15 per cent, the distribution stops describing reality. Review that bucket regularly and split out any theme large enough to name and act on.

2. 2

   Comparing share without comparing volume

   A category can fall in share simply because total volume rose. Always read the percentage alongside the absolute count so a shrinking share does not hide a growing problem.

3. 3

   Allowing inconsistent tagging

   If two agents file the same issue under different categories, the distribution is noise. Give tagging clear definitions and review accuracy, because the analysis is only as good as the labels feeding it.

4. 4

   Treating volume as importance

   The largest category is not always the most urgent. A small category of security or data-loss issues outranks a large category of cosmetic requests. Weight by impact, not just by count.