Win-Loss Analysis: A Buyer Interview and Evidence Template

Win-loss analysis investigates why a buyer selected your offer, chose another option, stayed with the status quo or stopped the project. The strongest starting point is a permissioned conversation about the actual decision, supported by a timeline and a record that separates what the buyer said from what your team thinks it means.

Use this guide to run a small, honest learning cycle: choose a decision to understand, invite the buyer without reopening the sale, reconstruct the events, code the evidence and agree on one test. You will leave with a usable interview guide and analysis worksheet, not a made-up “top loss reason” based on one conversation.

Start with the decision, not the CRM label

A closed-lost dropdown is an internal summary. It might capture the seller's best understanding, a required field entered quickly, or one factor among several. Treat it as a hypothesis to investigate, not the answer you need the buyer to endorse.

Clozd's current interview guide recommends buyer-specific preparation, open questions, adaptable topics and analysis after the conversation. The worksheets below are an original way to preserve those distinctions. They do not adopt the vendor's commercial performance claims or promise a certain result from interviewing.

Define the learning question before selecting participants. “Why did qualified small teams stop after the pilot?” is more actionable than “Why do we lose?” Include wins and no-decisions when they can challenge your explanation. For example, an implementation issue reported in a loss may also appear in a win that had a different support arrangement.

Choose a sample you can describe honestly

Write down who was eligible, who was invited, who responded and which decisions the interviews cover. A convenient set of enthusiastic customers cannot describe all buyers. A low response rate may hide different experiences among people who declined.

Record	What to capture	Why it matters
Eligible decisions	Period, segment, outcome and inclusion rule	Defines the population you hoped to learn about
Invitations	Who was approached, permission status and date	Shows selection and access limits
Responses	Accepted, declined, unanswered or unavailable	Makes nonresponse visible
Interviews	Role, proximity to the decision and completed date	A user and a purchasing approver may know different parts
Exclusions	Reason a case was not pursued	Prevents convenient exclusions from disappearing

There is no magic interview count that makes a poorly selected sample representative. Report the raw counts. Use a small batch to generate and challenge hypotheses, and avoid converting a handful of comments into a precise market-wide percentage.

Invite the buyer without disguising a sales follow-up

Agree internally who may contact the account and who can view the notes. A conversation about a sensitive procurement decision may need a different interviewer from the seller. Explain whether you want to record the call, how the information will be used and whether participation is optional. Respect a decline.

Subject: Learning from your evaluation of [offer]

Hi [name],

We are reviewing how buyers experienced our evaluation process. Would you be willing to discuss your decision about [specific initiative]?

This is a learning conversation, not an attempt to reopen the sale. I would like to understand the alternatives you considered, the events that shaped the decision and what we could make clearer.

Participation is optional. Before we begin, we will agree how notes or any recording may be used.

If someone else is better placed to discuss the decision, please let me know.

Do not promise anonymity you cannot maintain. If an incentive is proposed, obtain the relevant organizational approval and follow the participant's policies. Never make a benefit contingent on favorable feedback.

A flexible interview guide

Use the following topics as a route through the conversation, not a questionnaire to race through. Ask for an example when the answer is abstract. Follow the buyer's sequence before introducing your own theories.

1. The starting situation: What was happening when you first considered changing the way this work was done?
2. The existing alternative: What did you use before, and what was acceptable or difficult about it?
3. The real choice: Which options did you seriously consider, including doing nothing?
4. The timeline: Which events changed your view as the evaluation progressed?
5. The people: Who contributed information or had to approve the decision? What did each person need to resolve?
6. The evidence: What did you see or test that made an option feel more or less workable?
7. The tradeoff: What did you accept or give up when you chose that direction?
8. The reflection: What would have made the evaluation easier to understand or complete?

Replace “Was our price too high?” with a neutral request to explain the tradeoffs. If price emerges, learn what it was compared with and how it interacted with perceived value, implementation effort or risk. Do not argue with a buyer's account to protect your preferred conclusion.

Worked example: “price” was not the whole story

Illustrative case: A fictional software company has marked an opportunity lost because of price. In an invented interview, the operations lead explains that their team could not identify who would own the rollout. A lower-priced option was also rejected. The company postponed the project and kept its spreadsheet. This case is a teaching example, not a report of Finta customer research.

Decision event	Source observation	What remains unknown
Initial interest	Operations lead wanted fewer manual reporting steps	Whether leadership had agreed the project was a priority
Pilot discussion	No internal rollout owner had accepted the work	Who could have authorized that allocation
Alternative comparison	Buyer says a cheaper option was also rejected	How other participants weighed the alternatives
Final decision	Buyer reports keeping the spreadsheet and postponing the project	Whether a later budget cycle will change the decision

The evidence challenges “price alone caused the loss.” It does not prove “all losses are caused by implementation.” One useful next test is to ask future evaluators who would own rollout and to make implementation responsibilities explicit earlier.

Copy the evidence and coding worksheet

Case
Case ID: [pseudonymous identifier]
Outcome: [won, lost, no decision or other]
Decision date: [actual date]
Segment: [segment]
Inclusion reason: [why this decision is in the sample]
Interviewee role: [role]
Proximity to the decision: [what the interviewee directly knows]
Permission and recording limits: [restrictions]
Invitation date: [actual date]
Response date: [actual date or no response]
Interview date: [actual date or not interviewed]

Decision timeline
Repeat for each event.
Event: [event]
Buyer observation: [specific account]
Permitted evidence: [note reference]
Unknowns: [open questions]

Coding record
Observation: [what was said or observed, without embellishment]
Source: [case, role and note or transcript location]
Theme: [working label]
Interpretation: [separate team hypothesis]
Contradicting evidence: [case or fact that challenges the hypothesis]
Confidence: [reason for confidence]
Limits: [scope, missing views or other caveats]
Next test: [action that could confirm or challenge the interpretation]
Owner: [person]
Review: [date or trigger]

Sample receipt
Eligible decisions: [count and scope]
Invited: [count]
Responded: [count]
Interviewed: [count]
Selection and nonresponse limits: [known limitations]

Example coding field	Completed fictional entry
Observation	Operations lead reports that no rollout owner accepted the project
Theme	Implementation ownership
Interpretation	Unclear ownership may have made the purchase feel unworkable
Contradiction to seek	Comparable wins without an initially named owner; another decision-maker's account
Confidence	One participant's recollection; no basis for a company-wide loss-rate estimate
Next test	Ask about an accountable rollout owner in future evaluations and inspect what happens

Turn a finding into a bounded decision

Review the evidence with the people who can change the process. Separate a product gap from unclear messaging, an unsuitable buyer, a poor evaluation process and a project with no decision. A quote can help explain an experience; it cannot establish how prevalent that experience is.

For each proposed action, record the mechanism you expect to change and the evidence that would make you reconsider. If the team proposes an implementation brief, check whether buyers can name an owner and understand the work after reading it. Do not claim revenue lift simply because the next deal closes.

Preserve disagreement. If procurement describes budget constraints while an end user describes missing functionality, those views may both matter. Do not flatten them into whichever label makes the dashboard easiest to sort.

Ask Aurora, Claude or Codex to challenge your interpretation

Task
Act as a skeptical research assistant. Review the supplied win-loss evidence without turning a buyer account into an unsupported conclusion.

Tool: [Aurora AI in Finta, Claude or Codex]

Inputs
Approved notes and source references: [paste permitted evidence]
Sample receipt: [eligible, invited, responded and interviewed counts, if available]
Permission and recording limits: [paste restrictions]

Output
Separate observations, sources, interpretations and unknowns. Identify leading questions, conflicting accounts and unsupported causal claims. For each useful hypothesis, suggest an alternative explanation and one small test that could challenge it.

Report the supplied eligible, invited, responded and interviewed counts. Flag missing counts rather than filling them in.

Constraints
Do not contact buyers, invent quotes or treat synthetic examples as research. Do not calculate a population loss rate from anecdotes or infer missing counts. Use only the supplied material. Prepare analysis for human review, without sending messages, accessing new private records or changing records.

Keep the learning loop separate from the sales chase

Keep permitted notes and relationship context connected so the next reviewer can understand the decision without repeating the interview. Finta can support organizing that context and preparing reviewable next steps; a model-generated summary is still a working interpretation that a person must compare with the source.

For questions before a buying decision, use customer discovery interviews when you are researching the problem itself. For continuing feedback from current customers, use a customer advisory program. Win-loss work has a narrower job: explaining a completed or stopped buying decision well enough to improve the next evaluation.

Informational note: This is general operational education, not legal, tax or accounting advice. Finta is not a law or accounting firm. Consult your attorney or accountant about privacy, recordings, incentives, confidentiality or related obligations.