acct-win-loss-review git:20261011.dce569cA

Immutable. This exact content never changes and is served at /api/v1/blob/c82279643774fa8c.

---
name: acct-win-loss-review
description: Writes a win/loss review of one deal, with the timeline and its sources, expected against actual, the customer's reasons only as they gave them or "not asked" with three neutral questions, what counted factor by factor and what you keep and change. Use for "run acct-win-loss-review", "win/loss review", "win-loss analysis", "why did we lose this deal", "deal post-mortem", "debrief a lost deal", "what did we do right on this win", "lessons from this deal", part of the Claude for Account Executives Pack by Polar Bear.
---

# Win/Loss Review

## When To Use
You lose a deal and nobody really knows why. People say "too expensive" or "the incumbent was too strong" without having asked the customer. Or you win and cannot say what did it. Run this within a few weeks of the decision. It answers: what really counted, according to the customer and the facts of the cycle, and what do you change for the next one?

## When Not To Use
To turn a won deal into proof for prospects, use Customer Proof Story: this review stays internal. For deals still open, use Pipeline Review or Deal Review Brief.

## Inputs
- The deal history in your CRM (dates, stages, amounts, decisions), your call notes, the proposal, the quote and the key exchanges.
- What the customer said about their decision, with the source, if they said it, and whether you can still ask them.
If you have none of this, I start from your memory of the cycle, marked "from memory", and mark the output as a first draft.

## Approach
The four questions of an after action review, a practice described here generically: what was expected, what happened, what went well and why, what to change and how. Two rules make it work in sales. The reasons for the decision belong to the customer: you ask for them, you do not suppose them. And you look at the work (criteria, proof, price, timing, competition), never at a person. A review that hunts for someone to blame teaches nothing and will never be done honestly again.

## Workflow
1. I ask at most three questions: was the deal won or lost and on what date, did the customer explain the decision and where, and can you still ask them.
2. I rebuild the timeline from the CRM and your notes: dates, stage changes, decisions, each with its source.
3. Expected against actual, kept apart: what you expected at each key point and why you believed it then, and what happened. The lesson comes after the facts, not before.
4. The customer's reasons: only what they said, quoted with the source. If they said nothing I write "not asked" and draft three neutral questions, which you send or ask by phone yourself, with a request that is easy to refuse and no attempt to reopen the sale.
5. What counted, factor by factor (decision criteria, proof you brought, price, timing, competition), each with a proof or the word "assumed".
6. Keep and change, three of each at most, worded about ways of working and arguments, never about a person on your team or a contact at the customer. I then propose the updates this suggests to your FAB Statements (a proof that was missing) and your Objection Register (an objection that appeared), for you to approve.

## Output Format
```markdown
# Win/Loss Review
Deal: [name] · Outcome: [won / lost] on [date] · Prepared by: [you]
## Timeline
| Date | Stage or decision | Source |
|---|---|---|
| [date] | [event] | [CRM / call notes of date] |
## Expected against actual
| Point in the cycle | Expected (and why) | What happened |
|---|---|---|
| [point] | [expectation] | [fact] |
## Reasons the customer gave
| Reason | Their words | Source |
|---|---|---|
| [reason or "not asked"] | "[only if written down]" | [source] |
Questions to ask the customer (if not asked): [three neutral questions]
## What counted
| Factor | Finding | Proof or "assumed" |
|---|---|---|
| [criteria / proof / price / timing / competition] | [finding] | [proof] |
## Keep and change
- Keep: [practice or argument] · Change: [practice or argument]
- Updates proposed: FAB Statements: [proof to add] · Objection Register: [objection to add]
## Decision
[Your name] decides by [date] whether to ask the customer, and which one change to carry into the next deal.
```

## Done When
- Every customer reason is quoted with its source, or marked "not asked" with the questions to put.
- Expected and actual are written separately, with dates, and every factor carries a proof or the word "assumed".
- No line in keep and change points at a person.

## Quality Bar
- I never deduce the reason for a loss from price or from the competitor: without the customer's word it reads "not asked".
- No blame for the seller, the team or a customer contact, even implied; the questions to the customer are neutral and a no is respected.
- The deal is reviewed, never a person; the customer's reasons are asked for, never supposed or invented.

## Next
Run acct-account-plan (Account Plan) to carry what you learned into the plan for this account or the next one like it.

## About the makers

This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).