Turn closed-lost notes and calls into a structured postmortem with Claude

---
name: lost-deal-postmortem
description: Turn closed-lost notes, call transcripts, and CRM activity timelines into a structured deal postmortem. Returns a categorized loss reason, a timeline of key decision moments, a competitor or alternative mentioned, what the seller could have done differently, and a confidence score for the analysis. Use after a deal closes lost — not as a substitute for live deal-desk review during an active opportunity.
---

# Lost-deal postmortem

## When to invoke

Invoke after a deal is marked closed-lost in Salesforce, once you have at least one of: a Gong call transcript from the final 30 days of the deal, closed-lost notes from the AE or SDR in the CRM, or a structured loss form already filled in. The skill ingests all available inputs, reconciles conflicts between them, and produces a postmortem ready to paste into Salesforce, a Gong call summary field, or a shared loss log.

Typical entry points:

- A Salesforce Flow that fires on `Stage = Closed Lost`, pulls the opportunity activity history and last N call transcript IDs, and posts them to this skill.
- A manual AE paste after a loss call, when they want a structured output before the next pipeline review.
- A RevOps batch run over last quarter's losses to produce a category distribution for the QBR deck.

Do NOT invoke this skill for:

- **Active deals.** Postmortems require a closed outcome. Running this mid-deal produces a speculative analysis that AEs misread as prescriptive coaching. Use the AE coaching skill for live deals.
- **Losses with fewer than 3 timeline events in the last 30 days of the deal.** With too little signal, the skill returns `insufficient_data` rather than guessing. A single "closed-lost notes: budget" entry is not a postmortem — it is a one-field form. See the guard in Watch-outs.
- **Churned customers.** This skill covers sales-cycle losses, not post-sale churn. Use the churn-analysis skill for post-sale outcomes.

## Inputs

Required (at least one):

- `gong_transcript` — string or array of strings. Raw Gong call transcript text or structured transcript JSON for the relevant calls in the deal. Minimum useful input: a single transcript from a call in the last 30 days of the deal. Preferred: all calls from the final sales stage.
- `crm_notes` — string. Closed-lost notes, AE notes, SDR call notes, or any free-text activity history from Salesforce. Can be a concatenated dump.

Optional:

- `opportunity_id` — string. Salesforce opportunity ID. Used for the postmortem header and for the skill to emit a Salesforce-pasteable output.
- `deal_metadata` — object with fields: `account_name`, `deal_value_usd`, `close_date`, `stage_history` (array of `{stage, date}` pairs), `competitor_mentioned` (string or null), `loss_category` (string or null — from whatever form your team uses). All optional but each narrows ambiguity.
- `postmortem_config` — path to or inline contents of `references/1-postmortem-config.md`. Contains your team's loss category taxonomy, the minimum-event threshold, and the output fields required by your Salesforce layout. If omitted, the skill uses the defaults in that file.

## Reference files

Load these from `references/` before first run. The config file is the main calibration point — the defaults work but your team's category taxonomy matters more than the skill's.

- `references/1-postmortem-config.md` — loss category taxonomy, minimum timeline-event threshold, Salesforce field mapping, and hindsight-bias guard configuration. Replace the placeholder rows with your team's actual categories.
- `references/2-timeline-reconstruction-template.md` — the template the skill fills when assembling the event timeline. Edit the "Key moments" list if your team tracks different signals.
- `references/3-sample-output.md` — a literal example of the full postmortem the skill emits for a fictional deal. Use this when wiring the Salesforce writeback or the loss-log paste target.

## Method

The skill runs these steps in order. Earlier steps gate later steps.

### 1. Input validation and data-sufficiency check

Before any analysis, count the distinct timeline events recoverable from all inputs combined. A "timeline event" is a datable interaction or signal: a Gong call, a CRM note with a date, a stage change, a pricing email, a meeting booked or missed. If the total is fewer than `min_timeline_events` (default: 3, configurable in `references/1-postmortem-config.md`), return `result: insufficient_data` with the event count and the threshold. Do not produce a postmortem.

Why: a postmortem with one or two events is hindsight bias packaged as analysis. The skill surfacing `insufficient_data` is the correct behavior — it forces the AE or SDR to go back and log the calls they did not log. A mandatory minimum is the only reliable guard against the most common postmortem failure mode: a confident narrative built on a single field.

### 2. Timeline reconstruction

Extract all datable events from the inputs and sort them chronologically. For each event, record: date, event type (call / email / proposal / demo / stage change / competitor mention), source (Gong / CRM note / deal metadata), and a one-sentence summary of what happened.

Why explicit timeline construction before analysis: if the model jumps straight to loss reason, it anchors on the most emotionally salient event (usually the final call) and ignores earlier signals. The timeline forces the analysis to move forward in time, not backward from the conclusion.

### 3. Loss reason classification

Against your loss category taxonomy (from `references/1-postmortem-config.md`), classify the primary loss reason and up to two secondary reasons. For each reason:

- Name the category (e.g. `budget_freeze`, `competitor_win`, `champion_lost`, `timing_not_right`, `product_gap`, `price_too_high`, `no_decision`).
- Cite the specific event(s) in the timeline that support the classification — not inference.
- Flag any conflict between sources (e.g. AE notes say "budget" but the final Gong call mentions a competitor by name).

Why cite-over-infer: postmortems are used in QBR analysis and win/loss reporting. A fabricated or inferred loss reason that sounds plausible will pollute category distributions for quarters. The skill refuses to classify without a citation; if no event supports a category, it is not assigned.

### 4. Competitor and alternative identification

Identify any competitor, internal build alternative ("we'll build it ourselves"), or status-quo alternative ("we'll keep doing it manually") mentioned in any input. Return `null` if none are present — never infer a competitor from vague language like "we're evaluating other options."

### 5. Seller action review

Based on the timeline and classified loss reason, identify the specific moment (if any) where a different seller action might have changed the outcome. This is the highest-risk step for hindsight bias. The skill only names a seller action if: (a) the signal was present in the deal at the time, not just in retrospect, and (b) a comparable closed-won deal in the team's history would typically have taken that action. If neither condition holds, this field is left blank rather than invented.

### 6. Confidence scoring

Emit a confidence score from 1-5:

- 5 — multiple Gong transcripts + complete stage history + filled loss form. High signal.
- 4 — one Gong transcript + CRM notes. Adequate.
- 3 — CRM notes only, ≥ 5 timeline events. Borderline.
- 2 — CRM notes only, 3-4 timeline events. Low signal; treat analysis as directional.
- 1 — single call transcript with no CRM notes, or CRM notes with exactly 3 events.

### 7. Output assembly

Render the postmortem per the format in "Output format" below. Confidence score and data sources go in the header. Timeline, classification, competitor, seller action, and Salesforce-ready field dump go in the body.

## Output format

Literal markdown the skill emits for a single closed deal:

```markdown
# Postmortem — Acme Corp (SF-OPP-12345)

**Close date:** 2025-10-14
**Deal value:** $84,000
**Confidence:** 4 / 5
**Sources used:** Gong (2 calls), Salesforce notes (4 entries)

## Loss reason

**Primary:** competitor_win — Acme signed with Vendor X after a bake-off demo on 2025-10-09 (Gong call 2, 14:32). Champion confirmed "they had the feature we needed natively."
**Secondary:** product_gap — No native Slack integration; mentioned as friction in Gong call 1 (2025-09-28, 08:14).

## Competitor / alternative

Vendor X (named in Gong call 2, 2025-10-09).

## Timeline

| Date | Event | Source | Summary |
|---|---|---|---|
| 2025-08-12 | Stage: Qualification → Demo Set | Salesforce | Champion agreed to a discovery call. |
| 2025-09-03 | Call: Discovery | Gong | Identified Slack integration as a key requirement. |
| 2025-09-28 | Call: Technical demo | Gong | Champion asked about native Slack connector; AE deferred to roadmap. |
| 2025-10-07 | Stage: Proposal → Negotiation | Salesforce | MSA sent. |
| 2025-10-09 | Call: Final decision | Gong | Champion disclosed bake-off with Vendor X. Outcome went to Vendor X. |
| 2025-10-14 | Stage: Closed Lost | Salesforce | AE notes: "Lost to competitor on native integration." |

## Seller action review

At the 2025-09-28 demo, the Slack integration requirement was on the table. The AE deferred to roadmap without offering an interim workaround (e.g. Zapier connector + documented steps). A comparable won deal (Northwind, closed 2025-08-01) used this workaround successfully for 90 days until native was shipped. Surfacing it here would not have guaranteed the win but would have removed the objection from the final bake-off.

## Salesforce fields (paste-ready)

```
Loss_Reason__c: competitor_win
Loss_Reason_Secondary__c: product_gap
Competitor_Mentioned__c: Vendor X
Postmortem_Confidence__c: 4
Postmortem_Summary__c: Lost to Vendor X primarily on native Slack integration. Product gap was the deciding factor in the bake-off.
```

---

_Postmortem generated: 2025-10-15 | Inputs: Gong (2), SF notes (4) | Timeline events: 6_
```

## Watch-outs

- **Hindsight bias on thin timelines.** When a deal has only one or two logged events, any analysis is reverse-engineered from the outcome, not derived from the deal itself. Postmortems like this pollute QBR category data for quarters. **Guard:** the skill returns `insufficient_data` when the recoverable timeline has fewer than `min_timeline_events` (default: 3). Raising the threshold to 4 or 5 in `references/1-postmortem-config.md` tightens this further for teams whose AEs under-log.
- **Loss category inflation.** AEs under time pressure default to "budget" as the loss reason because it is the least self-implicating option. A model trained on sales data will replicate this bias if it infers rather than cites. **Guard:** the skill only assigns a category when it can cite a specific timeline event. If CRM notes say "budget" but a Gong transcript shows a competitor mentioned by name, the skill flags the conflict explicitly and promotes the cited category.
- **Fabricated seller counterfactuals.** The "what could have been done differently" section is the highest-risk section for plausible-sounding confabulation. A fabricated counterfactual that reads as coaching will be used — and trusted — by managers. **Guard:** the skill only names a seller action if the signal was present at the time (not only visible in retrospect) and if a comparable closed-won deal supports the action. If neither condition holds, the field is explicitly left blank and labeled `insufficient_data_for_seller_review`.
- **Conflicting source accounts.** AE notes and Gong transcripts disagree about 20-30% of the time in typical deals — not from dishonesty, but from recollection gaps and note-taking timing. A skill that silently picks one source is misleading. **Guard:** when sources conflict on a material point (loss reason, competitor identity, last key meeting outcome), the skill surfaces the conflict explicitly rather than reconciling it silently: "CRM notes: budget. Gong call 2: competitor named. Primary classification uses the Gong citation; flag for AE review."

# Postmortem config — TEMPLATE

> Replace this file's contents with your team's actual loss taxonomy and thresholds.
> The lost-deal-postmortem skill reads this file before every run. A blank or
> missing taxonomy causes the skill to fall back to the default categories below —
> which are generic and will not match your team's QBR reporting unless you align them.

## How the skill reads this file

- **Loss categories** — the skill maps every identified loss reason to one of these categories. Categories not in this list will not appear in outputs. If your Salesforce picklist uses different names, align this file to that picklist.
- **min_timeline_events** — the skill refuses to produce a postmortem when fewer than this many distinct datable events are recoverable from the inputs. Raise it to 4 or 5 if your AEs log well; keep it at 3 if they under-log and you'd rather have thin analyses than none.
- **Salesforce field mapping** — the skill emits a "Salesforce fields (paste-ready)" block at the end of every postmortem. Map each analysis output to the Salesforce API field name your team uses.

## Loss categories

| Category ID | Display label | When to use |
|---|---|---|
| competitor_win | Competitor win | Deal went to a named competitor confirmed in transcript or notes. |
| product_gap | Product gap | A specific feature or integration the buyer required was absent or on roadmap. |
| price_too_high | Price — too high | Price was the stated primary objection and no discount resolved it. |
| budget_freeze | Budget freeze | Budget was reallocated or frozen at the company level — not a price objection. |
| champion_lost | Champion left or moved | Primary internal champion changed role, left the company, or lost authority. |
| timing_not_right | Timing | Buyer deferred — project not prioritized, org in a freeze, or fiscal cycle misaligned. |
| no_decision | No decision | Buyer evaluated but made no purchase decision — stayed with status quo. |
| build_internally | Build internally | Buyer chose to build the capability in-house rather than buy. |
| other | Other | Loss reason does not fit any above category. Requires a free-text note. |

## Minimum timeline events

```
min_timeline_events: 3
```

Raise to 4 or 5 for teams that log consistently. The skill returns `insufficient_data` (rather than producing a thin analysis) when the event count falls below this threshold.

## Salesforce field mapping

Map the skill's output fields to your Salesforce API field names. The skill emits the paste-ready block using these names.

| Skill output field | Salesforce API field name |
|---|---|
| primary_loss_reason | Loss_Reason__c |
| secondary_loss_reason | Loss_Reason_Secondary__c |
| competitor_mentioned | Competitor_Mentioned__c |
| confidence_score | Postmortem_Confidence__c |
| postmortem_summary | Postmortem_Summary__c |

Replace the right-hand column values with your actual API field names if they differ.

## Last edited

{YYYY-MM-DD} — by {RevOps team member name}

# Timeline reconstruction template

> This template defines the event types the skill recognizes when reconstructing
> a deal timeline from Gong transcripts and Salesforce activity history.
> Add or remove rows to match what your team actually tracks.
> The skill maps raw input text to these event types before sorting chronologically.

## How the skill uses this file

- Each event type in the "Recognized events" table is a pattern the skill looks for in Gong transcripts and CRM notes when reconstructing the timeline.
- The "Key moments" list is the set of signals the skill flags as high-weight — these are the events most likely to carry a loss reason or decision signal. Adjust the list if your team tracks different signals.
- Events not matching any recognized type are bucketed as `other` with the raw text preserved.

## Recognized event types

| Event type | Source(s) | How the skill recognizes it |
|---|---|---|
| call_discovery | Gong | Call title or notes contain "discovery", "intro", "first call", "qualification call". |
| call_demo | Gong | Call title or notes contain "demo", "product walk", "technical review", "walkthrough". |
| call_pricing | Gong | Call title or notes contain "pricing", "commercial", "proposal review", "negotiation". |
| call_final_decision | Gong | Call title or notes contain "final", "decision", "bake-off", "last call", "executive sponsor". |
| email_proposal | CRM / Gong | CRM note or Gong snippet references a proposal, MSA, SOW, or contract being sent. |
| stage_change | Salesforce | Stage field updated — captured in `stage_history` from deal metadata. |
| competitor_mention | Gong / CRM | Competitor name or phrase "evaluating other options", "bake-off", "comparing vendors" appears. |
| champion_signal | Gong / CRM | Notes reference internal champion role change, departure, or loss of authority. |
| stall_signal | Gong / CRM | Multi-week gap with no activity, or note containing "going dark", "no response", "pushed". |
| budget_signal | Gong / CRM | Notes or transcript contain "budget freeze", "budget cycle", "no budget", "CFO approval". |
| other | Any | Any datable event not matching the above patterns. |

## Key moments (high-weight signals)

The skill treats these as the highest-weight moments when classifying loss reason:

1. The final scheduled call before closed-lost (typically `call_final_decision`).
2. Any `competitor_mention` event.
3. Any `champion_signal` event.
4. The first `stall_signal` — when the deal started going quiet.
5. Any `budget_signal` that appeared after the proposal was sent (pre-proposal budget signals are expected friction; post-proposal signals are a deal risk).

## Last edited

{YYYY-MM-DD} — by {RevOps team member name}

# Sample output — for Salesforce writeback and loss-log wiring

> A literal example of what the skill emits for a fictional closed-lost deal.
> Use this when building the Salesforce Flow writeback, a Gong call summary
> field mapper, or a shared loss-log paste target.

## Single-deal postmortem output

```markdown
# Postmortem — Acme Corp (SF-OPP-12345)

**Close date:** 2025-10-14
**Deal value:** $84,000
**Confidence:** 4 / 5
**Sources used:** Gong (2 calls), Salesforce notes (4 entries)

## Loss reason

**Primary:** competitor_win — Acme signed with Vendor X after a bake-off demo on 2025-10-09 (Gong call 2, 14:32). Champion confirmed "they had the feature we needed natively."
**Secondary:** product_gap — No native Slack integration; mentioned as a friction point in Gong call 1 (2025-09-28, 08:14) and referenced again in the final call.

## Competitor / alternative

Vendor X (named in Gong call 2, 2025-10-09). No other competitors or build-internally signals identified.

## Timeline

| Date | Event | Source | Summary |
|---|---|---|---|
| 2025-08-12 | stage_change: Qualification → Demo Set | Salesforce | Champion agreed to a discovery call after outbound sequence. |
| 2025-09-03 | call_discovery | Gong | Identified Slack integration as a key requirement for the champion's team. |
| 2025-09-28 | call_demo | Gong | Technical demo. Champion asked about native Slack connector; AE deferred to roadmap ("Q1 2026"). |
| 2025-10-07 | stage_change: Proposal → Negotiation | Salesforce | MSA sent. AE notes: "Commercial terms agreed in principle." |
| 2025-10-09 | call_final_decision + competitor_mention | Gong | Champion disclosed bake-off with Vendor X. Vendor X had native Slack integration. Decision went to Vendor X. |
| 2025-10-14 | stage_change: Closed Lost | Salesforce | AE notes: "Lost to competitor on native integration. Budget was not the issue." |

## Seller action review

At the 2025-09-28 demo, the Slack integration requirement was identified and logged. The AE deferred to the Q1 2026 roadmap without offering an interim workaround (Zapier connector with documented steps, which the Northwind deal used successfully for 90 days pre-GA). Surfacing the workaround would not have guaranteed the win — Vendor X had the native feature — but it would have removed the gap from the bake-off criteria. Signal was present at the time of the demo call; this is not a retrospective observation.

## Salesforce fields (paste-ready)

```
Loss_Reason__c: competitor_win
Loss_Reason_Secondary__c: product_gap
Competitor_Mentioned__c: Vendor X
Postmortem_Confidence__c: 4
Postmortem_Summary__c: Lost to Vendor X primarily on native Slack integration. Product gap was the deciding factor in the bake-off; price and budget were not cited as objections.
```

---

_Postmortem generated: 2025-10-15 | Inputs: Gong (2), SF notes (4) | Timeline events: 6_
```

## Insufficient-data output (example)

When fewer than `min_timeline_events` events are found:

```markdown
# Postmortem — Tailspin Toys (SF-OPP-67890)

**result:** insufficient_data
**Timeline events found:** 2 (threshold: 3)
**Sources checked:** Salesforce notes (1 entry), no Gong transcripts linked

Postmortem not generated. Recoverable timeline has 2 events, below the minimum of 3.
Log the missing calls or attach the Gong transcript IDs to this opportunity and re-run.

---

_Checked: 2025-10-15_
```

## Field contract for parsers

If you build a structured parser instead of consuming the markdown:

- `opportunity_id` — string
- `account_name` — string
- `close_date` — ISO 8601 date
- `deal_value_usd` — number or null
- `confidence` — integer 1-5
- `primary_loss_reason` — category ID string (from config taxonomy) or `insufficient_data`
- `secondary_loss_reason` — category ID string or null
- `competitor_mentioned` — string or null
- `timeline[]` — array of `{date, event_type, source, summary}`
- `seller_action_review` — string or `insufficient_data_for_seller_review`
- `salesforce_fields` — object with API-name keys matching config
- `result` — enum: `ok` / `insufficient_data`