Loss Review

---
name: loss-review
description: Audits a debrief call with a buyer who chose another option or no option, to see whether the rep learned the real reason the deal was lost in the buyer's own words, and what would reopen it. Use when the user asks to review a loss debrief or a lost-deal interview, wants to know why a deal was really lost, or wants to know whether a rep learned from a loss.
license: MIT
metadata:
  zime:category: deal-intelligence
  zime:dimension: intelligence
  zime:input-modes: transcript
---

# Loss-Review Audit

You are a sales-call auditor. Your goal is to tell a rep or manager whether a loss debrief captured the real reason, in the buyer's words, or only the rep's theory.

Audits a call held after a deal was lost. It is the call-level partner of `win-loss-brief`, which writes up one closed deal from a transcript or a CRM row. This skill grades how well the debrief call itself learned the reason.

## When to use this

- A manager wants to know whether a loss debrief taught the team anything.
- A rep finished a debrief with a lost buyer and wants an honest read on what was learned.
- Someone wants the loss reason in the buyer's words before it goes into the CRM.

## Before you start

- If `.agents/gtm-context.md` (or `.claude/gtm-context.md`) exists, read it
  first and don't ask for anything it already answers.
- Run this end to end in one pass. Don't stop to ask which call to use or
  how to read an ambiguous moment. Apply the rubric, decide, note the
  assumption once, and move on.
- If the call is not a debrief with a buyer who chose another option, say so in one line and score only the dimensions the call touches.
- If the transcript is cut off or a section is unclear, score what is there
  and mark the affected dimensions **Unclear** instead of guessing.

## Modes

### Transcript mode (`.txt`, `.vtt`, `.json`, `.md`)

```
claude "run loss-review on ./calls/call.txt"
```

1. Read the whole transcript before you score anything.
2. Score each of the 7 dimensions in `references/rubric.md` on its own.
3. Before each status, apply these tests:
   - Evidence is what the buyer said, in a line that is about that dimension. A claim that only the rep makes does not count. Never use one line for two dimensions.
   - When no line addresses a dimension, the status is Missed. Do not soften
     it to Partial because the call felt thorough elsewhere.
   - Partial needs a quotable line that names the dimension but stays vague.
     When you cannot quote that line, it is Missed.
   - Covered needs the specifics the rubric names, not a general statement.
   - Read each dimension's "does not count" line first.
4. Run the rubric's reads-well-too test before finalizing, in both directions.
5. Write the output in the exact shape under `## Output format`.

For every dimension, output:

- **Status**: Covered, Partial, or Missed
- **Evidence**: a direct quote or timestamp from the transcript. When you
  cannot point to a specific line, mark the dimension **Unclear**.
- **Note**: one line, only for Partial or Missed. It can end with the
  rubric's "strong call" move as one short question the rep can ask next time.

## Output format

7 dimensions, in the rubric's numbered order:

```
**2. Real reason in the buyer's words** — Covered
Evidence: Hannah: "mostly their ordering module already talks to our warehouse system. Yours needed a custom connector."

**6. Door left open honestly** — Partial
Evidence: Hannah: "Check back in the spring, after our rollout settles."
Note: A trigger is named but no date was agreed. Ask for a specific week and permission to call.
```

Then close with exactly one line:

> **Real reason, in the buyer's words:** [one sentence]. **Reopen condition:** [one sentence, or none stated].

No section recapping all 7 scores again after this line.

## Do not

- Don't score anything outside this skill's 7 dimensions. Other skills in
  this repo cover pain, qualification, and rapport.
- Don't blend the 7 dimensions into one score.
- Don't add a talk track or an email template unless the user asks.

## Related skills

- **`win-loss-brief`**: writes the brief on why one closed deal was won or lost.
- **`competitor-battlecard`**: turns a named rival from a call into a battlecard.
- **`competitive-positioning`**: audits how the rep handled the rival before the loss.

## Sample data

`assets/sample-transcript.txt` is a short synthetic call. Run the skill
against it first to see real output before you use your own file.

## What this does not do

No CRM connection, no API calls, no telemetry, no data retention beyond the
current session. It reads the file you point it at and nothing else.