Closed-Lost Reasons: Categories, Examples and Definitions

Why the taxonomy decides the quality of everything downstream

Loss reasons are the one piece of loss data almost every company collects, and the one they trust least. The usual complaint is that reps do not fill them in properly. That is rarely the real problem.

A rep facing a dropdown makes a judgement call in a few seconds. If two options could plausibly fit, they will pick whichever comes first, or whichever they picked last time. Multiply that across a team and a year and you get data that is internally inconsistent, not because anyone was careless, but because the list never told them how to decide.

Consistency is a design property of the taxonomy, not a training problem. Every segmentation, revenue calculation, and callback decision you make later inherits the quality of this list.

Four rules before the list

• Reasons must be mutually exclusive in practice, not just in theory. If two could plausibly fit the same deal, write the rule that decides between them and publish it next to the list.
• Name the cause, not the emotion. "Too expensive" is a reason. "Bad fit" is a verdict that hides several different causes and tells you nothing you can act on.
• Keep the list short enough to hold in mind. Past roughly a dozen options, reps stop reading to the bottom and the tail reasons go unused.
• Keep the list stable. Every change breaks comparison with prior periods, so change it deliberately and note the date it changed.

Start with two groups, then six categories

The most useful first cut is not by department. It is whether the loss was caused by what you were selling, or by what was happening inside the buyer organisation.

Solution losses point at your product, your pricing, or how much the buyer trusted you. They are fixed by changing something you control. Buyer losses point at timing, budget cycles, internal politics, or disengagement. They are rarely fixable at the time, but they are the ones most likely to become winnable later, which makes them the core of a recycling programme.

The reasons inside each category

Categories are for reporting; reasons are what a rep actually selects. Thirteen cover the overwhelming majority of B2B losses. This is the set Rizer ships with, and it is a reasonable starting point whatever you use to record losses.

Underneath these sit micro-reasons: the specific version of the reason in a particular deal. "Missing feature" is the reason; "no multi-currency support in the payment integration" is the micro-reason. Reasons are what you report on and compare over time. Micro-reasons are what you actually fix, and grouping losses by micro-reason is what lets you rank fixes by the revenue behind them rather than by how often someone complains.

Note what is absent. There is no "not interested", because it describes an outcome rather than a cause. There is no "bad fit", because that is a qualification failure that should be caught before a deal exists. And "No feedback provided" is deliberately available, because forcing a guess produces worse data than admitting you do not know.

The five confusions worth pre-empting

These pairs account for most inconsistent tagging in practice. Publish the deciding rule alongside the list, where the rep is choosing.

• Too expensive vs. Unclear value / ROI: if the buyer thought the number itself was too high, that is price. If they accepted the number but could not justify the return, that is value. One is a pricing problem, the other a positioning problem.
• Too expensive vs. No available budget: if money existed but not at your number, that is price. If no money existed at all, that is budget. The test is whether a discount could have saved it.
• Better price by competitor vs. Too expensive: only use the competitor reason when a named competitor won on price. If you lost on cost with no alternative chosen, it is Too expensive.
• No decision-making authority vs. Internal misalignment: authority means your contact could not reach the decision-maker. Misalignment means the decision-makers were reached and disagreed.
• Buyer stopped responding vs. No feedback provided: use "stopped responding" when engagement faded mid-process. Use "no feedback" when the deal formally ended without explanation.

Worked examples

Definitions only become operational when people see them applied to ambiguous cases. These generate the most disagreement in practice.

Give every reason a default callback window

A loss reason that only feeds a chart is doing half its job. The more useful question is: given this reason, when does it become worth trying again?

Attach a default waiting period to each reason so recording the loss also schedules the next attempt. "No available budget" points at the next budget cycle. "Not the right time" points at whatever date the buyer named. "Missing feature" should not wait on a date at all; it should wait on the feature shipping, and then trigger immediately.

Defaults are starting points, not rules. A rep who knows the buyer said to call in March should override the default. But defaults mean every lost deal leaves with a plan attached, instead of relying on someone to remember.

Putting it into the CRM

Make the reason a required dropdown at the closed-lost stage. Never free text: free text cannot be aggregated and quietly becomes a hundred variations of the same few answers.

Add short structured fields for the detail that makes a reason actionable: which feature was missing, which competitor won, how large the price gap was, what date the buyer named. These are what turn a category into a callback.

• Put the definitions where the rep is choosing, as field help text. A taxonomy documented in a wiki nobody opens is a taxonomy nobody follows.
• Capture the missing feature by name, not in a comment. Named features are what let you find every affected deal when one ships.
• Record the competitor as a value, not free text, so competitive losses can be totalled by value.
• Keep an honest catch-all. Removing it does not improve data quality; it just pushes noise into whichever real reason is nearest.

One practical note if you are doing this in HubSpot: the taxonomy is a property, and a property is only ever as good as the discipline behind it. Rizer takes the opposite route and derives the profile from the deal record itself, treating the dropdown as one signal among several. A clean taxonomy still makes every report you build on top of it easier to read, so it is worth getting right either way.

Reviewing the taxonomy

Review the distribution quarterly. Three signals tell you the list needs work:

• One reason above roughly 40% is almost certainly concealing several distinct causes. "Too expensive" is the usual offender, and splitting out value and discount cases is usually what resolves it.
• A rising catch-all share means a real reason is missing. Read those deals and name what they have in common.
• A reason below 2% for several quarters is either dead or being avoided. Check which before removing it.

When you do change the list, record the date and treat it as a break in the series. Comparing distributions across a taxonomy change without noting it is an easy way to reach a confident wrong conclusion.

The review is where taxonomies usually die, because nobody owns it. If you would rather not run it by hand, this is the part Rizer automates: it re-reads the record as new losses land, so the categories stay current without a quarterly clean-up project.