Win Win Loss Review

---
name: win-win-loss-review
description: Writes a Win/Loss Review for deals you won or lost, with expected versus actual per deal, what to keep and change, questions to ask the client with their agreement, and patterns across recent deals. Use for "run win-win-loss-review", "win loss review", "why did I lose that pitch", "we went another way", "debrief a lost deal", "what did we do right on that win", "lessons from my last proposals", "ask a client why they said no", part of the Claude Guide for Finding Clients Pack by Polar Bear.
---

# Win/Loss Review

## When To Use
You lost a pitch and the only feedback was "we went another way". Or you won and cannot say why. Use this within a few weeks of a decision, while you still remember, to answer: what did I expect, what happened, and what do I keep or change next time?

## When Not To Use
If the deal is still open, run Pipeline Review. If the client has just raised a concern and you want to answer it now, run Objection Response.

## Inputs
- For each decided deal: what you proposed, the dates, the outcome and anything the client said
- Your notes, the proposal and the email thread
- Whether you can ask the client for a short conversation
If you have none of this, I start from what you remember of one deal and mark every client reason as "our view, not confirmed".

## Approach
The review follows the four questions of the After Action Review, from USAID's 2006 technical guidance, built on US Army practice: what was expected to happen, what actually happened, what went well and why, what can be improved and how. The guidance is clear that a review is not a critique or a complaint session, and that matters here: a lost deal invites blaming the buyer or a colleague, and blame teaches nothing. The client's reasons are the part most often guessed; a guess written as fact will steer every next proposal wrong.

## Workflow
1. Ask at most three questions: which deals to review, what the client said when they decided, and whether you can ask them for a short conversation.
2. For each deal, answer the first two questions in order. Expected: the outcome, the timing and why you believed it then. Actual: what happened, with dates. Keep them separate; writing the lesson before the facts is the commonest slip.
3. Work out why the difference, as a sequence of decisions: who you spoke to, what you learned in discovery, how the proposal was framed, how follow-up went. Decisions and sequence only, never the client's or a colleague's character.
4. The client's side: draft 3 to 5 short, open questions and a request that makes no easy to say. You ask, only with the client's agreement. Without an answer, mark each client reason "our view, not confirmed".
5. Keep and change: at most three of each, each tied to a habit or a skill you will use next time (for example, a firmer discovery step, a walk-through before the proposal goes out).
6. Patterns: look across deals only when there are several. With one or two, write "no pattern yet" and leave it.

## Output Format
```markdown
# Win/Loss Review
Period: [dates] · Deals reviewed: [count]
## [Deal] · [won / lost] · [decision date]
| Expected | What happened | Why the difference |
|---|---|---|
| [what we expected] | [what happened] | [decision or step] |
What went well and why: [answer]
What to improve and how: [answer]
Client's view: [their words, confirmed] or [our view, not confirmed]
## Questions for the client (asked with their agreement)
1. [open question]
## Keep (at most three)
- [habit] · next used in [skill or step]
## Change (at most three)
- [habit] · next used in [skill or step]
## Patterns across deals
[pattern, or "no pattern yet"]
## Decision
[Your name] decides by [date] whether to ask the client, and which one change to try on the next proposal.
```

## Done When
- Each deal has expected and actual written separately, with dates
- Every client reason is confirmed in their words or marked as your view
- Keep and change hold three items each at most
- Patterns appear only when there are enough deals to show one

## Quality Bar
- No assessment of the buyer or of anyone on your team
- Feedback is asked for only with the client's agreement, and a no is respected
- Lessons are tied to something you will do differently, not a general principle
- The client's reasons are theirs to give; anything not confirmed is marked as your view.

## Next
Run win-past-client-list (Past Client Reconnect List) to turn the lessons and the won clients into reconnects.

## 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).