Revenue decision guide · Closed-lost analysis
Closed-lost analysis that changes what happens next
Connect the recorded loss reason to the earlier conditions, decisions and actions that preceded the final outcome.
The operating question
The final loss reason is often the last event, not the first cause.
The opportunity is marked Closed Lost at 4:40 on a Friday. The required field offers eleven reasons. The Seller chooses Price, adds a short note and moves on to the next quarter.
Price is plausible. The buyer did ask for a reduction. It's also the last visible event in a deal whose business case never became urgent, whose main contact could not reach the decision group and whose security requirement appeared six weeks after the proposed close date. By the time the dropdown appears, the person completing it is working backwards from the ending.
At the QBR, Price becomes a count in a chart. Product hears that discounts are the problem. Enablement hears nothing about the business case. Leadership never sees the point when the deal may have stopped being winnable.
A better taxonomy improves consistency, not objectivity
A well-designed loss taxonomy is useful. It stops every variation of price, budget and commercial terms becoming a separate category. It makes reporting cleaner and gives the team a shared language.
It doesn't change who records the reason, when they record it or what evidence they can see. More codes chosen after the outcome by the same person can create a more precise-looking version of the same hindsight problem.
Ask when the deal stopped being winnable
“Why did we lose?” invites one explanation. “When did the deal stop being winnable?” forces the team to reconstruct the sequence.
The answer may be a date weeks before Closed Lost. It may also be that the deal remained winnable and the final commercial decision genuinely changed the outcome. The point isn't to replace one easy answer with another. It's to inspect what was visible, what the team did and what happened next.
Separate outcome, label and explanation
Closed Lost is an outcome. Price, competition and timing are labels. The explanation is the evidence and sequence behind the label, including conditions that contributed, decisions taken and actions completed or missed.
Keep the recorded code because customers need consistent reporting. Add the author, timing and explanation. Then connect earlier deal events without pretending one of them caused the loss on its own.
Route the learning to somebody who can use it
A required capability that isn't on the near-term roadmap belongs with Product and may require the team to qualify out. A capability gap in the sales team belongs with Enablement. A weak business case belongs with the way value is sold. External timing may have no internal owner, and the honest action is to learn it rather than invent one.
This is where loss analysis becomes useful. The output isn't a better slide. It's a named decision about what to change, what not to change and who owns the work.
Where loss analysis goes wrong
Don't publish a hidden internal taxonomy as though it were a proven set of causes. Protected conditions, thresholds and causal mappings don't belong on a customer-facing page. Public explanation should remain many-to-one and open to correction.
Don't use loss review to prosecute the Seller. The record should show what was knowable at the time, where judgment was reasonable and where material evidence was ignored. That distinction is necessary for fair coaching and useful learning.
A note on evidence
PROOF has no customer outcome study proving that a particular condition causes a loss. This page doesn't make that claim.
The defensible value is the record itself: keeping earlier conditions, evidence, decisions and actions attached to the eventual outcome lets the organization test explanations instead of selecting one from memory.
How PROOF approaches it
Keep the evidence, decision and action connected.
PROOF keeps the source, timing and accountable decision together so the team can act while the outcome can still change and learn from what happened afterwards.
See the working product