agentleFS
prosyo-aiprosyo-ai/gtm-skill/skills/win-loss-analysis/SKILL.md

win-loss-analysis

Skill13 starsChanged 22 days agoMITView on GitHub

Use this skill when you want to learn why deals are won and lost: \"run a win-loss analysis\", \"why are we losing to competitor X\", \"analyse last quarter's closed deals\", \"prepare win-loss interviews\". Analyses closed-won and closed-lost deals and buyer interviews, separates stated reasons from real ones, finds patterns by segment, competitor, deal size and stage, and turns them into specific changes for targeting, messaging, product and sales process.

10 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 6 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this quarterly or after a run of losses.

    line 16
  2. Distinctive:

    Call notes, emails and, ideally, 5-10 buyer interviews.

    line 21
  3. Distinctive:

    MUST quantify before interpreting.

    line 66
  4. Distinctive:

    MUST treat stated reasons as hypotheses until evidence supports them.

    line 67
  5. Distinctive:

    NEVER single out individual reps in a team-wide report.

    line 68
  6. Distinctive:

    NEVER share interview quotes with identifying details without the buyer's permission.

    line 69

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Use this quarterly or after a run of losses. It replaces anecdotes ("we always lose on price") with patterns and specific changes.

Inputs

  • Closed-won and closed-lost deals for the period with stage lost, reason, competitor, amount, segment and cycle length.
  • Call notes, emails and, ideally, 5-10 buyer interviews.
  • Rep notes on why they think deals went the way they did.

The play

1. Quantify first

Win rate by segment, deal size, lead source, competitor, rep and stage lost. The stage where deals die says more than the reason field: losses after the demo are fit or value problems; losses after the proposal are price, champion or competitor problems.

2. Separate stated from real reasons

"Price" is the most common stated reason and often not the real one. Look for evidence: was the economic buyer engaged? Was value quantified? Did the champion go quiet? Real reasons usually fall into: no quantified value, wrong buyer, competitor better fit, poor timing, weak process, product gap.

3. Interview buyers

Short calls with won and lost buyers, run by someone other than the rep. Ask about their process and alternatives, not about the rep. A guide:

  • What problem were you trying to solve, and why then?
  • What alternatives did you consider, including doing nothing?
  • What mattered most in the decision?
  • Where did we fall short, or stand out?
  • What almost made you choose differently?

4. Find patterns

A pattern needs 3+ deals pointing the same way. Group into: targeting, messaging, product, pricing, sales process, competition.

5. Turn patterns into changes

Each pattern gets one recommended change, an owner and how to measure it next quarter.

Output format

Period: <dates> | Deals: N won, N lost | Win rate: X% (vs X% last period)
Where we win: <segments, use cases, competitors>
Where we lose: <same, with the stage deals die>
Stated vs real reasons: <table>
Patterns (3+ deals each): <pattern - evidence - change - owner - metric>
Quick wins: <changes that can start next week>

What good looks like

  • Losses are explained with evidence from the deal, not from the reason picklist.
  • Wins are analysed too; knowing why you win tells you where to aim.
  • Recommendations name a team and a metric.
  • The common mistake is concluding "we need to be cheaper" from picklist data when the losses show no economic buyer was ever met.

Rules

  • MUST quantify before interpreting.
  • MUST treat stated reasons as hypotheses until evidence supports them.
  • NEVER single out individual reps in a team-wide report; give rep-level findings privately to managers.
  • NEVER share interview quotes with identifying details without the buyer's permission.

Example prompts

  • "Here are 80 closed deals from last quarter. Run a win-loss analysis."
  • "Why do we keep losing to Acme in mid-market? Notes attached."
  • "Write a win-loss interview guide and a request email to lost buyers."

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.