Win Loss Analysis Prompts for Competitive Deals

The artefact this job almost always produces is a list: five or six reasons, in order, sometimes with counts beside them. It circulates further than anything else competitive intelligence makes, and it is read as a description of why buyers choose somebody else.

It is a description of the write-ups. Between a deal ending and a line appearing in that list, three filters have run. Somebody decided the deal was worth writing up. Somebody asked questions in their own words, which shaped what got answered. And somebody chose which sentence in the answer was the reason. A model reading the corpus sees the output of all three and none of the three themselves.

The filter that matters most is the first, because its effect is invisible. Deals nobody wrote up are not under-represented in the list, they are absent from it, and the deals least likely to produce a write-up are the ones that faded rather than ended. So the reason that never appears is often the most common thing that happens.

Four inputs, and two of them are not documents. The code list and the denominator are numbers and definitions you bring to the run, and leaving either out is what turns this from an analysis into a summary.

Put the denominator in the brief rather than in your head. An output that opens “across 19 write-ups, from 64 deals closed against this competitor” is arguable in a way that the same output without those numbers simply is not, and it takes one sentence to arrange.

Four passes, and they are deliberately not one pass. Asking for the coding and the ranking together lets the ranking anchor the coding, because a model that has already decided price is the headline has a reason to read the next ambiguous sentence as being about price.

Almost nobody runs the second pass, and it repays the twenty minutes faster than anything else here. Running the same corpus cold, in a fresh conversation, and diffing the two codings that tells you which of your reason codes two careful readers would disagree about. Those codes are where a year of counting quietly goes wrong, and no amount of re-running the analysis finds them.

We asked a model to rank why deals go to a real competitor, supplying nothing, and read what came back against that competitor’s published pricing.

An ordered list is a number in disguise

Nothing in that answer would be challenged in a meeting. Each reason is real, each is expressed carefully, and there is not a statistic anywhere in it to argue with. That is the whole difficulty. A list numbered one to five asserts that the first outranks the second, which is a claim about relative frequency, and it arrives in a form nobody knows how to question because it never printed a figure.

The same shape survives when the corpus is real. Nineteen write-ups produce a ranked list just as readily as nothing does, and the list looks identical. The difference is entirely in whether the output says how many deals sit behind each position and how many deals it never saw, which is why both of those are required inputs above rather than nice additions.

There is no grounded counterpart to the run above, and the reason is worth stating plainly rather than leaving as a gap. The grounded version of this job reads your own customers talking about their own companies, which is material nobody can publish. Every other page in this library shows the same question answered twice; this one cannot, and any page in this format that shows you a tidy win/loss corpus has written it.

Ask for themes and a model will give you six, well chosen, fitting the corpus neatly. Ask again next quarter and it will give you six again, also well chosen, also fitting, and not the same six. Both outputs are good. Together they are worth nothing, because a trend needs two measurements on one scale.

A coding scheme is infrastructure rather than analysis. It gets agreed once, written down, and changed deliberately and rarely, which is the discipline a coded archive has always needed. What changes when a model does the coding is only the speed, and speed is exactly what makes the drift invisible: nobody re-reads a scheme that took four seconds to produce.

Read the unfitted pile before the counts

Which is why every prompt above insists on somewhere for the write-ups that do not fit, and forbids widening a code to absorb them. A closed scheme with an honest overflow tells you something a tidy one never will. Three deals that will not fit any existing reason is how a new competitor, a new objection or a changed buying process first appears in your own data, usually a quarter before anybody names it.

The quotes are the other thing to protect. A coded row with the buyer’s sentence attached can be handed to a sceptical sales leader; the same row with a paraphrase cannot survive a single “did they actually say that?”. Verbatim material also travels further than analysis does, and the passages worth pulling are the ones carrying a competitor’s argument back to you in a buyer’s own words, months after the deal, which is the raw material for a battlecard that argues with something real.

A synthesis describes deals that have already closed, which makes it the most backward looking artefact competitive intelligence produces. By the time thirty write-ups exist, the oldest is a year old, and the competitor in it has repriced, renamed something or shipped the capability the loss was about.

That is not an argument against doing it. It is an argument for reading the findings against a current picture of the competitor rather than on their own. A loss reason from March and a pricing page from March are one story; the same loss reason read in September against September’s pricing page is a different one, and only one of those two is the question your sales team is asking.

The output needs somewhere to live that is not a deck. A win/loss report holding the coded rows, the denominator and the quotes can be compared against the last one, and the comparison is the only way a set of reasons becomes a trend rather than a fresh opinion every quarter.

Flares tracks what competitors change and dates every change, so a set of loss reasons can be read beside what was true when each deal closed and what is true now. Why a specific buyer chose somebody else is not something any monitoring can recover, and asking them remains the only method that works.