Choose win-loss analysis software by the work that is failing, and make each vendor prove it

Start from the work that is failing

If late invitations, missed follow-ups, scattered responses and a report that took the quarter are not happening, the current process is working and there is nothing to buy. There is no number of losses at which a spreadsheet stops working.

Count the work instead of guessing at it. Take the closed deals from your last period, the minutes you spend per deal on the invitation, each reminder and reading the response, and the hours the last report took, and put the total against the hours the owner has. Every input comes from your own records or is marked unknown. An illustrative calculation, invented for this lesson: forty closed deals at twenty minutes of invitation and reminder work each is about thirteen hours, and a day of report writing brings the period to roughly three working days. Whether that is sustainable depends on who owns it and what else they carry.

Before buying, try the cheapest fix: an approved recipient list, a reusable set of neutral questions, a reminder calendar, one evidence sheet and a named reviewer. If maintaining that routine is the step that keeps breaking, evaluate software. If it holds, keep it.

Separate collecting buyer explanations from analysing evidence you already hold

Win-loss work has two distinct jobs. One collects new explanations from buyers, through interviews or surveys. The other analyses records you already hold: CRM fields, call transcripts, deal history. Cirrus Insight's guide to win-loss software sorts tools along that line, listing structured interviews, transcript analysis, forecasting intelligence and CRM workflow automation as separate approaches (Cirrus Insight, May 2026). A tool built for one job may do little for the other.

Some platforms combine buyer collection with competitive intelligence. Klue's win-loss page describes win-loss and competitive intelligence in one platform, with win-loss flowing into battlecards automatically (Klue win-loss). Clozd describes one of its interviewers running a thirty-minute conversation with the buyer, and labels its AI-led Flow mode beta and coming soon (Clozd). These are vendor descriptions read in September 2026, not observed performance. The category has no clean boundary, so ask which of the six operations below the product you are evaluating includes, and record an availability label such as beta or add-on as part of the answer.

Write six requirements before you open a vendor page

The six below are proposed criteria. Each pairs a requirement with something observable and a person who owns it. An export, a static survey form or a hand-picked sample can each be the right answer for a given team. What disqualifies an answer is that nobody can see how it works, trace a result to its source or say who is responsible.

Write your own version with the CRM, languages and participant restrictions that apply to you, and fix the study question first: a product that fits a quarterly loss review may not fit a launch retrospective. A requirement that reads "AI" or "integration" without an observable output is not finished. Analysing win-loss interviews shows what a traceable finding looks like; hold a vendor's report to the same standard.

Turn vendor pages into evidence and open questions with Claude

Keep the shortlist in a chat inside a Claude Project so the criteria stay constant across vendors. Projects are available on free accounts, capped at five, and project instructions apply to every chat in the project (Anthropic, what are Projects; managing Projects). Put the six requirements and your company constraints in the instructions, and add each captured page to project knowledge with its URL and date. With web search on, Claude can retrieve a page from a supplied URL (Anthropic, web search); paste an approved excerpt when a fetch fails. A plain chat with the same brief works for a one-off. This is a proposed method, not an evaluation we ran.

1. Evaluate one permitted source at a time

   Ask for the stated capability per requirement, one short exact passage, the URL and date, and what remains unanswered. Check: every capability has a supporting sentence, and a requirement the page does not address reads "not stated" rather than "not supported".

2. Keep the availability words

   Beta, add-on, coming soon and enterprise-only are part of the claim. Check: each label survives into your evidence sheet next to the capability it qualifies.

3. Open every passage yourself

   A passage you cannot find on the page is a defect in the evidence, whatever the cell says. Check: each quoted sentence exists at the URL and means what the sheet claims.

4. Turn the gaps into the test request

   Requirements no page answered become the questions for the vendor. Check: your request lists them, so the vendor prepares answers instead of a tour.

One prompt is worth keeping, because it sets the evidence boundary. It has not been tested against real vendor pages; treat it as a starting wording.

Using only this source, assess our six requirements. For each, give the stated capability, one short exact supporting passage, and what remains unverified. Preserve beta or add-on conditions. Write "not stated" when the source does not answer; do not turn that into "not supported".

An illustrative good output notes that the vendor describes CRM-triggered collection but names neither the configured stage nor the retry policy, so both go into the test. A bad one turns "Salesforce integration" into automatic interviews, reconciliation and approved battlecards, three capabilities inferred from one word.

Within this method, Claude assesses the statements you give it. A source you cannot supply stays unverified, and one failed fetch says nothing about other ways of reaching a page; respect the access controls. Nothing produced here replaces a product test, a security review or a reference call.

Test the claims and count what stays with you

A public claim yields a test request. Ask to see, on practice inputs the vendor agrees to: an eligible test deal, the invitation the buyer receives, the opt-out, a substantive response and a report whose finding you can trace to the answer behind it. Then ask for the failures: a deal with no contact, a duplicate record, a step that is rejected or fails. No real buyer is contacted for this. Mark a capability demonstrated only when you watched that behaviour.

Then compare the remaining work with the process you have. Estimate time from your own invitation, follow-up, review and maintenance experience, and add implementation, reward handling, source access, exports and renewal. What stays manual differs by product; make the vendor show those steps, then budget them with a named owner each.

The decision memo:

• The study question and the observed missed work that started the evaluation.
• Six requirements, each with an observable output and an owner.
• For each shortlisted product: the checked passages with URL and date, what was demonstrated, and what stays unknown.
• The remaining manual tasks and who owns each, beside the DIY estimate on the same inputs.
• Explicit non-fits, the decision (buy or keep the current process), and the date to refresh vendor facts before renewal.

Keep the memo and the excerpts where another evaluator can reconstruct why a product passed.

When Steve's survey workflow fits

Steve Win/Loss fits the narrow case where the failing work is scheduling and collection. When a deal closes won or lost in HubSpot or Salesforce, Steve invites the buyer after the delay you choose. The buyer answers an AI interview that asks follow-up questions. Steve sends up to three reminders, on days 3, 7 and 12, and an invitation expires after 30 days. When someone in the workspace clicks Generate Summary, Steve prepares a summary report from the responses available at that moment, with sections such as decision drivers, loss drivers, competitor insights and cross-question patterns.

The tradeoffs are the steps that stay with you. Your team approves each completed response before the buyer's gift card is sent. Each finding sits beside the buyer's own words, so check those words before quoting one; the report does not compare those answers with CRM loss reasons, which is a separate job, and nothing moves a finding into a battlecard or a message on its own. If your requirement is synchronous human research, automatic reconciliation, a report on every submission or unattended reward approval, it is not a fit, and a process that already meets your needs has nothing to buy. If scheduled collection with eligible reminders is the gap, see Steve Win/Loss.