Pareto Analysis

A customer support team is fielding more tickets than it can close, and everyone has a theory about the biggest cause: a confusing checkout flow, a slow app, unclear billing emails. Without data, every theory sounds equally plausible, and the loudest voice in the room usually wins the debate. Pareto analysis replaces the debate with a count.

Pareto analysis, based on the observation by economist Vilfredo Pareto that a small share of causes tends to produce a large share of effects, ranks causes by how often they actually occur and looks for the small number responsible for most of the volume: commonly summarised as the 80/20 rule, though the real split is rarely exactly eighty and twenty. The output is usually a bar chart of causes ordered from most to least frequent, with a line showing cumulative percentage. The pattern shows up far beyond economics, from which product lines generate most of a company's revenue to which bugs generate most of a support team's tickets, which is why the same simple chart keeps reappearing across such different problems.

• Use it whenever you have a list of recurring problems, complaints or defects and need to know which ones actually matter most.
• Use it before allocating limited time or budget to fixes, so effort goes toward the causes with the biggest real impact.
• Use it to settle disagreements about priorities when opinions in the room differ and nobody has counted anything yet.
• Do not use it without real data: a Pareto analysis built on guesses about frequency is just an opinion with a chart around it.
• Do not assume the top cause found last quarter is still the top cause; the ranking needs rechecking as conditions change.

One-page model visual

The one-page visual

Use this visual as a quick reference. The card in the deck adds the questions and the steps to run the model in your next meeting.

See all 50 models as cards →

The most common mistake is running the analysis on categories that are too broad to act on, such as "technical issues", which lumps together a dozen genuinely different problems under one label. A category that broad will always look like the biggest cause, simply because it is a bucket for everything, and that tells the team nothing about what to actually fix.

The second mistake is stopping at the count and skipping the "why" behind the top causes. Knowing that one ticket type accounts for thirty percent of volume is a start, not an answer: the team still needs to dig into why that specific issue keeps happening before a fix makes sense.

A subtler version of the same mistake is counting tickets rather than counting cost. A high-frequency issue that takes thirty seconds to resolve can matter less than a rarer one that ties up an agent for an hour each time, and a Pareto analysis built purely on ticket volume will rank the first one higher even though the second one is doing more damage to the team's capacity.

Illustrative example: a fictional company, not a customer case.

For the support team, a month of tickets, tagged and counted by specific type rather than broad category, shows that "unclear delivery date at checkout" accounts for close to a third of all tickets on its own: more than double the next largest category. Nobody in the original debate had named that specific issue at all; it had been buried inside a general "checkout confusion" theory nobody could act on.

Checking resolution time alongside frequency confirms the ranking rather than overturning it here: the delivery-date tickets are quick to answer individually, but their sheer volume still makes them the biggest single drain on the team's total hours this month, ahead of anything else on the list.

That one ranked, counted cause is now a clear candidate for the team's next sprint, ahead of three other theories that, once counted, turned out to be minor. The card takes you through the remaining steps to a decision.

• Front: what Pareto analysis is for and why it needs real counted data, not opinions, to work.
• Back: the numbered steps to apply the model, plus a short worked example of its own. The company in this guide is a separate illustration, not the example printed on the card.
• Digital: a Google Sheets calculator that turns a raw list of tagged issues into a ranked Pareto chart automatically, with a video tutorial.

• Fishbone Diagram is often used first, to generate the list of candidate causes that Pareto analysis then ranks.
• DMAIC Model gives Pareto analysis a place within a broader structured improvement cycle.
• Theory of Constraints pairs well when the top-ranked cause turns out to be a capacity bottleneck rather than a one-off defect.

BizDecks is the cheat sheet for business decisions: 50 models, one card each. See the toolkits.