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

*Grade any ICP document against seven pass/fail tests and reach a Buildable, Revise, or Not Yet verdict that a second rep would repeat, with each failure's fix named.*

- Canonical URL: https://www.refolk.ai/guides/icp-acceptance-gate-standard
- Pillar: Sales and go-to-market
- Format: Standard
- Published: 2026-10-25
- Last reviewed: 2026-10-25
- Reading time: 22 min
- Keywords: how to know if your ICP is too broad, ICP definition checklist, negative ICP disqualifiers, turn ICP into account list filters, validate ICP against closed-won and closed-lost, ICP scoring inter-rater agreement

## Key takeaways

- An ICP spec is Buildable only when all seven criteria pass. If no attribute separates good wins from losses on counted evidence, it is Not Yet an ICP, however polished the deck looks.
- Validate an ICP on at least 30 closed deals, won and lost, and treat any trait shared by fewer than about 30 deals as a hypothesis rather than a filter.
- Remove churned wins before testing. In one illustrative example, retail's 9 wins from 58 closed deals fell to 4 good wins (7%) once customers who churned within a year were taken out.
- A blind two-rater test on 20 accounts carries a 95% confidence interval of about plus or minus 0.44 on kappa, so use it as a fail-fast gate and confirm on 50 accounts (plus or minus 0.28).
- In Refolk's index, 'Revenue Operations' titles are 12.5x more common in the US than the UK, while SDR titles are only 6.2x more common, so a 'RevOps present' filter cuts UK match counts about twice as hard.
- ICP sizing rules conflict because they count different units: 20 to 30 high-touch accounts per SDR per week, 50 to 150 open per SDR at once, and a universe three to five times the final list.

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.

| Verdict | Trigger | Next move |
|---|---|---|
| Buildable | All seven criteria pass | Build the list; confirm agreement at 50 accounts before scaling |
| Revise | Criterion 2 passes, kappa is 0.41 or higher, another criterion fails | Fix the named criteria and re-grade only those |
| Not Yet an ICP | Criterion 2 fails, or kappa is below 0.41 | Go back to closed-deal data before writing any filter |

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.

> **Rule:** No count, no attribute
>
> An attribute without counts from both good wins and losses fails criterion 2, however obvious the team thinks it is.
> Write the counts on the same line as the attribute, so the grader never has to ask where they came from.

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.

#### How churn shrinks a segment's real win rate

| Stage | Figure | Note |
| --- | --- | --- |
| Retail closed deals | 58 | won and lost together |
| Raw wins | 9 | what a churn-blind CRM report shows |
| Good wins | 4 | retained past year one, 7% of closed deals |

*Once customers who churned within a year are removed, an illustrative retail segment falls from 9 wins to 4 good wins out of 58 closed deals.*

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

#### Which attributes become filters

Horizontal axis runs from Hard to observe publicly to Observable in public records. Vertical axis runs from Does not separate wins from losses to Separates wins from losses.

| Quadrant | What it means |
| --- | --- |
| Predictive but hidden | Name a public proxy or move it to discovery questions |
| Filter on it | Write it as a field rule with source and taxonomy |
| Cut it | Delete it from the spec |
| Visible noise | Do not filter; it only distorts the match count |

*Only attributes that are both publicly observable and proven to separate wins from losses should become list filters.*

## 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.

| Signal | Field rule | Grade |
|---|---|---|
| Too small to implement | Exclude by employee band or minimum department size | Pass |
| Low budget | Filter by funding, revenue estimate, or firmographic tier | Pass |
| High-churn segment | Exclude industries that churn at twice the average rate | Pass if the rate is measured |
| Bad culture fit | None | Fail |

- **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.

| Unit | Bound | What it limits |
|---|---|---|
| High-touch accounts per SDR per week | 20 to 30 | Weekly effort |
| Tier 1 accounts per SDR per week | 15 to 25 | Weekly effort, top tier |
| Accounts open per SDR at once | 50 to 150 | Working list |
| Accounts per SDR per month | 100 to 200 | Monthly throughput |
| Universe vs final list | 3 to 5x | Total matches |

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.

| Metric | US | UK | US:UK |
|---|---|---|---|
| "Revenue Operations" profiles | 351 | 28 | 12.5x |
| "Sales Development Representative" profiles | 22,093 | 3,551 | 6.2x |
| SDRs per RevOps-titled profile | 62.9 | 126.8 | 0.5x |
| Off-target titles in 25-profile RevOps sample | 8% | 0% | n/a |

**12.5x - More "Revenue Operations" profiles in the US than the UK, in Refolk's index**

SDR profiles are only 6.2x more common, so a "RevOps present" filter cuts UK matches about twice as hard as US ones.

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.

I ran this search: `Heads of Revenue Operations at UK B2B SaaS companies with 50 to 200 employees` - [see the full result list](https://www.refolk.ai/s/tfzqp6q2h4).

*Returns matching people with titles, companies, and locations, so you can count off-target titles and country-only locations for a coverage line.*

## 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).

| Kappa | Landis & Koch label | Gate outcome |
|---|---|---|
| Above 0.80 | Almost perfect | Pass |
| 0.61 to 0.80 | Substantial | Pass |
| 0.41 to 0.60 | Moderate | Revise |
| Below 0.41 | Below moderate | Not Yet an ICP |

> **Note:** The pass line is borrowed, not measured
>
> No sales-specific kappa threshold has been published. The 0.61 line comes from the Landis & Koch "substantial" band and McHugh's stricter view that kappa below roughly 0.60 is inadequate, so adopt it as team policy rather than as a proven benchmark.

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:

| Accounts rated | Standard error | 95% CI ± | Agreement change per disagreement |
|---|---|---|---|
| 20 | 0.224 | 0.44 | 5 pts |
| 50 | 0.141 | 0.28 | 2 pts |
| 100 | 0.100 | 0.20 | 1 pt |

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.

**Blind rater brief for the two-rater sample**

```
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]
```

*Send to each rater separately with the same account list and replace the bracketed fields.*

## 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.

#### The ICP acceptance gate

1. **Export closed deals with a retention flag** - Pull every closed-won and closed-lost deal with 12-month retention. Done when every won row carries a renewed or churned flag.
2. **Re-label wins into three groups** - Move wins that churned within 12 months or closed at a heavy discount out of good wins. Done when each deal is good won, lost, or churned.
3. **Test each attribute for discrimination** - Keep traits common in good wins and rare in losses, from at least 30 deals. Done when every line cites counts from both sides.
4. **Write disqualifiers as field rules** - With customer success, turn each exclusion into a field, an operator, and a threshold. Done when no rule needs its author to explain it.
5. **Size the universe and measure field coverage** - Count matches per named unit against its band, then sample about 25 records per filter field. Done when counts sit inside the bands and every field has a coverage rate.
6. **Run the blind two-rater sample** - Two reps score a balanced 20 accounts independently. Done when kappa and its confidence interval are recorded, with a pass marked provisional until 50.
7. **Name the owner and refresh date** - Assign one owner, set the next quarterly review, and open a change log. Done when the log has an entry dated this quarter.
8. **Grade and record the verdict** - Score all seven criteria and apply the verdict rule. Done when the scorecard shows the verdict and a fix for each failed criterion.

## 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.

> **Watch out:** The cheapest false pass
>
> A spec can pass every other criterion and still be built on customers who left. If the export has no renewed or churned flag, criterion 2 cannot pass, however strong the counts look.

## 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**

```
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
```

*Fill one per spec version and keep it with the change log; the verdict rule at the bottom is the team policy.*

#### Before you build the list

- [ ] Every filter attribute names a source, a field, and one taxonomy with exact codes.
- [ ] Every attribute line shows counts from good wins and from losses, drawn from at least 30 closed deals.
- [ ] Wins that churned within 12 months or closed at a heavy discount are out of the good-win group.
- [ ] Traits shared by fewer than about 30 deals are labelled hypotheses, not filters.
- [ ] Every disqualifier is written as a field, an operator, and a threshold.
- [ ] The spec states each match count with its unit, and each count sits inside that unit's band.
- [ ] Every filter field carries a coverage rate measured on about 25 records.
- [ ] Every owning-role filter lists title synonyms, not a single string.
- [ ] Two blind raters scored a balanced 20-account sample, and kappa is recorded with its confidence interval.
- [ ] A pass at 20 accounts is marked provisional until 50 accounts are rated.
- [ ] One named owner, a next refresh date, and a change-log entry from this quarter appear on the document.

## Frequently asked questions

### How do I know if my ICP is too broad?

Your ICP is too broad when its match count is bigger than your team can work in the unit the count measures. For one SDR, that means 20 to 30 high-touch accounts a week or 50 to 150 open at once. Your universe should be three to five times the final list, not twenty times. After launch, a Tier 1 meeting rate below 8% is another sign that the tier definition is too broad.

### How many closed deals do I need to validate an ICP?

Use at least 30 closed deals, counting both wins and losses. Published floors run from a ten-deal sanity check up to 50 to 100 deals. One framework calls fewer than 30 noise, and another says quantitative analysis is unreliable below 40 to 50. Apply the floor to each trait as well as to the whole sample: if fewer than about 30 closed deals share a trait, label it a hypothesis and don't use it as a hard filter.

### What is a negative ICP, and how do I write disqualifiers?

A negative ICP is the explicit list of accounts you will not pursue. Each disqualifier has to be a field plus a threshold that a list builder can apply. Write 'too small to implement' as an employee band or a minimum department size, and 'low budget' as a funding, revenue estimate, or firmographic tier filter. 'Bad culture fit' fails because no field holds it.

### Is 20 accounts enough for an inter-rater agreement test on an ICP?

Twenty accounts is enough to catch gross ambiguity, but it can't confirm a pass. At 20 accounts, the 95% confidence interval on kappa is about plus or minus 0.44, which runs from moderate to almost perfect, and a single disagreement moves agreement by 5 points. Use 20 as a fail-fast gate. Treat any pass as provisional until two raters have scored 50 accounts, where the interval narrows to about plus or minus 0.28.

### How often should an ICP be refreshed, and who should own it?

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 it. Whoever it is, name one person and keep a change log. Review off-cycle after a product launch that changes who benefits most, a shift in the competitive landscape, or an acquisition. The spec fails if its last change-log entry is more than one quarter old.

### Why do two reps disagree on the industry of the same company?

They are usually reading different taxonomies. LinkedIn's Industry Codes V2 has 434 industries under 20 top-level sectors, and its IDs differ from NAICS codes. NAICS gives no guidance on companies made up of multiple establishments. If one rep reads LinkedIn categories and the other reads NAICS, they disagree before any ICP judgment happens. The fix is for the spec to name one taxonomy and the exact codes it accepts.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/icp-acceptance-gate-standard*