Win Loss Analysis: How to Run It in Five Steps, With a Free Template and Real Deal Reasons
Publish date: Nov 4, 2026
A win loss analysis asks buyers why they chose you, chose a rival or chose nothing. Then it turns the answers into counts you can act on. You need three things: a deal log with one reason code per closed deal, a short interview guide, and a monthly review that changes something. This post gives you all three.
The ten reason codes come from Spona's own log of 137 closed deals, and the eight questions from Spona's 29 post-decision interviews. The free Google Sheet holds every one of those deals as example rows. You can watch the formulas work before you clear them. Make a copy of the Sheet and follow the five steps below.
Get thousands of leads in 4 minutes.
Stop stitching tools together.
Start with verified sales data, delivered in minutes.
No contracts · No setup · No onboarding
Win loss analysis: what it answers
A win loss analysis answers three questions: why you win, why you lose, and why deals stall without a decision. Most teams skip the third one. Dixon and McKenna analyzed millions of recorded sales conversations for The JOLT Effect. They found that 40 to 60% of lost deals ended in no decision.
If your log has only Won and Lost, around half of your losses may hide in the wrong column. Count a closed deal as won, lost or no decision, and give each outcome its own codes. A buyer who paused a project did not reject you. A buyer who signed with the incumbent did, and the two need different fixes.
The second thing the analysis answers is how wrong your CRM is. Clozd runs interview programs for vendors. It reports that buyer and seller reasons for lost deals align only 15% of the time. The rep writes "price"; the buyer says the team could not change its process.
Only the buyer's version tells you what to change. So the method below keeps two sources for every reason: the code the rep picks at the close, and the answer the buyer gives a few weeks later. The template records both and shows how often they agree.
Spona's own log makes the point with numbers. It holds 137 closed deals. Of those, 85 ended as wins and 25 as losses. The other 27 ended with no decision.
Computed from those counts, Spona won 62.0% of all closed deals and 77.3% of the deals that reached a decision. The no-decision deals cause the gap between the two rates. A Won-and-Lost log never shows it. The template shows it first.
How do you conduct a win loss analysis?
Five steps, in the order the template expects them. Each step ends with a row, a code or a count, so nothing depends on memory.
- Pull every closed deal, no decision included. Export each closed opportunity from your sales pipeline with its stage history. Keep the deals that went quiet after a proposal. They belong in the log as No decision, not as open pipeline. Klue's guide says you need at least 10 similar deals before a pattern means anything. Spona's log added 32 to 40 closed deals a month over four months. Even so, four of its ten codes stayed under 10 deals. A smaller team should pull at least a quarter. A team closing a handful of deals a month should pull a year.
- Code one primary reason in the CRM. HubSpot ships two default deal properties for this: Closed won reason and Closed lost reason. Limit both to a fixed list of your codes, and add a code set for No decision. One code per deal, picked at the close by the rep who worked it. A deal with two reasons gets the one the buyer named first. Record where the code came from as well: the CRM field, a rep debrief or a buyer interview. If your CRM is a spreadsheet, our CRM template has a lost-reason field you can point at the same list.
- Interview buyers after the decision. The rep's code is a hypothesis; the buyer's answer is the data. Clozd suggests interviewing within 30 to 90 days of the decision, with an even split of wins and losses. User Intuition argues for two to four weeks, while memory is fresh. Klue advises 30-minute calls with an hour blocked in the calendar. Expect 15 to 30% of buyers to accept an interview. Surveys get 3 to 5%. Someone other than the rep should ask. Pragmatic Institute puts product people on the call, because buyers may hold back bad news to protect their relationship with the salesperson.
- Log and count. One row per closed deal: the outcome, the code, the source of the code and the buyer's wording. Then count the deals behind each code. A code with three deals behind it is an anecdote. A code with eleven deals behind it is a pattern. Keep the buyer's wording short and verbatim; a paraphrase loses the word that mattered. Set a minimum before you read any code, and treat everything under it as "not yet". The template does the counting for you and flags any code under the minimum you set.
- Give each top code an owner and a change. Liminal's rule is that insights should update three things every month: battlecards, discovery questions and objection handling. Assign the top code in each outcome to a team. Write the change, and check next month whether the count moved. Clozd's survey found that only 39% of companies run win loss as an ongoing, cross-functional program. 72% of programs sit with go-to-market teams, split evenly between sales and marketing. Pick one owner now and the review date before you leave the room.
Win loss interview questions: the eight we ask
Klue suggests you write 20 to 30 questions and expect to use about half. Spona's guide has eight. They cover the trigger, the alternatives, the evidence, the ranking of criteria, the people, the near miss, the missing change and the aftermath. Six go to every buyer; one goes only to buyers who chose Spona and one only to buyers who did not.
The table shows the questions word for word, with the number of interviews that included each one. Swap "Spona" for your own company name in questions 6 and 7. The Interview guide tab in the template has a column for your wording beside ours. Ask the questions in order: the ranking in question 4 only makes sense once the alternatives from question 2 are on the table.
| # | Question | Asked to | Interviews |
| 1 | What first made this project worth spending time on? | Both | 29 |
| 2 | Which alternatives did you seriously evaluate? | Both | 29 |
| 3 | Which evidence changed your view of the data quality? | Both | 29 |
| 4 | How did usable records, workflow and commercial terms rank in the decision? | Both | 29 |
| 5 | Who influenced the decision and what mattered to each person? | Both | 29 |
| 6 | What nearly stopped you from choosing Spona? | Won | 17 |
| 7 | What would Spona have needed to change to win? | Lost | 12 |
| 8 | What happened after you made the decision? | Both | 29 |
The counts come from 29 scheduled post-decision conversations, separate from the sales calls themselves. 17 followed won deals and 12 followed lost deals. The cohort includes no buyer whose deal ended in No decision. That is the gap we would close first.
The no-decision codes (a paused project, a moving launch date, a procurement review) are hard to code from a CRM field alone. The rep sees the deal go quiet and has to guess. Only the buyer knows whether the project died or merely moved. Add those buyers to your interview list from the first month.
Question 1 earns its place because it separates a real trigger from a vague wish. Question 2 tells you who you were actually up against, which may not be the vendor in the CRM. Question 3 asks for evidence, not opinion, so the answer names a sample, a test or a competitor's file. Question 4 forces a ranking, which is how you learn whether "price" meant the price or the inability to buy small.
Questions 6 and 7 are the pair that changes the sales playbook. The near miss from a won buyer is tomorrow's loss reason. The missing change from a lost buyer is either a product gap or a proof you failed to show. Question 8 catches what happened after the signature or the walk-away, which is where references and churn risks live.
Question 5 matters most for larger accounts. Gartner puts the typical buying group for a complex B2B purchase at six to 10 decision makers. Those buyers spend only 17% of their buying time meeting potential suppliers. The rep may have met two or three of them.
The interview is your one chance to hear what mattered to the others. Record each person's role, not the name. Then feed the roles into your buyer persona template, so the next discovery call asks for them by title.
Win loss analysis: 137 Spona deals by reason
Most published code lists are generic. AskElephant suggests five loss reasons: price, timing, fit, competitor and process failure. Unkover's template sorts reasons into five buckets: pricing, product, people, process and positioning. Neither list comes with real deal counts, and neither gives no-decision deals reason codes of their own.
Spona's CRM uses ten codes across the three outcomes: four for wins, three for losses and three for no decision. Each closed deal carries exactly one. The codes are specific to a data vendor, so rename them for your product. Keep the structure: a code names a reason the buyer would recognize, not a sales stage or a feeling.
The table gives each code, the rule for using it and the buyer wording recorded against it in Spona's log. Each code has one recorded wording. Read the quote as the typical phrasing, not as something every buyer said.
| Outcome | Code | Use it when | Recorded buyer wording |
| Won | Verified coverage | the records for the buyer's target accounts checked out | "We found the right people in the territory we actually sell to." |
| Won | Flexible purchase | the buyer could start small or pay for what they used | "We could fund a focused pilot without buying more data than we needed." |
| Won | Workflow fit | the output fit the tools and steps they already had | "The file was straightforward to use in the workflow we already had." |
| Won | Support and speed | questions and corrections were handled fast | "We got the list definition and corrections resolved quickly." |
| Lost | Existing contract | an incumbent contract runs this budget period | "We are already committed to the incumbent for this budget period." |
| Lost | Budget constraint | no budget for another paid tool | "We cannot add another paid workflow this quarter." |
| Lost | Workflow change | the team could not change process during the evaluation | "Our team could not change its process during the migration." |
| No decision | Project paused | the project lost its owner | "Hiring changed and nobody owns the outbound project right now." |
| No decision | No urgency | the need exists but the date driving it keeps moving | "We need the data, but the launch date keeps moving." |
| No decision | Procurement delay | the decision waits on supplier or procurement review | "We are waiting for the internal supplier review." |
Verified coverage was the code on 31 of the 137 deals, the largest single share. Computed from the counts, that is 36.5% of the wins. On the loss side, Existing contract was the code on 11 of 25 losses. Its recorded wording names the budget period, not the product.
Procurement delay was the code on 11 of the 27 no-decision deals. The three biggest reasons for not winning all sit inside the buyer's company: a contract, a review and a missing owner. That is why the interview guide asks what happened after the decision, and why step 1 keeps no-decision deals in the log.
Flexible purchase, the second win code at 23 deals, is the one you can check against public prices. Spona's Pro plan costs $99 a month and includes 10,500 credits. A new search session takes 1,000 credits, which leaves 9,500. Standard Search with email only costs 3 to 7 credits a lead.
By our calculation, that first month buys about 1,357 to 3,166 verified leads. Every search starts with a free sample. The fee is refundable for 14 days as long as you have not spent any credits. That is the kind of purchase the code's recorded wording describes.
Win loss analysis template: what each tab answers
The template is a Google Sheet with five tabs. Make a copy, and it opens with Spona's 137 deals already in the Deal log. Every count and flag on the other tabs is live before you type anything. Clear the example rows when you are ready, or keep them for a month to learn the formulas.
| Tab | What it answers | What is inside |
| Instructions | How do I set this up and keep it honest? | Six setup steps, the minimum-deals setting, every dropdown list in one place |
| Deal log | What happened in each closed deal, and why, in one code? | One row per deal: outcome, reason code, where the code came from, buyer wording, next question asked, interviewed yes or no |
| Reason codes | What does each code mean, how often does it come up, and who owns the fix? | Ten codes with their rule, buyer wording and next question; live counts and shares; Spona's counts for reference; a flag for codes with too few deals |
| Interview guide | What do buyers say after the decision, and does it match the CRM code? | The eight questions with your own wording beside them; a log with a Match column that compares the buyer's reason with the CRM code |
| Summary | Where do we win, lose and stall, and is it changing? | Outcome counts and win rates, top three reasons per outcome, outcomes by company size and by competitor, interview match rate, closed deals per month |
Three things in the Sheet stop the log from drifting. First, the Deal log's Code check column tests each row's code against its outcome with COUNTIFS. It prints "Code does not fit outcome" when a rep logs a win reason on a lost deal. Second, the Outcome, Size band and Reason code columns are dropdowns from a range that reject anything off the list.
The Competitor column only warns, so "ZoomInfo + Sales Navigator" still fits. Third, the Reason codes tab flags any code with fewer deals than the minimum on the Instructions tab. The flag reads "Too few deals to read", and the minimum starts at 10. With the example rows, four codes carry that flag.
The Reason codes tab also keeps Spona's counts in two fixed columns for reference. Your live counts sit beside them, so you can see whether your losses cluster where ours did. Each code has a suggested owner team from a dropdown: sales, marketing, product, pricing or leadership. Rename the codes to fit your product and the owner stays with the row.
The Interview guide tab is where the 15% alignment problem becomes visible. Each interview row pulls the deal's outcome and CRM code from the Deal log. It takes the buyer's main reason from a dropdown of the same codes and prints Match or Mismatch. The Summary tab turns those into a match rate.
If yours is low, your reps are not lying. They are guessing, and the fix is step 3, not a reprimand. The Summary tab also breaks outcomes down by company size band and by competitor named. Once you add close dates, it counts closed deals per month.
Two more Deal log columns keep the log honest. Source of reason records whether a code came from the CRM field, a rep debrief or a buyer interview, so you can see how much of your log rests on guesses. Interviewed marks the deals with a completed interview, and the Summary counts them. Filter the Deal log by outcome to compare your won and lost interviews with the even split Clozd recommends.
Other free templates on this topic are thinner. Mural's is a whiteboard behind a signup, Klue's spreadsheet sits behind a form, and Unkover's XLSX has eight fields and no example data. Excel users can take our file through File, Download, Microsoft Excel (.xlsx). The formulas use COUNTIFS, INDEX, MATCH and SUMPRODUCT, so Excel and LibreOffice recalculate them without edits.
Win loss analysis: turning reasons into changes
A count is not a change. The Reason codes tab gives every code a suggested owner team. The Deal log records the next question the rep asked once the code was clear. Those questions are the start of the fix, because they test whether the reason was real or a polite exit.
The six codes that cost Spona deals, with our suggested owner and the next question the rep asked:
| Code | Suggested owner | Next question asked |
| Existing contract | Sales | When does the renewal decision happen, and can we test a gap before then? |
| Budget constraint | Pricing | What current tool or research cost would a successful pilot need to replace? |
| Workflow change | Product | Which part could be tested without changing the current sending workflow? |
| Project paused | Sales | Who should own the next decision and when should we revisit it? |
| No urgency | Marketing | What event would make this an active project? |
| Procurement delay | Sales | Which evidence would help the reviewer finish the decision? |
Three of the six questions are about timing: a renewal date, a revisit date, an event that makes the project active. That points to a qualification fix rather than a product fix. Ask about the incumbent's renewal date and the project's owner on the first call. Our lead qualification checklist is where those two questions belong.
Workflow change points at product and onboarding. The lost buyer could not change process mid-migration, so the change is a pilot that runs beside the current workflow instead of replacing it. Budget constraint points at pricing. Its question asks which current cost a pilot would replace, which turns "no budget" into a comparison.
The win codes deserve the same treatment. Verified coverage won the most deals. The proof behind it, a test on the buyer's own target accounts, belongs in the first call, not the third. Flexible purchase won 23 deals, which argues for leading with the small pilot rather than the annual contract.
Review the counts on a fixed schedule. Clozd recommends a standing monthly or quarterly review. Monthly fits a team closing 30 or more deals a month; quarterly fits a smaller one. Cotera's practitioner write-up describes a one-page monthly summary in three paragraphs: the numbers, the pattern and the actions.
The Summary tab gives you the first paragraph. The second paragraph is the code whose count moved most. The third names who changed what, and the date you will check it again.
Get thousands of leads in 4 minutes.
Stop stitching tools together.
Start with verified sales data, delivered in minutes.
No contracts · No setup · No onboarding
Win loss analysis FAQ
Who should run win loss interviews?
Not the rep who worked the deal. Klue's guidance is an impartial interviewer, with sales making the warm introduction. Pragmatic Institute wants product people to lead, because buyers may hold back criticism that could hurt the salesperson.
Clozd's survey found that teams using a third party are over twice as likely to say their feedback goes deep enough. A sales leader who was not on the deal is the practical middle option for a small team.
How many deals for a win loss analysis?
Klue sets the floor at 10 similar deals per pattern. For interviews, Clozd finds answers reach saturation at 25 to 30 per segment. User Intuition puts the minimum for directional patterns at 20 to 30 interviews.
Liminal notes that most programs interview 8 to 12 buyers a quarter, too few to see a shift. Spona's 29 interviews over four months fall inside the Clozd and User Intuition ranges, read as one segment.
How is win loss calculated?
Win rate is won deals divided by closed deals. Klue's worked example divides 40 wins by 100 closed deals. The same 40 wins against 60 losses make a two-to-three win-loss ratio. Decide whether "closed" includes no-decision deals and say so on the report.
Spona's log computes two rates from the same counts: 62.0% of all closed deals and 77.3% of decided deals. The template shows both, because the gap between them comes from your no-decision deals.
Can CRM win loss reasons replace interviews?
No, but keep both. The CRM code is cheap, immediate and covers every deal, which makes it the right denominator for counts. In HubSpot, the first fix is to limit the default reason properties to a fixed list of your codes.
The interview is slow and covers a sample, but it is the only source the buyer controls. Clozd's 15% alignment figure is the reason the template has a Match column. It shows you how often the two sources agree on your own deals.
Share this article
GET FREE LEADS
