White Belt · 12 min
Pareto: finding the few categories that carry the problem
After this you can
- build a Pareto chart from defect counts and identify the vital few categories.
Assumes you have done DMAIC: what each phase produces and why the order holds.
The problem
An IT helpdesk had 326 tickets reopened in a quarter and a team meeting that produced eleven improvement ideas. Everybody's idea was about the thing they personally found most annoying. The manager, sensibly, asked which of the eleven would move the number. Nobody knew. Somebody counted the reopening reasons that afternoon: two categories accounted for 70% of every reopened ticket, and neither had come up in the meeting.
The idea
A Pareto chart is a bar chart of categories sorted from most frequent to least, with a line showing the running cumulative percentage. That is the whole construction. Its value is not the arithmetic — it is that it forces a conversation about evidence rather than salience.
Left to ourselves, we prioritise what is recent, what is vivid, or what happened to us. A Pareto chart replaces that with counts.
It is built on an empirical observation, not a law: in many processes a small number of categories account for most of the occurrences. This gets called the 80/20 rule, and that framing does more harm than good. Your data will not produce 80/20. It might produce 70/30 or 55/45 or a completely flat distribution. A flat Pareto is a real and useful result — it tells you there is no vital few, and that a single fix will not move the number. Teams who expect 80/20 tend to force a cut where the data does not support one.
Three things to get right:
Count the right thing. Frequency is the default, but not always the right measure. Ten password resets and one data-loss incident are not comparable by count. If the categories differ hugely in cost or severity, weight by cost — and say on the chart which you used.
Choose categories that point at an action. "Other" and "User error" are not categories; they are places to put things you have not investigated. If "Other" is one of your tallest bars, your categories are wrong.
The cut is a judgement, not a calculation. The cumulative line helps you see where the curve flattens. Where you draw the line is a decision about your capacity and the effort each category will take. The chart informs it; it does not make it.
Worked example
Every reopened ticket in one quarter, by the reason recorded at reopening.
| Reason | Count |
|---|---|
| Password reset did not persist | 142 |
| Issue recurred within 48h | 87 |
| Wrong team assigned | 41 |
| Resolved without contacting user | 23 |
| User could not follow instructions | 14 |
| Hardware fault misdiagnosed | 9 |
| Duplicate of another ticket | 6 |
| Other | 4 |
Total = 326.
Already sorted, which is the first step. Now the cumulative percentage — a running total divided by 326:
| Reason | Count | Cumulative | Cumulative % |
|---|---|---|---|
| Password reset did not persist | 142 | 142 | 43.6% |
| Issue recurred within 48h | 87 | 229 | 70.2% |
| Wrong team assigned | 41 | 270 | 82.8% |
| Resolved without contacting user | 23 | 293 | 89.9% |
| User could not follow instructions | 14 | 307 | 94.2% |
| Hardware fault misdiagnosed | 9 | 316 | 96.9% |
| Duplicate of another ticket | 6 | 322 | 98.8% |
| Other | 4 | 326 | 100% |
Two categories carry 70%. Not 80 — 70, and that is simply what the data says.
Now read it properly, which is where most of the value is:
The top category is specific and actionable: password resets that do not persist points at one system behaviour. Good.
The second, "issue recurred within 48h", is not a cause at all — it is a restatement of the symptom. It tells you a fix did not hold; it does not tell you why. That category needs breaking down before it can be worked on, and noticing this is more valuable than the chart itself.
And "User could not follow instructions" at 14 is worth a moment. It is phrased as the user's failing. Reworded as "instructions were not followable" it becomes something you can fix. Category names carry assumptions, and the assumptions survive into the solutions.
Dataset: ds-helpdesk-tickets — the same data loads in the tool below, so you can reproduce every figure here yourself.
Your turn
Open the Pareto Chart tool with the helpdesk data.
Three things to try:
- Read the cumulative line at the second bar and confirm 70.2%.
- Merge "Duplicate" and "Other" into a single bar. Notice that it changes nothing about the decision — small categories rarely do, which is why arguing about them wastes time.
- Now rank by cost instead of count. There is no weight column and no multiplier: you retype the values. The misdiagnosed hardware faults cost roughly forty times the others, so enter 360 where the count said 9 and leave the rest alone. One category climbs from the bottom of the chart to the top. Tick These values are weighted by impact as well — it changes no number, it only stops the tool advising you to try weighting, which is worth knowing about a checkbox that looks like it does arithmetic. Only one category moves, and that is the point: the vital few by count and the vital few by cost are different lists, and nothing on a count chart tells you so.
Pareto Chart
practiceShow the data behind this chart
| Rank | Category | count | Share | Cumulative |
|---|---|---|---|---|
| 1 | Password reset did not persist | 142 | 43.6% | 43.6% |
| 2 | Issue recurred within 48h | 87 | 26.7% | 70.2% |
| 3 | Wrong team assigned | 41 | 12.6% | 82.8% |
| 4 | Resolved without contacting user | 23 | 7.1% | 89.9% |
| 5 | User could not follow instructions | 14 | 4.3% | 94.2% |
| 6 | Hardware fault misdiagnosed | 9 | 2.8% | 96.9% |
| 7 | Duplicate of another ticket | 6 | 1.8% | 98.8% |
| 8 | Other | 4 | 1.2% | 100.0% |
Ranked by frequency. If these categories differ sharply in cost or severity, the ranking may point at the wrong one — try weighting by impact and compare.
3 of 8 categories reach 80% of the total. The 80% line is a convention, not a rule your data has to obey — where you actually cut is a judgement about effort and capacity.
One per line: a name, then the value. Paste straight from a spreadsheet — tabs, commas, £ signs and thousands separators are all understood.
How this is calculated
Categories are sorted by value, descending. The cumulative percentage is the running total divided by the grand total, times 100. Ties are broken alphabetically so the chart does not reorder between runs.
Source: Montgomery, Introduction to Statistical Quality Control 7e, §5.4. The “vital few and trivial many” is Juran’s formulation, and Juran later noted he had misnamed the principle after Pareto.
Check yourself
No hints. Wrong answers are explained, not softened.
A Pareto chart of 12 defect categories shows the tallest bar at 14% and the shallowest at 5%, with the cumulative line nearly straight. What does this tell you?
Categories: A=50 incidents at £10 each, B=8 incidents at £900 each, C=30 at £15. Ranked by count, A is the vital few. What should you do?
In the helpdesk data, the second-largest category is 'Issue recurred within 48h' at 87 tickets. Why is this category problematic?
Worth remembering
How is the cumulative % on a Pareto chart calculated?
Running total of counts (sorted descending) divided by the grand total, x 100.
When should a Pareto chart NOT be ranked by frequency?
When categories differ sharply in cost or severity. Weight by impact instead, and label the chart with which measure you used.
Can you do this now?
Rate yourself honestly. We compare your rating with how you actually answered — the gap is more useful than either number alone.
I can build a Pareto chart from defect counts and identify the vital few categories.
Your rating is recorded alongside your drill results. Neither alone marks the competency as met.