Win-Loss Reason Code Template
Three documents and four sheets, turning your largest catch-all loss bucket into codes tested against win rate, not typed into a dropdown.
Free download · No account needed
Reason Code Register (sample)
Fenwright CRM Solutions, a fictional B2B SaaS company. One row per closed deal; original CRM picklist code alongside the derived code from reading the free text.
| Deal | Original picklist code | Derived reason code | Differ? |
|---|---|---|---|
| FW-2031 | No Decision / Timing | Champion left or org reorganized | yes |
| FW-2058 | Other | Chose to build in-house | yes |
| FW-2079 | Competitor | Competitor – Northbridge Systems | no |
| FW-2145 | Other | Miscoded – deal was still active | yes |
Across the full 142-deal register, the original code and the derived code disagree on 52 deals, all of them originally filed under No Decision / Timing or Other.
Win Rate by Reason
Each derived category searched across the full closed set, won and lost, for the same language appearing before the deal closed.
| Signal in notes before close | Deals flagged | Won | Lost | Win rate when flagged | Baseline win rate |
|---|---|---|---|---|---|
| "Champion turnover" language present | 20 | 2 | 18 | 10.0% | 40.3% |
Baseline win rate is 4.0x the flagged rate. A champion-turnover mention in the notes, while the deal is still open, is a stronger predictor of the outcome than most stage-based forecast categories.
Competitor Mapping
The 31 deals the CRM coded "Competitor," broken out by which competitor the notes actually name.
| Named competitor | Deals | Share | Value lost |
|---|---|---|---|
| Northbridge Systems | 14 | 45.2% | $714,000 |
| Vantable | 9 | 29.0% | $459,000 |
| No competitor named in notes | 8 | 25.8% | $408,000 |
Northbridge alone accounts for nearly half of named-competitor losses, concentrated enough to justify one specific competitive teardown rather than a generic battlecard.
The standard advice for closed-lost reasons is a controlled picklist, not free text, and it isn't wrong on its own terms. Trailhead's own competitor-tracking guidance recommends a picklist specifically because free text produces variants that are painful to group later: a rep typing Price, Pricing, Too expensive, and Budget issue for one real reason. The trade a picklist makes is coarseness. Reps click whichever value is fastest at the end of a long deal, and the value absorbing everything else, usually No Decision, Timing, or Other, quietly becomes the board's largest bucket.
This pack does the grouping a picklist exists to avoid doing by hand, but from the free text already in your CRM: call notes, last-activity logs, whatever a rep typed. It reads every deal in the board's largest catch-all bucket, clusters the recurring situations reps actually described, and requires five deals behind a new category before it counts. Then it runs a pass a taxonomy alone skips: searching the full closed set, won and lost, for each category's language appearing before the deal closed, to find which ones predict rather than just describe.
On a worked run for Fenwright CRM Solutions, a B2B SaaS company, No Decision / Timing held 52 of 142 closed-lost deals, 36.6% of losses. Reading the free text split it into four situations, the largest being 18 deals where a champion left or the buying org reorganized. Deals carrying that language in the notes before close won at 10%, against a 40.3% baseline, worth a mid-deal flag, not a line in a quarterly report. The pack pairs with reweighting a forecast by rule-scored deal quality and finding which rep behaviors already caused a miss.
What's in the pack
Reason Code Definitions
Named categories derived from reading the catch-all bucket's free text, each requiring five or more deals before it counts as a category.
Reason Code Register
Every closed deal, won and lost, tagged with both the original picklist code and the derived one, so the gap between them is a row-level number.
Win Rate by Reason
Each derived category tested against the full closed set for whether its language predicts the outcome before the deal closes, not just after.
Trend
Each category's share of quarterly losses over the trailing four quarters, so a rising pattern is visible before it's a full year old.
Competitor Mapping
Competitor-coded losses broken out by the specific rival actually named in the notes, not left as one undifferentiated bucket.
Capture Policy and Rep Guidance
A required free-text field for the two vaguest picklist values going forward, with the one sentence of detail that makes a note usable.
How to use it
- 1
Send the closed deal export
Closed-won and closed-lost records for the trailing four quarters, with whatever picklist code the CRM already has and any free-text notes attached.
- 2
Read the catch-all bucket first
Every deal in the largest picklist value, in full, clustered into specific named situations rather than sampled or skimmed.
- 3
Test each code against win rate
The same language searched across the full closed set for whether it appears, and predicts the outcome, before the deal closes.
- 4
Get the register and the trend
Every deal tagged with both codes, competitor losses mapped by name, and each category's share tracked by quarter.
Frequently asked questions
Doesn't a free-text field just recreate the mess a picklist was meant to fix?
Only if a person has to read it raw every time. The picklist stays in place for reporting. This pack reads the free text once per quarter to derive a small set of named codes, each requiring five or more deals, so the output stays as clean as a picklist without losing what the picklist discards.
What if our reps barely write any notes on closed-lost deals?
The pack works with whatever free text already exists, including thin last-activity logs. The Capture Policy doc adds one required field going forward for the two vaguest picklist values, with a minimum length so a non-answer like "timing" can't satisfy it.
How is this different from a customer win-loss interview program?
It reads what's already in the CRM instead of scheduling new conversations, so it works on deals from a year ago as easily as last week's. A structured interview program answers a different, complementary question: what the buyer says now, in their own words, after the fact.
How many deals does a new reason code need before we trust it?
Five, at minimum, per the pack's own rule. A category built from two or three similar-sounding notes is a guess wearing a label; fewer than five gets folded into a nearby category or marked provisional in the definitions doc until another quarter of data arrives.
What does 'tested against win rate' actually mean?
Each derived category's language gets searched across every closed deal, won and lost, not just the ones that lost, for whether it appears before the deal closed. Fenwright's champion-turnover signal showed a 10% win rate against a 40.3% baseline once tested this way, turning a loss-reason label into an early warning.
Does this replace the forecast accuracy review or pipeline hygiene work?
No. Pipeline hygiene scores which open deals belong in the pipeline count, and forecast accuracy review explains why a quarter already missed. This pack answers a narrower question: why deals are actually won and lost, in language specific enough to act on.
Does this pack cover renewals, or only new-business deals?
New-business closed-won and closed-lost only. A renewal that lapses is a different event with different signals, usually a usage decline rather than a competitive loss. The renewal and churn forecast template covers that side, scoring renewal risk from account usage trend instead of deal notes.
Find out what your catch-all loss bucket is actually hiding
Send a closed deal export with whatever free text already exists, and get named reason codes tested against win rate.
Get the template