post-loss-review

---
name: post-loss-review
description: Turns a lost deal into the buyer's real reason for saying no, by testing the recorded reason and writing a 30-minute buyer interview plus the request email. Use after any closed-lost deal.
---

# Learn the real reason you lost, not the polite one

The buyer's own reasons, in their words, instead of the one line the CRM guessed.

## Claude does

1. Asks for: the deal facts, the closed-lost reason as recorded, the last three emails or call notes, the buyer contact and role, and the sender's name. Will not run on the recorded reason alone.
2. Labels that reason **outcome** or **reason**. Clozd found 44% of CRM closed-lost reasons are outcomes. "Went with a competitor", "no budget", "no decision" say what happened, never why.
3. Splits the file into evidenced and assumed. A named competitor is marked unverified: Clozd found CRM competitor data wrong in nearly 7 of 10 deals.
4. Writes one evidenced hypothesis on status quo versus indecision. JOLT: 40% to 60% of losses go to indecision, 56% of those to fear of getting it wrong.
5. Builds a 30-minute interview guide ordered overall decision, product, pricing, sales process, competitor. Clozd sets 30 minutes because asking longer lowers response rates.
6. Asks for four to five factors. The average buyer names four to five; the CRM records one.
7. Drafts the request email in your named sender, no pitch, no attempt to reopen.
8. Refuses to write a reason the buyer has not given, or to fill a field from your side.

## Then Codex does

Codex takes the mechanical half: expanding the five blocks into neutral, non-leading questions, laying them out in a fixed template, and producing a CRM-ready loss record with separate outcome and reason fields plus four to five factor slots. Repetitive formatting that scales across a batch of losses.

```
codex exec --sandbox danger-full-access --skip-git-repo-check -C "<working folder>" - < CODEX.md
```

Claude fills these in first: {DEAL_FACTS}, {RECORDED_REASON}, {HYPOTHESIS}, {BUYER_CONTACT}, {SENDER_NAME}.

## Claude checks

1. Every question open and non-leading. One naming the suspected reason first is rejected: it buys the polite answer.
2. The guide fits 30 minutes. Count and cut.
3. Overall decision comes before product, pricing, process and competitor.
4. Separate outcome and reason fields, four to five factor slots, never one.
5. Competitor marked unverified until the buyer says it.
6. No urgency, discount or re-pitch. Pushing urgency backfired 84% of the time in the JOLT data.
7. Sender name present and correct.

Fails a check: send back once with the offending line quoted. Fails twice: Claude rewrites it.

## Rules

- Never keep your own version as the answer. Buyer and seller reasons agreed only 15% of the time across 1,000 losses.
- Never record a single reason.
- Never use the review to sell, discount or reopen.
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.

## If Codex is not installed

Claude writes the question set and loss record itself and says it did both halves.

## Built from

- Clozd, 1,000 closed-lost deals checked against buyer interviews, https://www.clozd.com/blog/5-lies-your-crm-is-telling-you-about-your-buyers
- The JOLT Effect, Dixon and McKenna, https://www.jolteffect.com/blog/what-is-the-jolt-effect
- louisblythe/Sales-Skills, 143 stars via api.github.com, https://github.com/louisblythe/Sales-Skills

# Learn the real reason you lost - Codex task

You are formatting a win/loss review for one lost B2B deal. You have no memory of the earlier conversation, so work only from what is below.

## You are given

- {DEAL_FACTS}: company, deal size, dates, stages reached, people involved on both sides.
- {RECORDED_REASON}: the closed-lost reason exactly as it sits in the CRM, plus a label saying whether it is an outcome or a reason.
- {HYPOTHESIS}: one line on whether this looks like a preference for the status quo or indecision driven by fear of getting it wrong, with the evidence behind it.
- {BUYER_CONTACT}: name and job title of the person to interview.
- {SENDER_NAME}: the person whose name the request email goes out in.

## Produce

Three files in the working folder.

1. `interview-guide.md` - a 30-minute buyer interview, five blocks in this exact order: Overall decision, Product, Pricing, Sales process, Competitor. Four to six questions per block, 22 to 26 questions in total. Every question open and neutral. Include one closing question asking the buyer to name the four to five factors that most affected the decision and rank them. Put a minutes budget beside each block heading.
2. `loss-record.md` - a table with these rows and nothing else: Outcome (what happened), Reason (why, buyer's words), Factor 1 to Factor 5, Competitor (marked UNVERIFIED until confirmed by the buyer), Indecision or status quo, Evidence source, Interview date, Interviewer. Leave any value the buyer has not given as `NOT STATED`.
3. `request-email.md` - under 120 words, signed by {SENDER_NAME}, asking {BUYER_CONTACT} for 30 minutes to understand the decision. State plainly that nothing will be sold and the deal will not be reopened.

## Rules

- Never write a leading question. A question that names a suspected reason first buys the polite answer, not the real one.
- Never merge outcome and reason into one field.
- Never invent a fact, a number, a quote or a competitor name. `NOT STATED` is the correct output for anything missing.
- No urgency, no deadline, no discount, no re-pitch anywhere, including the email.
- Do not ask for more than 30 minutes.
- British English throughout. No em dash characters.
- Public information only.

## Return

Print, in this order: the three file paths written; the total question count and the per-block counts; the number of `NOT STATED` fields left in the loss record; the word count of the email; and a one-line confirmation that no question names a suspected reason and no competitor is asserted as fact.