Atul Singh logoAtul Singh
← Back to prompts
RevOpsRevOps Analystbeginner 10 min saved

Win/Loss Reason Insight Extractor

Turn raw win/loss reasons into concise, evidence-based RevOps insights.

Customise & copy

Add the context you have. The prompt updates as you work.

Paste the win/loss interview summary or reason text exactly as received.

Select the known outcome if available; do not use it to override the reason text.

Optional context such as industry, segment, product, or deal stage. Leave blank when unavailable.

Live prompt

3 fields
Extract structured win/loss insights from the provided reason text. Use the deal outcome and business context only as supplemental context; do not infer facts that are not supported by the raw text. Return exactly one valid JSON object with exactly these four fields: "core_reason" (string: concise primary reason), "why_it_happened" (string: evidence-based explanation), "repeatability" (string: one of "repeatable", "one-off", or "unclear"), and "playbook_update_needed" (boolean: true only when the text explicitly indicates a process, messaging, product, or playbook change is needed; otherwise false). If a detail is absent, use "Not stated in source." Do not add fields, commentary, markdown, or conversational filler. Raw reason text: {{raw_reason_text}} Deal outcome: Unknown Business context: {{business_context}}

Proof before you use it

A real example

Tested on gpt-5.6-luna on 2026-09-10

{
  "deal_outcome": "Won",
  "raw_reason_text": "The regional hospital renewed with us because the implementation team completed the pilot in three weeks and trained the nursing managers before launch. The buyer specifically said the onboarding plan reduced operational risk and should be used in future hospital proposals.",
  "business_context": "Healthcare services; implementation-led expansion; account executive reviewing a senior buyer's win interview."
}

A small ritual that works

How to use it

  1. 01Paste the raw win/loss reason text.
  2. 02Select the deal outcome if known.
  3. 03Add optional business context.
  4. 04Review the returned four-field JSON object.

Why it works

The prompt gives the model a narrow analytical task, a clearly defined four-field structure, and explicit rules for handling uncertainty. It prioritizes the raw reason text while limiting deal outcome and business context to supplemental context, which helps keep the analysis tied to available evidence. The permitted values for repeatability and the explicit condition for playbook_update_needed also make those judgments more consistent and easier to consume downstream. Strict JSON requirements and additional-field restrictions support machine-readable use.

Where it fails

The prompt cannot establish causes, repeatability, or required changes when the raw reason text does not provide enough supporting detail. Its instruction to avoid unsupported inference appropriately limits what can be concluded, but that also means vague, incomplete, or highly subjective source text may lead to fields containing "Not stated in source." The separate schema-formatting instructions may also create ambiguity because the analytical task requests one four-field JSON object while the enclosing instructions request a different wrapper structure.

Customisation tips

Adapt the four field definitions to match the decisions the analysis will support. If repeatability requires a specific evidence threshold, define that threshold directly in the prompt. Add permitted categories only when downstream users need distinctions beyond repeatable, one-off, and unclear. If business context should influence interpretation more strongly, specify which context signals are relevant and require the model to label them separately from evidence in the raw reason text. For reliable integration, choose one final JSON shape and keep the task instructions, schema, and required fields aligned.

Watch-outs

  • The raw reason text is the primary evidence source; supplemental context should not override it.
  • The playbook_update_needed field is intentionally conservative and should be true only when the source explicitly calls for a process, messaging, product, or playbook change.
  • The phrase "Not stated in source." is a deliberate fallback for absent details, not an invitation to fill gaps with assumptions.
  • Strict JSON constraints require valid quoting, no extra commentary, and no fields outside the defined structure.

Works in

Win/loss interviewsCRM analysisRevOps reportingDeal retrospectives

Was this useful?

Submit your variation

If your version helps, it may be published with your name and a link back to you.

Want to make AI useful across your team? Explore Atul's training.