The ICP Acceptance Gate: Buildable, Revise, or Not Yet an ICP

This standard is the check between the ICP workshop and the first account list. It is for founders selling their own product, account executives, SDR leads, and partnerships teams who have a written ideal customer profile (ICP: a description of the companies most likely to buy, succeed, and stay). Before building any list, they need to know whether it is specific, evidenced, and observable enough that two reps would pull the same companies from it. The standard gives seven pass/fail criteria, a repeatable test for each, and a verdict of Buildable, Revise, or Not Yet an ICP that a second grader would reach on the same document.

What the verdict means: Buildable, Revise, or Not Yet an ICP

An ICP spec is Buildable when it passes all seven criteria. It is Revise when its win/loss evidence holds but another criterion fails. It is Not Yet an ICP when the evidence is missing or two raters cannot agree on what it means. Every verdict lists the failed criteria and the fix for each, so the spec goes back to its owner as a to-do list rather than a debate.

These are the seven criteria. Each is graded pass or fail:

1. Observable. Every filter attribute names a public source, a field, and a taxonomy (classification scheme) or code list.
2. Discriminating. Every attribute cites counts from at least 30 closed deals showing it is common in good wins and rare in losses.
3. Disqualifiers explicit. Every exclusion is written as a field and a threshold.
4. Bounded. The spec states its match count, names the unit the count applies to, and the count falls inside the capacity band for that unit.
5. Covered. Every filter field carries a coverage rate measured on a sample.
6. Agreed. Two raters scoring the same balanced 20-account sample blind reach a Cohen's kappa of 0.61 or higher.
7. Owned. The spec has one named owner, a next refresh date, and a change log whose last entry is less than one quarter old.

Most published ICP advice explains how to write the document and offers sizing rules of thumb that seem to contradict each other. None of it grades the finished spec. So teams ship slide-deck ICPs like "mid-market companies with a modern sales culture" that every rep reads differently. Each criterion here has a test a second person can repeat, because the verdict should not depend on who runs it.

If two reps pull different companies from the same ICP, the team has a mood board, not a spec.

Criteria 1 and 2: is each attribute observable, and does it separate wins from losses?

An attribute belongs in the spec only if two things are true: a rep can see it in public records before first contact, and closed-deal counts show it is common in good wins and rare in losses. Passing one test is not enough. A visible trait that predicts nothing just inflates the list, and an invisible predictor cannot be filtered on.

Criterion 1: observable from public evidence

• What it proves: a rep who has never spoken to the account can judge fit from the same evidence the author used.
• The test: for each attribute, the spec names the source (public LinkedIn and Crunchbase records, the company's own site, or a business registry), the field, and the taxonomy. If any of the three is missing, the attribute fails.
• What it looks like when it lies: the field exists but describes the company wrongly.

Here is how visible each common attribute is:

• Headcount. Public employee counts depend on employees having profiles. In industries where few staff are on LinkedIn, expect the LinkedIn count to understate true company size by 20 to 40 percent.
• Industry. LinkedIn's Industry Codes V2 has 434 industries under 20 top-level sectors, up from 149 in the first version, and its IDs differ from NAICS codes. NAICS itself gives no guidance on companies made up of multiple establishments. The spec must name one taxonomy and the exact codes it accepts.
• Owning role. You can measure whether a named function exists at the account, such as a Head of RevOps or an SDR team. Refolk's figures for this are under criterion 5.
• Tech stack, funding stage, hiring signal. No public reliability figures exist for these fields. Treat their accuracy as unproven and check it yourself: take 25 accounts the filter returns and verify each against the company's own site or announcements before you trust the field.

An attribute with no public field, such as "values partnership" or "data-driven culture", fails criterion 1 unless the spec names a public proxy for it. Otherwise it moves to the discovery questions, where it belongs.

Criterion 2: discriminates won from lost

• What it proves: the attribute predicts deal success instead of just describing who happened to buy.
• The test: every attribute line cites counts from both sides, in the form "8 of 12 wins are sub-200, 5 of 7 losses are 500+". The underlying sample has at least 30 closed deals, won and lost. Any trait shared by fewer than about 30 closed deals is labelled a hypothesis and cannot be a hard filter.
• What it looks like when it lies: wins that churned are counted as wins, or a small sample makes a coincidence look like a pattern.

Sources disagree on the minimum sample:

• One treats a check of the last ten wins as the fastest reality check.
• Another sets a minimum of 20 closed-won and 20 closed-lost deals.
• One framework says fewer than 30 deals is noise.
• Another says quantitative pattern analysis is unreliable below 40 to 50 closed deals.
• A fifth pulls the last 50 to 100 deals.

I set the pass line at 30 because that is where two independent sources stop calling the result noise or a hypothesis. A ten-deal check is a sanity test, not validation. Compiling 30 deals takes 30 to 60 minutes.

A good spec usually ends up with 8 to 12 attributes that predict deal success. One common inclusion rule says an attribute present in 70 percent of wins goes into the template. That rule is only half the test: a trait found in 70 percent of wins and 70 percent of losses tells you nothing.

Re-label your wins before you count anything. In one illustrative worked example (the company may be fictional), retail won 9 of its 58 closed deals, but 5 of those 9 customers churned within a year. Counting only good wins, retail converts 4 of 58, or 7%. Without a churn flag, the discrimination test measures the wrong thing and the segment looks better than it is.

Put the two criteria together and every candidate attribute lands in one of four places:

How to write negative ICP disqualifiers that a filter can apply

A disqualifier passes criterion 3 only when it names a filterable field and a threshold, so a list builder can apply it without asking the author what they meant. The negative ICP (the explicit list of accounts not to pursue) is half the spec, and it is the half most often written as adjectives.

• What it proves: the author and the list builder exclude the same accounts.
• The test: rewrite each exclusion as a field, an operator, and a value. If you can't, it fails.
• What it looks like when it lies: the rule is a real field but the threshold is a guess. Base thresholds on your own loss and churn data and write the source next to the rule. The "twice the average churn rate" form is good because it says where its number comes from.

Write disqualifiers with customer success in the room, because they see churn the sales team never does. Disqualifiers also have to pass criteria 1 and 5. An exclusion on a field that is empty for some accounts silently lets those accounts through.

How to know if your ICP is too broad: the match-count bound

An ICP is too broad when its match count is bigger than the team can work in the unit that count measures. It is too narrow when the universe cannot feed the list. Criterion 4 passes when the spec states the count, names the unit, and the count sits inside the band for that unit and team size.

Sizing advice looks contradictory because it counts different things. A weekly touch budget, an open list per SDR, a monthly total, and a total universe are four different units. A number that makes sense in one is absurd in another.

The monthly figure comes from Trish Bertuzzi's The Sales Development Playbook. For the whole target list, published guidance scales with the team:

• 1 AE: about 10 to 15 accounts.
• 5 AEs: about 30 to 50 accounts, or 6 to 10 per rep with marketing support.
• 3 SDRs feeding a team: about 50 to 100 accounts.

The universe (every account that matches the spec) should be three to five times the final list, not twenty times. One sizing source warns against filters so tight that the universe drops below 800 accounts and treats 5,000 as the upper limit. Sizing takes about a day.

• What it proves: the spec can be worked by the team that will work it.
• The test: the spec contains a sizing line for each unit it uses, such as universe, working list, and per-SDR open accounts, and each number sits inside its band. A bare number with no unit fails.
• What it looks like when it lies: the count is understated, because of a single title string or a drifting headcount band (see the failure modes), so the spec looks tight while real matches go uncounted.

Getting the count is where teams usually lose the day, juggling filters across tools. In Refolk you can type the ICP as a plain-English request, see what comes back, and compare that count with the band before anyone builds a list.

Field coverage: will the filters find the accounts the spec describes?

Field coverage is the share of returned records where the field a rule depends on is filled in, correct, and as detailed as the rule needs. Criterion 5 passes when every filter field has a coverage rate measured on a sample of about 25 records, written next to the rule.

Refolk measured how common the roles that own an ICP are in its index of professional profiles. The results show that coverage changes from market to market.

Refolk's index has only 28 UK profiles with the literal title "Revenue Operations". A UK spec that requires the role will barely feed a list. Whether this reflects title conventions or a real shortage of the role is not established. Either way, a UK spec that depends on the role should list synonyms such as Sales Operations and count again.

The same 25-profile samples show two more ways coverage leaks:

• Off-target titles. In the US, 3 of 25 SDR matches (12%) were off target, including "Imvestor", a co-founder CEO, and "Strategic SDR". In the UK, 2 of 25 (8%) were Account Executive titles.

• Location granularity. 7 of 25 UK SDR profiles (28%) gave location at country level only, against 4 of 25 (16%) in the US. A city or region rule silently drops those people.

• What it proves: the filter returns the accounts the spec describes, and the team knows how many it misses.

• The test: for each filter field, pull about 25 records the rule returns. Count how many have the field filled in at the detail the rule needs, and how many are off target, then write both rates on the rule line. A field with no measured rate fails. A low rate does not fail on its own, but it must be written down so the team can accept the loss or add a fallback field.

• What it looks like when it lies: the sample came from one market and the spec covers two.

Counting off-target titles is tedious when the profiles are spread across tabs. In Refolk, one request returns the people with their titles and locations side by side, ready to count.

Blind two-rater agreement: the ICP scoring inter-rater test

Two reps who did not write the spec each score the same balanced sample of 20 accounts as fit or not fit, without talking to each other. Criterion 6 passes when Cohen's kappa is 0.61 or higher. Treat a pass on 20 accounts as provisional until 50 accounts are rated.

Cohen's kappa is the standard statistic for agreement between two raters. It is the share of accounts they agree on, corrected for the agreement they would reach by chance: kappa = (observed agreement - chance agreement) / (1 - chance agreement).

Twenty accounts is a small sample, and the numbers show how small. With chance agreement at 0.5, the standard error of kappa shrinks with sample size like this:

At 20 accounts, the confidence interval runs from "moderate" to "almost perfect". General guidance says to aim for at least 50 rated items, and a methods tutorial by Madadizadeh and Bahariniya sets a minimum of 50 to 100. So the policy has two stages:

1. Fail fast at 20. If kappa is below 0.61, the spec is ambiguous enough that a bigger sample won't rescue it. Fix the attributes behind the disagreements first.
2. Confirm at 50. A pass at 20 makes the spec provisionally Buildable. Rate 30 more accounts before scaling outreach.

Balance the sample. If 18 of 20 accounts are obvious non-fits, the raters agree on almost everything and kappa still comes out low. This is the kappa paradox, and it happens when one category dominates. Draw roughly as many likely fits as likely non-fits from the universe, and include some borderline accounts on purpose.

After scoring, go through every disagreement with both raters. Each one points to a specific attribute line that reads two ways, which makes it the most useful output of the test.

You are rating [20] accounts against the attached ICP spec, version [n].

Rules:
1. Rate alone. Do not discuss accounts with the other rater or the spec's author until both sheets are in.
2. Use only the sources named in the spec. Do not use CRM history or anything you remember from past calls.
3. Mark each account FIT or NOT FIT. There is no "maybe".
4. For every NOT FIT, cite the spec line that excluded it. For every FIT, name the attribute that was hardest to verify.
5. If a field the spec needs is missing, rate on the evidence available and write "field missing: [field]".

Return one row per account:
Account | FIT / NOT FIT | Spec line cited | Field missing | Minutes spent

Due: [date]

Running the gate step by step

The gate runs as eight steps, from the closed-deal export to a recorded verdict. On clean CRM data, compiling 30 deals takes 30 to 60 minutes, re-labelling takes 3 to 4 hours, sizing takes about a day, and validation with sales takes about a week.

Published methods disagree on order. Some build from the top 20 customers first and test against wins and losses afterwards. Others include losses from the first export. I include losses from the start, because criterion 2 cannot be graded without them and there is no reason to export twice.

How the gate goes wrong: failure modes and false positives

Most false passes come from a test that ran on too little data or on fields that quietly mean different things to different people. Each failure mode below has a check that a grader can apply in minutes.

1. Small-sample predictor (criterion 2). "Fintech" shows up in 4 of 6 wins and looks like a pattern. Check: at least 30 deals share the trait, and its win-rate interval does not overlap the average win rate.
2. Headcount band drift (criteria 1 and 5). The source example: "A 500-person company where most employees are warehouse workers without LinkedIn profiles might show up in the 51-200 bracket." Check: for staff-heavy industries, compare the band with a business registry or the company's own site.
3. Two taxonomies (criteria 1 and 6). Rater A uses LinkedIn's V2 categories and rater B uses NAICS, so they disagree about the same company before any ICP judgment happens. Check: the spec names one taxonomy and its exact codes.
4. One-string role search (criteria 4 and 5). In Refolk's index, 23 of 25 US matches carried the literal string "Revenue Operations", so a single-string search probably misses the variants and undercounts the role. Check: the spec lists title synonyms for every owning role.
5. The lucky 20 (criterion 6). A 20-account sample can pass by chance, because the 95% confidence interval is about plus or minus 0.44. Check: the scorecard reports the interval, and a 20-account pass stays provisional until 50 accounts are rated.
6. Kappa paradox (criterion 6). If 18 of 20 accounts are non-fits, agreement is high and kappa is low, or the raters agree on the easy cases and never test the boundary. Check: the sample is balanced between likely fits and likely non-fits.
7. Adjective disqualifiers (criterion 3). "Bad culture fit" is not a field. Check: each rule names a field and a threshold.
8. Decorative owner line (criterion 7). A refresh date is listed, but no change log exists. Check: the last revision entry is less than one quarter old.

Owner, refresh date, and keeping the verdict current

Criterion 7 passes when the spec names one owner, a next refresh date, and a change log whose last entry is under one quarter old. A Buildable verdict is a snapshot. It expires when the market, the product, or the customer base moves.

The documented default is a quarterly review owned by RevOps, with input from sales, marketing, and customer success. At the earliest stage, the founders own the ICP. In both cases the guidance is the same: one named owner with a change log, and not a committee.

Re-run the affected criteria off-cycle when any of these happens:

• A product launch changes who benefits most from the offering.
• The competitive landscape shifts.
• An acquisition happens, on either side of the deal.
• The Tier 1 meeting rate falls below 8%, which suggests the tier definition is too broad. Re-grade criteria 4 and 6 first.

Some popular figures claim to show how few companies refresh quarterly, or how much quarterly refreshers outperform annual ones. Their sources and methods are not published. Don't use them to justify a cadence. Use your own meeting rates and churn instead.

ICP ACCEPTANCE SCORECARD
Spec: [name] | Version: [n] | Owner: [name] | Graded by: [name] | Date: [date]

1 Observable       PASS / FAIL   Attributes missing source, field, or taxonomy: __   Fix:
2 Discriminating   PASS / FAIL   Closed deals in sample: __   Churned wins removed: Y/N   Fix:
3 Disqualifiers    PASS / FAIL   Rules without field + threshold: __   Fix:
4 Bounded          PASS / FAIL   Count: __   Unit: __   Band: __   Fix:
5 Covered          PASS / FAIL   Filter fields without a measured rate: __   Fix:
6 Agreed           PASS / FAIL   Kappa: __   95% CI: +/- __   n = __   Balanced: Y/N   Fix:
7 Owned            PASS / FAIL   Last change-log entry: [date]   Next refresh: [date]   Fix:

VERDICT: Buildable / Revise / Not Yet an ICP
Rule: Not Yet if criterion 2 fails or kappa < 0.41. Revise if any other criterion fails. Buildable if all seven pass.
Provisional until 50 accounts rated: Y/N