Won Deal Icp Finder

Applies when the ICP on the slide was written before the revenue arrived. Produces a proven profile, derived from deals that closed, plus the search criteria to find more of them.

Most stated ICPs are aspirational

Teams write their ICP at the start, from the market they want. Then they close deals, and the deals quietly disagree — smaller, in an adjacent vertical, in a country nobody targeted. Nobody rewrites the slide, so prospecting keeps aiming at the market that never paid. This skill re-derives the profile from the ledger instead of the plan.

Select on money, not on stage names

The first move is picking which deals count, and it is where this play usually breaks.

The obvious approach — filter on a "Closed Won" stage — assumes a stage that a surprising number of pipelines don't have, or don't use consistently, or spell in another language. When it silently matches nothing, the fallback is worse: pull the most recent deals instead, which are the newest and emptiest ones, and the analysis runs on rows with no value in them.

Select on deal value being populated, over the last twelve months. A won signal, where one genuinely exists, is a filter you add on top — not the thing you rely on. Read the CRM's own conventions before pulling anything: which field actually holds value (the standard amount field is often abandoned in favour of a custom ARR or ACV one), and whether a won status exists at all. If you can't tell, ask one specific question and stop. Guessing here doesn't produce a slightly-off answer, it produces a confident answer about empty rows. See references/deal-data-extraction.md for the field-discovery sequence, the CSV fallback, and how to keep the pull bounded.

Do the arithmetic in code

Sums, revenue shares, concentration ratios, and frequency rankings across a hundred-odd deals are exactly the work a language model gets quietly and unfixably wrong — and a wrong ranking sends a team after the wrong accounts for a quarter.

scripts/analyze.py does the counting. It parses both European and US amount formats, applies the window, excludes lost deals always, detects a won signal when present, aggregates revenue per company, and returns segments and source rankings as JSON. Run it, then reason over what it returns. It refuses rather than improvises when it can't find a value field, a company, or any deal in the window — a refusal is a question for the user, not a problem to code around. references/analysis-engine.md covers the flags, the output schema, and how to read each block.

The judgment — which companies form a coherent archetype, whether a source ranking can be trusted, what to flag — is the part that stays yours.

Cluster on revenue, not on logos

Group the companies behind the top deals into two to four named archetypes, built by intersecting the revenue-dominant industry, size and geography segments: "mid-market FinTech in FR/DE", not "B2B in Europe". Each needs objective criteria a search can consume — one or two values per dimension, a typical deal size, and how many won companies fit.

Read revenue share, never deal count. Three large deals in one vertical beat twenty small ones in another, and counting logos rewards whichever segment is cheapest to sell to. Above roughly a quarter of revenue in a single account, you have a whale rather than a pattern — say so plainly instead of building an archetype around one customer.

Before promoting any segment to an archetype, count the distinct companies inside it. A segment can sit third on the revenue table and consist entirely of one customer who renewed; the table makes it look like a market and it isn't. Fewer than two companies means concentration to report, not a profile to search. Past four archetypes you are slicing noise; collapse the thin ones. The clustering rubric, the anti-pattern table and a worked example are in references/archetype-clustering.md.