Die meisten ICP-Übungen driften in Adjektiv-Suppe — „Mid-Market-SaaS in Fintech, Growth-Mindset, sicherheitsbewusst.” Listen, die aus einer solchen Beschreibung aufgebaut werden, schießen entweder unter (Filter zu eng, Sie bekommen 30 offensichtliche Accounts, die alle schon haben) oder überschießen (Filter zu locker, Sie bekommen 4.000 Logos und die AEs ignorieren die Datei). Das Bundle, das diese Seite liefert, macht die Umkehrung: Statt das ICP zu beschreiben, zeigen Sie auf zehn bis zwanzig Closed-Won-Accounts und lassen Claude umgekehrt erschließen, was sie gemeinsam haben, dann lassen Sie Clay diese Signatur in Filter und Anreicherung übersetzen.
Das Artefakt ist ein Claude Skill — icp-list-builder — der die Seed-to-List-Schleife von Ende zu Ende ausführt und einen geordneten Entwurf in eine Clay-Tabelle schreibt. Er ist darauf ausgelegt, einem Reviewer gleichzeitig einen Markdown-Report und eine Clay-Tabelle zu übergeben, nicht direkt in den Outbound zu pushen.
Wann einsetzen
Verwenden Sie diesen Skill, wenn Sie 10–20 Closed-Won-Accounts nennen können, die eine erkennbare Form teilen, und Sie möchten, dass die nächsten 100–500 Kandidaten wie sie aussehen. Die häufigsten Trigger in der Praxis:
Vierteljährliche Territory-Auffrischung — AEs brauchen einen Listenentwurf pro Region, frisch gegen aktuelle öffentliche Signale bewertet
Ein neues Wedge-Produkt oder neues Preisgestaltungs-Tier startet und die Basis der „Leute, die Ja gesagt haben” ist klein, aber echt
Ein Outbound-Programm hat das offensichtliche ICP bearbeitet und das Team braucht eine zweite Welle, die von dem informiert ist, was abgeschlossen hat, nicht von dem, was der Gründer ursprünglich als ICP imaginierte
Der Skill setzt ein Clay-Account auf dem Pro-Plan oder höher voraus. Darunter ist die Anreicherungs-Oberfläche zu schmal für die Lookalike-Schleife, um nützlich zu sein, und Sie werden für einen Workflow bezahlen, der ungefähr das tut, was eine Tabelle plus LinkedIn-Suche tun würde.
Wann NICHT einsetzen
Tier-1-Named-Account-ABM. Manuell aufgebaute Listen für 25–50 strategische Accounts umfassen Customer-Success- und Exec-Input, den der Skill nicht modellieren kann. Verwenden Sie das für Tier-2- und Tier-3-Outbound; die Varianz der Lookalike-Schleife ist zu hoch für die Tier-1-Auswahl.
Auto-Loading in Outbound-Sequenzen. Der Output ist ein geordneter Entwurf. Der Skill schreibt absichtlich in eine Clay-Tabelle und produziert einen Markdown-Report, sodass ein AE oder SDR ihn ansehen muss, bevor irgendetwas gesendet wird. Wenn Sie den Output in einen Sequenz-Trigger verdrahten, verwenden Sie das falsch.
Re-Scoring von Accounts, die bereits in Ihrem CRM sind. Verwenden Sie ein CRM-natives Intent-Tool dafür. Dieser Skill schreibt netto-neue Kandidaten; er rankt keine bekannten neu.
Scoring auf Protected-Class-Proxies. Gründergeschlecht, Gründer-Ethnizität, Alma Mater, Namensherkunft — nichts davon gehört in das Rubric. Die Referenz-Rubric-Datei listet auf, welche Dimensionen erlaubt sind; fügen Sie keine anderen hinzu.
Seed-Listen unter acht Accounts. Der Skill verweigert, unter acht gültigen Seeds fortzufahren, weil die Signatur-Extraktion auf einer kleineren Basis unzuverlässig ist. Wenn Sie nur fünf Wins haben, bauen Sie die Liste manuell auf und kommen Sie zurück, wenn Sie mehr haben.
Einrichtung
Das Bundle liegt unter apps/web/public/artifacts/icp-account-list-builder-clay/ und enthält:
SKILL.md — die Claude-Skill-Definition, die die Schleife orchestriert
references/1-icp-rubric-template.md — die firmografischen Gates und Signal-Gewichtungen, die Sie für Ihr Team ausfüllen
references/2-signal-source-matrix.md — welche öffentlichen Quellen als primär vs. korroborierend zählen und welche explizit nicht erlaubt sind
references/3-exclusion-criteria.md — gesperrte Domains, Mutterkonzerne und firmografische Muster, die niemals im Output erscheinen dürfen
Die Einrichtung dauert beim ersten Mal ungefähr 45 Minuten und bei jeder Auffrischung 5 Minuten.
Skill installieren. Legen Sie SKILL.md in Ihr Claude Skills-Verzeichnis (oder laden Sie es über Claude Code mit /skill load). Füllen Sie references/1-icp-rubric-template.md mit Ihren echten firmografischen Gates, technografischen Signalen und Signal-Gewichtungen aus. Füllen Sie references/3-exclusion-criteria.md aus einem frischen CRM-Export von Kunden, aktiven Opportunities und Closed-Lost-Accounts der letzten 180 Tage.
Seed-Liste vorbereiten. Ein CSV mit company_name, domain und why_we_won (zwei Sätze). Seeds über mehrere AEs, Segmente und Abschluss-Monate ziehen — der Skill warnt, wenn mehr als 60 % der Seeds einen einzelnen AE, ein Vertical oder einen Abschluss-Monat teilen, weil das eine Liste produziert, die wie das Territory eines Reps aussieht.
Clay verbinden. Der Skill liest Ihren Clay-Workspace über API. Workspace-ID und API-Key in der lokalen Config des Skills setzen (commiten Sie diese niemals in das Bundle).
Ersten Run. Rufen Sie den Skill mit Ihrem Seed-CSV und einem target_list_size von 100 auf. Der erste Run ist langsamer, weil das firmografische Universum ungefiltert ist; nachfolgende Runs gegen eine gespeicherte Clay-View sind schneller.
Markdown-Report und Clay-Tabelle zusammen überprüfen. Der Report erklärt die Seed-Signatur, die Signal-Typ-Aufschlüsselung und die Ausschluss-Flag-Zählungen. Die Clay-Tabelle ist die Arbeitsoberfläche für den AE.
Was der Skill tatsächlich macht
Sechs Schritte, in Reihenfolge. Die Reihenfolge ist wichtig — das LLM-Scoring vor dem firmografischen Filter auszuführen, verschwendet Credits und zieht offensichtliche Misfits herein.
Inputs laden und validieren. Seeds ohne why_we_won löschen und unter acht gültigen Seeds den Fortgang verweigern.
Seed-Signatur extrahieren. Die Seeds und das ICP-Rubric an Claude senden, das eine strukturierte Signatur zurückgibt: Branchencodes, Mitarbeiterzahl-Band, Umsatz-Band, Geografie, Finanzierungsphase, technografische Marker und Intent-Marker. Die why_we_won-Notizen kodieren Signale, die keine Clay-Spalten sind („sie hatten eine Sicherheits- und Compliance-Seite”); deshalb ist ein LLM-Pass vor dem deterministischen Filter nötig.
Deterministischen firmografischen Filter in Clay anwenden. Die Hard-Gates der Signatur in Clay-Filter übersetzen und sie zuerst ausführen, um das Universum auf ungefähr 500–3.000 Kandidaten einzuengen. Alles in der Ausschlussliste in diesem Schritt löschen. Das Tun vor dem Scoring reduziert die LLM-Kosten um ungefähr 30–100-fach, weil die meisten Ablehnungen offensichtliche firmografische Misfits sind, die kein Reasoning brauchen.
Intent-Signale anreichern und korroborieren. Für jeden verbleibenden Kandidaten Clay bitten, Tech-Stack, Einstellungs-Deltas und Ankündigungen der letzten 90 Tage anzureichern, dann Claude um Per-Signal-Match-Scores mit Zitaten bitten. Jedes einzelne Intent-Signal erfordert ein primäres korroborierendes Signal — eine LinkedIn-Jobänderung plus eine Pressemitteilung, zum Beispiel. Single-Source-Intent-Claims werden mit 0 bewertet mit Begründung „nicht korroboriert” statt geraten.
Ranken, deduplizieren und batch-schreiben nach Clay. Nach Gesamtscore sortieren, nach Mutterkonzern-Spalte deduplizieren und die Top-target_list_size-Zeilen in einem einzigen Batch in eine neue Clay-Tabelle schreiben. Per-Zeilen-Schreibvorgänge verbrauchen Credits und hinterlassen bei Unterbrechung inkonsistenten Status; Batch-Schreibvorgänge nicht.
Output-Report produzieren. Ein Markdown-Dokument mit der Seed-Signatur oben, der geordneten Kandidatentabelle, einer Signal-Typ-Aufschlüsselung, Ausschluss-Flag-Zählungen und Run-Metadaten. Der Reviewer liest das, bevor er die Clay-Tabelle bearbeitet.
Kostenrealität
Die großen Kostenhebel sind Clay-Anreicherungs-Credits und Claude-Token. Grobe Budgets pro Run, verankert auf einem target_list_size von 100 gegen ein firmografisch gefiltertes Universum von 1.800–2.200 Kandidaten:
Claude-Token (Signatur-Extraktion + Per-Kandidaten-Scoring). Ungefähr 500K–700K Input-Token und 80K–120K Output-Token auf Claude Opus pro Run. Zu Opus 4.7-Listenpreisen landet das bei rund 9–14 $ pro Run. Auf Claude Sonnet ist dieselbe Schleife ungefähr 1,50–2,50 $ pro Run mit messbarem Qualitätsverlust beim Signatur-Extraktionsschritt (das Seed-Muster-Reasoning profitiert vom größeren Modell). Empfehlung: Opus für den Signatur-Schritt, Sonnet für den Per-Kandidaten-Scoring-Schritt.
Clay-Credits. Ungefähr 800–1.000 Anreicherungs-Credits pro Run für einen 100-Zeilen-Output, bei 2.000 Kandidaten, die in den Anreicherungsschritt eingehen. Zu Clay-Pro-Preisen sind das etwa 24–30 $ an Credit-Kosten pro Run; auf dem Explorer-Tier sind Credits enger und Sie sollten target_list_size auf 50 reduzieren oder härter vorfiltern.
Im Maßstab. Ein Team, das das wöchentlich pro Region ausführt (sagen wir vier AE-Pods), landet bei ungefähr 1.300–2.000 $ pro Monat kombiniert (150–200 $ für Claude, der Rest Clay-Credits). Das ist weit unter den Kosten eines einzelnen ZoomInfo-SalesOS-Seats und produziert eine frischere Liste, erfordert aber, dass das Rubric und die Ausschlussdatei aktuell gehalten werden — veraltete Inputs sind der Ort, wo die Kosten schiefgehen (Sie zahlen für Credits, um Accounts anzureichern, die Schritt 1 nie überstehen sollten).
Das dominante Kosten-Blowup-Muster ist das wiederholte Aufrufen des Skills mit einem losen firmografischen Gate und das Ansehen, wie das Kandidaten-Universum explodiert. Der Guard ist in Schritt 3: Wenn Clay mehr als 5.000 Kandidaten zurückgibt, strafft der Skill ein Band und läuft erneut, statt die gesamte Menge anzureichern.
Erfolgsmetrik
Die zu beobachtende Metrik ist die Rate, mit der AEs den Listenentwurf in ihr Arbeitset akzeptieren, ohne manuelle Überarbeitung. Ziel: 70 %+ akzeptiert (d. h. von 100 geordneten Kandidaten landen mindestens 70 in der Outbound-Queue von jemandem, ohne gelöscht oder neu gelabelt zu werden). Unter 50 % Akzeptanz ist das Rubric falsch, die Seed-Liste ist biased oder die Ausschlussdatei ist veraltet — diagnostizieren Sie in dieser Reihenfolge.
Sekundär: Meeting-Buchungsrate auf den akzeptierten Accounts im Vergleich zur Baseline-Outbound-Liste des Teams. Der Skill verdient seine Credit-Kosten, wenn diese Rate mindestens der Baseline entspricht; der Mehrwert liegt in der Reduzierung der Listenaufbauzeit, nicht unbedingt in einem sofortigen Konversions-Lift.
Vergleich mit Alternativen
vs. LinkedIn Sales Navigator + manuelle Filterung. Sales Nav ist das richtige Tool für manuell erstellte Tier-1-Listen und für individuelles Prospecting auf einem Kandidaten. Es ist das falsche Tool zum wöchentlichen Produzieren von 100 geordneten Lookalikes — die Saved-Search-Filter erfassen keine Intent-Signale, und die manuelle Filter-Zeit pro Liste sind ungefähr 3–5 Stunden eines SDR pro Woche. Dieser Skill ersetzt diese 3–5 Stunden durch eine 5-minütige Überprüfung eines geordneten Entwurfs.
vs. ZoomInfo SalesOS Intent. SalesOS ist ausgereift, hat gute Intent-Daten zu Enterprise-Accounts und ist die richtige Antwort, wenn Sie eine Enterprise-Motion haben und das Budget für 35.000–80.000 $ pro Jahr an Seats. Für eine Mid-Market-Motion bei einem kleineren Team ist dieser Skill plus Clay Pro ungefähr 80 % des Signals zu 5–10 % der Kosten, mit dem Trade-off, dass Sie das Rubric und die Ausschlussliste besitzen statt auf das Scoring eines Anbieters zu vertrauen.
vs. Apollo Living Data. Apollos Lookalike-Funktion ist in der Form diesem Skill am nächsten und ist einen Klick statt eine 45-minütige Einrichtung. Apollos Lookalike-Scoring ist undurchsichtig (Sie können die Signal-Gewichtungen nicht sehen oder überschreiben) und die Outputs neigen dazu, auf firmografische Ähnlichkeit zu überindizieren. Dieser Skill macht das Rubric und die Gewichtungen inspizierbar und erzwingt Per-Signal-Korroboration; der Preis ist die Einrichtungszeit und die Anforderung, die Referenzdateien aktuell zu halten.
vs. nichts (Status quo, AE baut die Liste). AE-gebaute Listen sind umfassend bei den bekannten Accounts des AE und schwach bei den Lookalikes, von denen der AE noch nichts gehört hat. Dieser Skill ist das Gegenteil — er ist schlecht bei benannten strategischen Accounts und gut bei der Aufzeigung der nächsten 100 Lookalikes. Das ehrliche Muster ist, beides parallel zu betreiben: AE besitzt die benannte Liste, der Skill produziert den Lookalike-Entwurf.
Watch-outs
Schlechte firmografische Daten aus öffentlichen Quellen. Aggregator-Mitarbeiterzahlen und Umsatzzahlen hinken der Realität 6–18 Monate hinterher und sind bei Wachstumsphasen-Unternehmen um 30–50 % falsch. Guard: Der Skill behandelt jede einzelne firmografische Quelle als richtungsweisend und erfordert Übereinstimmung über zwei unabhängige Quellen, bevor er ein hartes Gate anwendet. Konflikte erscheinen im Output-Report („LinkedIn sagt 120, BuiltWith sagt 380 — für manuelle Überprüfung geflaggt”) statt still aufgelöst zu werden.
Intent-Signal-Rauschen. Ein „hat einen VP of Sales eingestellt”-Signal aus LinkedIn allein fehlklassifiziert Beförderungen, Vertragsrollen und Titel-Inflation als Netto-Neueinstellungen. Guard: Schritt 4 erfordert ein primäres korroborierendes Signal (Pressemitteilung, zweiter-Winkel-LinkedIn-Beleg), bevor ein Intent-Signal über 0 bewertet wird; nicht korroborierte Claims werden mit 0 bewertet, mit dem aufgezeichneten Grund für das Audit.
Listen-Vergiftung durch veraltete Datenbanken. Manche Clay-Anreicherungsquellen tragen Zombie-Unternehmen — akquiriert, fusioniert oder erloschen — die Filter passieren, aber nicht kaufen können. Guard: Jeden Kandidaten löschen, dessen Website bei der Homepage-Prüfung eine 4xx/5xx zurückgibt, in den letzten 90 Tagen keine LinkedIn-Aktivität hat oder dessen Mutterkonzern-Feld zu einem bekannten Käufer in der Ausschlussdatei aufgelöst wird. Die Lösch-Zählung erscheint in den Run-Metadaten, damit der Operator einen Spike erkennen kann (ein Zeichen dafür, dass die Ausschlussdatei oder die Aggregator-Quelle sich verschlechtert).
Seed-Bias. Eine Seed-Liste von 10 Wins von einem AE in einem Vertical produziert eine Liste, die wie das Territory dieses AE aussieht. Guard: Der Skill warnt, wenn mehr als 60 % der Seeds denselben AE, dasselbe Vertical oder denselben Abschluss-Monat teilen, und bittet den Operator, den Seed zu verbreitern, bevor er fortfährt.
Filter-Overfit. Eine Signatur, die so eng ist, dass sie nur die 14 Seeds matched, produziert 0–30 Kandidaten und fühlt sich präzise an, ist aber nutzlos. Guard: Wenn Schritt 3 weniger als 200 Kandidaten zurückgibt, lockert der Skill die Mitarbeiterzahl- und Umsatz-Bänder um eine Stufe und läuft erneut, statt mit einem ausgehungerten Universum fortzufahren.
Veraltete Ausschlussdatei. Wenn der Kunden-Listen-Export zwei Monate alt ist, kann ein Kunde durchrutschen und in den Outbound geraten. Guard: Der Skill warnt im Output-Report, wenn last_refreshed in der Ausschlussdatei mehr als 14 Tage alt ist.
Stack
Clay (Pro oder höher) — Anreicherungs-Substrat, firmografischer Filter und Zieltabelle. Pro ist der praktische Boden für die Lookalike-Schleife.
Claude (Opus 4.7 für Signatur-Extraktion, Sonnet für Per-Kandidaten-Scoring) — Signatur-Reasoning über die Seed-why_we_won-Notizen und Per-Signal-Korroboration-Scoring mit Zitaten. Die Modell-Auswahl über die zwei Schritte aufzuteilen ist der Ort, wo der Kosten-Qualitäts-Trade am besten landet.
CRM (beliebig) — Quelle der Seed-Liste, Kundenliste, Opportunity-Liste und Closed-Lost-Liste, die die Ausschlussdatei speist. Der Skill liest das CRM nicht direkt; der Operator exportiert CSVs.
Outbound-Ziel (Outreach, Salesloft, Apollo, Custom) — wohin die überprüfte Liste nach AE-Akzeptanz geht. Der Skill stoppt bei der Clay-Tabelle aus Design-Gründen.
---
name: icp-list-builder
description: Build a ranked target-account list from public signals using a closed-won seed pattern. Input is a seed of 10-20 closed-won accounts plus an ICP rubric; output is a ranked list of 100-500 lookalike candidates with per-account evidence, ready to write to a Clay table for outbound or AE territory routing.
---
# ICP list builder (Clay + Claude)
## When to invoke
Invoke this skill when a RevOps or SDR leader needs a fresh target-account list grounded in what already worked — not in a generic "mid-market SaaS in fintech" description. The skill takes closed-won accounts as the ground truth, extracts the firmographic + technographic + intent signature shared across them, then proposes Clay filters that produce lookalikes plus a ranked candidate list with evidence.
Typical triggers:
- Quarterly territory refresh — AEs need a new draft list per region
- New product or new wedge launch — the seed list is small (10-20 wins) and you want the next 100 to look like them
- Outbound program needs more accounts after the obvious ICP has been worked
Do NOT invoke this skill for:
- Auto-loading the output into outbound sequences without rep review. The output is a ranked draft, not a send list. AE or SDR review is mandatory.
- Scoring on protected-class proxies (founder gender, ethnicity, school). Rubric weighting must be on firmographic and intent signals only.
- Account lists for ABM tier-1 named accounts — that work is hand-built and this skill's lookalike loop has too much variance for tier-1 selection.
- Buying-signal scoring inside an existing CRM record (use a CRM-native intent tool — this skill writes new candidates, it does not re-score known ones).
## Inputs
Required:
- `seed_accounts` — CSV with columns `company_name`, `domain`, `why_we_won` (two sentences). 10-20 rows. Rows with missing `why_we_won` are dropped with a warning rather than silently skipped.
- `icp_rubric` — path to `references/1-icp-rubric-template.md` filled in for your team. Defines hard firmographic gates and signal-weight ordering.
- `target_list_size` — integer, the number of ranked candidates to return. Default 100. Hard cap 500 (above that, Clay credits and signal noise both blow up).
Optional:
- `signal_sources` — path to `references/2-signal-source-matrix.md` to override which public sources Clay/Claude should query and which it should ignore. Defaults: company website, LinkedIn company page, BuiltWith, public hiring pages, last-90-day press/funding announcements.
- `exclusion_list` — path to `references/3-exclusion-criteria.md`. Domains, parent companies, or firmographic patterns that must never appear in the output (existing customers, active opportunities, do-not-contact, known losses inside last 6 months).
- `territory_filter` — geography or vertical filter applied after scoring, for splitting the output by AE territory.
## Reference files
Always read the following from `references/` before generating the list. They contain the team's actual ICP definition, source preferences, and exclusions. Without them, the list is generic and may write banned domains.
- `references/1-icp-rubric-template.md` — hard firmographic gates plus the signal-weight order used for scoring. Replace template contents with your real rubric before first run.
- `references/2-signal-source-matrix.md` — which public sources count as primary vs corroborating, and which are explicitly disallowed (low-quality scraped databases, stale aggregators). Replace with the team's source policy.
- `references/3-exclusion-criteria.md` — banned domains, parent companies, firmographic patterns to drop. Replace with the team's actual exclusion list before first run.
## Method
Run these six steps in order. The deterministic firmographic filter MUST run before any LLM scoring — running scoring across the full Clay universe wastes credits and pulls in obvious misfits.
### 1. Load and validate inputs
Read `seed_accounts`, `icp_rubric`, and `exclusion_list`. Drop seed rows with missing `why_we_won` and warn. Refuse to proceed if fewer than 8 valid seed rows remain — the signature extraction is unreliable below that floor.
### 2. Extract the seed signature
Send the validated seeds to Claude with the ICP rubric as context. Ask for a structured signature: industry codes, headcount band, revenue band (if known), geography, funding stage, technographic markers (specific tools), intent markers (hiring patterns, page additions, public announcements), and disqualifiers observed.
Why Claude here, not a SQL query: the `why_we_won` notes encode tacit signals ("they had a security and compliance page" — not a Clay column) that firmographic queries miss.
### 3. Apply deterministic firmographic filter in Clay
Translate the signature's industry, headcount, revenue, geography, and funding gates into Clay filters. Run them first to narrow the universe to ~500-3000 candidates before any LLM cost is spent. Drop anything in `exclusion_list` at this stage.
Why deterministic first, LLM second: a single LLM scoring pass at full Clay universe scale costs roughly 30-100x more than a filter pass, and 80-90% of the rejections are obvious firmographic misfits that need no reasoning.
### 4. Enrich and corroborate intent signals
For each remaining candidate, ask Clay to enrich tech stack, hiring page deltas, and last-90-day announcements. Pass each candidate to Claude with the seed signature and ask for a per-signal match score (0-3) plus a corroborating citation URL.
Constraint: any single intent signal (e.g. "hired a VP of Revenue") requires a primary corroborating signal (LinkedIn job change visible from a second angle, or a press release citing the hire). Single-source intent claims are scored 0 with reason "uncorroborated" rather than guessed. This is the guard against intent-signal noise.
### 5. Rank, dedupe, and batch-write to Clay
Sort by total signal-match score, descending. Dedupe by domain (parent companies via Clay's parent-company column where present — same parent counts once). Write the top `target_list_size` rows to a new Clay table, one batch write at the end rather than per-row.
Why batch + dedupe before write: Clay enrichment is metered per row, and duplicate parent writes burn credits without adding accounts. A single batch write also keeps the table consistent if the run is interrupted.
### 6. Produce the output report
Generate the markdown output (format below). Include a top section that explains the seed signature so the AE/SDR reviewer can sanity-check the shape of the list before working it.
## Output format
Output is a single markdown document, written to disk and surfaced to the caller. Literal example shape:
```markdown
# ICP list — {date}
## Seed signature
- Industry: B2B SaaS — DevTools and Observability (NAICS 5415)
- Headcount: 80-350
- Revenue (where known): $10M-$60M ARR
- Geo: US + Canada, EMEA-EN
- Funding: Series B and C
- Technographic markers: Stripe, Datadog OR New Relic, Notion (corroborator)
- Intent markers: hired VP of Revenue or Head of Sales in last 9 months, or
shipped a new public security/compliance page in last 6 months
- Disqualifiers observed: government contractor, parent in F500
## Ranked candidates (top 100 of 217 scored)
| Rank | Company | Domain | Score | Top signal | Exclusions flagged |
|---|---|---|---|---|---|
| 1 | Acme Observability | acme.io | 14/15 | Hired VP Rev (LinkedIn + Sept 2026 press release) | none |
| 2 | Beacon Logs | beaconlogs.com | 13/15 | Stripe + Datadog + Series B Aug 2026 | none |
| 3 | Ledger Trace | ledgertrace.dev | 12/15 | New SOC 2 page Oct 2026 | EU-only — territory split required |
| ... | ... | ... | ... | ... | ... |
## Signal-type breakdown across the top 100
- Hiring-signal-driven: 38
- Technographic-driven: 29
- Funding/announcement-driven: 22
- Multi-signal (3+): 11
## Exclusion-flag explanations
- 14 candidates flagged "EU-only — territory split required": these passed
ICP but fall outside US/CA territories and should route to the EMEA pod.
- 3 candidates flagged "parent in F500": these were dropped from the ranked
list per `exclusion_list`. Listed for audit only.
- 9 candidates flagged "uncorroborated intent": dropped per Step 4 guard.
## Run metadata
- Seeds used: 14 (2 dropped for missing why_we_won)
- Clay universe after firmographic filter: 1,847
- Candidates scored by Claude: 217
- Final ranked list: 100
- Clay credits consumed: ~870 (enrichment) + 217 (scoring lookups)
```
## Watch-outs
- **Junk firmographic data from public sources.** Aggregator headcount and revenue numbers lag reality by 6-18 months and are wrong by 30-50% on growth-stage companies. Guard: treat any single firmographic source as directional, require headcount or revenue agreement across two independent sources before applying a hard gate, and surface conflicts in the output ("LinkedIn says 120, BuiltWith says 380 — flagged for manual review").
- **Intent-signal noise.** A "hired a VP of Sales" signal scraped from LinkedIn alone misclassifies promotions, contract roles, and job-title inflation as net-new hires. Guard: Step 4 requires a primary corroborating signal (press release, second-angle LinkedIn evidence) before any intent signal scores above 0.
- **List poisoning from outdated databases.** Some Clay enrichment sources carry zombie companies (acquired, merged, defunct) that pass filters but cannot buy. Guard: drop any candidate whose website returns a 4xx/5xx, has no LinkedIn activity in last 90 days, or whose parent-company field resolves to a known acquirer. These are reported in the run metadata, not silently dropped.
- **Seed bias.** A seed list of 10 wins from one AE in one vertical produces a list that looks like that AE's territory, not the company's ICP. Guard: the skill warns if more than 60% of seeds share the same primary AE, vertical, or close-month, and asks the operator to broaden the seed before proceeding.
- **Filter over-fit.** A signature so tight it matches only the 14 seeds produces 0-30 candidates and feels precise but is useless. Guard: if the Clay firmographic-filter step returns fewer than 200 candidates, the skill loosens the headcount and revenue bands by one notch and re-runs rather than proceeding.
- **AE review is non-optional.** Skill output is a ranked draft. The output format is markdown (not a Clay-to-sequence webhook) deliberately to force a human review step before any send.
# ICP rubric — TEMPLATE
> Replace this template's contents with your team's actual ICP rubric
> before the first run of `icp-list-builder`. The skill reads this file to
> set hard firmographic gates and signal-weight ordering. Without your
> real values, the candidate list will be generic.
## Hard firmographic gates
These are AND-gates — a candidate failing any single gate is dropped before any LLM scoring runs. Keep this list short (5-8 dimensions max). Long gate lists shrink the candidate universe below the 200-row floor and force the skill to loosen filters anyway.
| Dimension | In-ICP | Stretch (allowed but downweighted) | Out (dropped pre-scoring) |
|---|---|---|---|
| Industry (NAICS or custom tag) | {list} | {list} | {list} |
| Headcount | {range, e.g. 80-500} | {range, e.g. 50-79 or 501-800} | {below/above} |
| Revenue (where known) | {range} | {range} | {range} |
| Geography | {regions, e.g. US/CA, EMEA-EN} | {regions, e.g. APAC-EN} | {regions, e.g. China, sanctioned countries} |
| Funding stage | {stages, e.g. Series B-D} | {stages, e.g. Series A late or Series E} | {stages, e.g. pre-seed, IPO+} |
| Business model | {e.g. B2B SaaS subscription} | {e.g. usage-based} | {e.g. consulting, services} |
## Technographic signals
Tools that signal a fit (we win when these are present). Each entry should name a specific product, not a category.
- {Tool 1 — e.g. "Stripe (billing) — strong"}
- {Tool 2 — e.g. "Datadog or New Relic — strong"}
- {Tool 3 — e.g. "Notion (corroborator only, not a primary signal)"}
Tools that signal misfit. The skill downweights candidates with these.
- {Tool A — e.g. "Salesforce + manual CPQ — competing internal build"}
- {Tool B — e.g. "Legacy ERP with no API surface"}
## Intent signals
The signals the skill looks for in Step 4. Each must specify the primary source AND the required corroborating source. Single-source intent counts as zero per the skill's guard.
| Signal | Primary source | Required corroborator |
|---|---|---|
| Hired VP Rev / Head of Sales (last 9 months) | LinkedIn job change | Press release, company blog, or 2nd-angle LinkedIn evidence (e.g. announcement post) |
| New compliance page (SOC 2, ISO 27001, HIPAA) | Company website diff | Trust center URL or vendor listing |
| Funding round (Series A+) last 6 months | Crunchbase / company press | TechCrunch, PitchBook, or filed 8-K |
| Active hiring 5+ GTM roles | Public careers page | LinkedIn jobs cross-reference |
## Signal weights
The skill ranks candidates on a 0-15 scale across five signal categories. Set the per-category weights here. Total must equal 15.
- Industry + business-model match: weight {N, e.g. 4}
- Headcount + revenue match: weight {N, e.g. 3}
- Technographic match: weight {N, e.g. 3}
- Intent signal (corroborated): weight {N, e.g. 4}
- Geography + funding stage match: weight {N, e.g. 1}
## Disqualifiers (skill flags prominently if found)
Single signals that drop a candidate regardless of other fit. Keep narrow.
- {Disqualifier 1 — e.g. "Parent company in Fortune 500 (procurement model wrong for our motion)"}
- {Disqualifier 2 — e.g. "Government contractor (compliance posture we cannot meet)"}
- {Disqualifier 3 — e.g. "Active acquisition in last 90 days (buying frozen)"}
## Last edited
{YYYY-MM-DD} — update on every material change so the skill can warn when the rubric is stale (more than 6 months old triggers a stale-rubric notice in the output report).
# Signal source matrix — TEMPLATE
> Replace this template's contents with your team's actual source policy.
> The `icp-list-builder` skill reads this file to decide which public sources
> count as primary vs corroborating, and which to skip entirely.
## Why this file exists
The skill's intent-signal scoring (method Step 4) requires a primary source plus a corroborating source for any signal to count above 0. This matrix is where you encode which source plays which role for your team. Without it the skill defaults to a generic ordering that under-weights signals you trust and over-weights ones you've found unreliable.
## Source roles
For each public source the skill may query, assign one role:
- **primary** — a signal originating here can anchor a score (still needs one corroborator)
- **corroborator** — only counts as the second source confirming a primary signal; cannot anchor on its own
- **skip** — never query this source; results are too noisy or stale to trust
## Source × signal-type matrix
| Source | Firmographic | Technographic | Hiring | Funding | Compliance/security | Notes |
|---|---|---|---|---|---|---|
| Company website (homepage, About, careers, trust center) | corroborator | corroborator | primary | corroborator | primary | Source of truth for own claims; queried first |
| LinkedIn company page | primary | skip | primary | corroborator | skip | Strongest for headcount + role changes; rate-limited |
| LinkedIn jobs | skip | skip | corroborator | skip | skip | Volume signal only; titles are noisy |
| BuiltWith | skip | primary | skip | skip | corroborator | Strong for tech stack, weak for everything else |
| Crunchbase | corroborator | skip | skip | primary | skip | Funding date + amount only; org charts are stale |
| Public press releases (last 90 days) | skip | skip | corroborator | corroborator | corroborator | Date-stamped; cite URL + date |
| TechCrunch / industry press | skip | skip | corroborator | corroborator | skip | Use for funding corroboration |
| G2 / Capterra reviews | skip | corroborator | skip | skip | skip | Reviewer-self-reported; treat as weak signal only |
| Wayback Machine | corroborator | corroborator | corroborator | skip | corroborator | Use to date page additions (compliance pages, jobs page changes) |
| Generic data aggregators (ZoomInfo, Apollo passive scrape) | skip | skip | skip | skip | skip | High noise; use a paid product directly if needed, do not let the skill scrape |
## Sources explicitly disallowed
The skill must never query these. Add domains here as you discover sources that have produced bad data for your team.
- {Domain 1 — e.g. "scraped-data-aggregator-x.example"}
- {Domain 2}
## Refresh windows
How fresh a signal must be to count. Anything older than the window is dropped to corroborator-only or to 0.
| Signal type | Max age to count as primary | Max age to count as corroborator |
|---|---|---|
| Hiring announcement | 9 months | 18 months |
| Funding round | 6 months | 12 months |
| Compliance page addition | 6 months | 24 months |
| Tech-stack signal | 6 months (BuiltWith last-seen) | 12 months |
| Headcount snapshot | 90 days | 12 months |
## Last edited
{YYYY-MM-DD}
# Exclusion criteria — TEMPLATE
> Replace this template's contents with your team's actual exclusion list
> before the first run of `icp-list-builder`. The skill reads this file in
> method Step 1 and Step 3, and refuses to write any matched domain to the
> output Clay table.
## Why this file matters
A list builder that writes existing customers, active opportunities, or known-loss accounts back into outbound is worse than no list — it burns trust with AEs, with the prospect (who gets contacted as a stranger), and with CS (who finds out when the customer escalates). This file is the backstop. The skill treats it as a hard filter, not a downweighting signal.
## Banned domains
Exact-match domains that must never appear in the output. The skill matches on root domain and known parent-company domains.
```
# Existing customers
{customer1.com}
{customer2.com}
# Active opportunities (export from CRM monthly and paste here)
{opp1.com}
{opp2.com}
# Closed-lost in last 6 months (do not re-engage from outbound; route to AE for hand-touch)
{lost1.com}
{lost2.com}
# Do-not-contact requests honored
{dnc1.com}
{dnc2.com}
# Internal / partners / investors (never outbound)
{partner1.com}
{investor1.com}
```
## Banned parent companies
If the skill's enrichment step resolves a candidate to a parent in this list, the candidate is dropped regardless of root-domain match.
- {Parent 1 — e.g. "BigCo Inc — all subsidiaries flagged"}
- {Parent 2}
## Firmographic exclusion patterns
Patterns broader than a single domain. The skill applies these in Step 3 after firmographic enrichment.
- {Pattern 1 — e.g. "Any company tagged as government contractor by NAICS prefix 5417"}
- {Pattern 2 — e.g. "Any company headquartered in {sanctioned-country-list}"}
- {Pattern 3 — e.g. "Any company with active M&A announcement in last 90 days"}
## Audit posture
Excluded candidates are not silently dropped. The skill's run metadata section reports counts per exclusion category. This lets RevOps verify the exclusion file is current and catches the case where the customer list export was forgotten and a customer slipped through.
## Refresh cadence
This file is regenerated from CRM exports on a fixed cadence. Stale exclusion files are the most common source of bad list output.
- Customers: refresh weekly (every Monday)
- Active opportunities: refresh weekly (every Monday)
- Closed-lost: refresh monthly (first of month)
- DNC: refresh on every request received
- Partners / investors: refresh quarterly
## Last refreshed
{YYYY-MM-DD} — exports as of this date. The skill warns in its output report if this date is more than 14 days old.