ooligo
claude-skill

Construire des listes de comptes ICP depuis des signaux publics avec Clay et Claude

Difficulty
intermédiaire
Setup time
45min
For
revops · sdr-leader
RevOps

Stack

La plupart des exercices ICP dérivent vers une soupe d’adjectifs — « SaaS mid-market en fintech, growth mindset, conscient de la sécurité ». Les listes construites à partir de ce type de brief sont soit trop restrictives (filtres trop serrés, vous obtenez 30 comptes évidents que tout le monde a déjà) soit trop larges (filtres trop lâches, vous obtenez 4 000 logos que les AE ignorent). Le bundle livré sur cette page fait l’inverse : au lieu de décrire l’ICP, vous pointez vers dix à vingt comptes gagnés en closed-won et laissez Claude faire l’ingénierie inverse de ce qu’ils ont en commun, puis vous laissez Clay traduire cette signature en filtres et en enrichissement.

L’artifact est un Claude Skill — icp-list-builder — qui exécute la boucle graine-vers-liste de bout en bout et écrit un draft classé dans une table Clay. Il est conçu pour donner à un réviseur un rapport Markdown et une table Clay côte à côte, pas pour pousser directement vers l’outbound.

Quand l’utiliser

Utilisez ce skill quand vous pouvez nommer 10-20 comptes closed-won qui partagent une forme reconnaissable, et que vous voulez que les 100-500 prochains candidats leur ressemblent. Les déclencheurs les plus courants en pratique :

  • Rafraîchissement trimestriel de territoire — les AE ont besoin d’un draft de liste par région, fraîchement scoré par rapport aux signaux publics actuels
  • Un nouveau produit de niche ou un nouveau niveau tarifaire se lance et la graine de « personnes qui ont dit oui » est petite mais réelle
  • Un programme outbound a travaillé l’ICP évident et l’équipe a besoin d’une deuxième vague informée par ce qui a closé, pas par ce que le fondateur imaginait initialement que l’ICP serait

Le skill suppose un compte Clay au plan Pro ou supérieur. En dessous du Pro, la surface d’enrichissement est trop étroite pour que la boucle lookalike soit utile, et vous vous retrouverez à payer pour un workflow qui fait à peu près ce que ferait une feuille de calcul plus une recherche LinkedIn.

Quand NE PAS l’utiliser

  • ABM Tier-1 comptes nommés. Les listes construites manuellement pour 25-50 comptes stratégiques impliquent des inputs de customer success et de direction que le skill ne peut pas modéliser. Utilisez-le pour l’outbound tier-2 et tier-3 ; la variance sur la boucle lookalike est trop élevée pour la sélection tier-1.
  • Chargement automatique dans des séquences outbound. L’output est un draft classé. Le skill écrit dans une table Clay et produit un rapport Markdown délibérément pour qu’un AE ou SDR doive l’examiner avant tout envoi. Si vous câblez l’output dans un déclencheur de séquence, vous utilisez ceci à mauvais escient.
  • Re-scoring de comptes déjà dans votre CRM. Utilisez un outil d’intention natif CRM pour ça. Ce skill écrit des candidats net-new ; il ne reclasse pas les connus.
  • Scoring sur des proxies de catégories protégées. Genre du fondateur, ethnicité du fondateur, alma mater, origine du nom — rien de tout ça n’appartient au rubric. Le fichier de rubric de référence énumère les dimensions autorisées ; n’en ajoutez pas d’autres.
  • Listes de graines de moins de huit comptes. Le skill refuse de procéder en dessous de huit graines valides car l’extraction de signature n’est pas fiable sur une base plus petite. Si vous n’avez que cinq victoires, construisez la liste manuellement et revenez quand vous en avez plus.

Configuration

Le bundle se trouve dans apps/web/public/artifacts/icp-account-list-builder-clay/ et contient :

  • SKILL.md — la définition du Claude Skill qui orchestre la boucle
  • references/1-icp-rubric-template.md — les portes firmographiques et les pondérations de signaux que vous remplissez pour votre équipe
  • references/2-signal-source-matrix.md — quelles sources publiques comptent comme primaires vs corroborant, et lesquelles sont explicitement interdites
  • references/3-exclusion-criteria.md — domaines bannis, sociétés mères et patterns firmographiques qui ne doivent jamais apparaître dans l’output

La configuration prend environ 45 minutes la première fois et 5 minutes à chaque rafraîchissement.

  1. Installez le Skill. Déposez SKILL.md dans votre répertoire Claude Skills (ou chargez-le via Claude Code avec /skill load). Remplissez references/1-icp-rubric-template.md avec vos vraies portes firmographiques, signaux technographiques et pondérations. Remplissez references/3-exclusion-criteria.md depuis un export CRM frais de clients, opportunités actives et comptes closed-lost des 180 derniers jours.
  2. Préparez la liste de graines. Un CSV avec company_name, domain et why_we_won (deux phrases). Extrayez les graines de plusieurs AE, segments et mois de clôture — le skill avertit si plus de 60 % des graines partagent un seul AE, secteur ou mois de clôture, car ça produit une liste qui ressemble au territoire d’un seul commercial.
  3. Connectez Clay. Le skill lit votre espace de travail Clay via API. Définissez l’ID d’espace de travail et la clé API dans la configuration locale du Skill (ne les committez jamais dans le bundle).
  4. Première exécution. Invoquez le skill avec votre CSV de graines et un target_list_size de 100. La première exécution est plus lente car l’univers firmographique n’est pas filtré ; les exécutions suivantes sur une vue Clay sauvegardée sont plus rapides.
  5. Revoyez le rapport Markdown et la table Clay ensemble. Le rapport explique la signature de graine, la répartition par type de signal et les décomptes de signalements d’exclusion. La table Clay est la surface de travail pour l’AE.

Ce que le skill fait réellement

Six étapes, dans l’ordre. L’ordre est important — exécuter le scoring LLM avant le filtre firmographique gaspille des crédits et inclut des inadéquations évidentes.

  1. Chargement et validation des inputs. Supprime les graines sans why_we_won et refuse d’exécuter sous huit graines valides.
  2. Extraction de la signature de graine. Envoie les graines et le rubric ICP à Claude, qui retourne une signature structurée : codes sectoriels, fourchette d’effectifs, fourchette de revenus, géographie, stade de financement, marqueurs technographiques et marqueurs d’intention. Les notes why_we_won encodent des signaux qui ne sont pas des colonnes Clay (« ils avaient une page sécurité et conformité ») ; c’est pourquoi un pass LLM est nécessaire avant le filtre déterministe.
  3. Application du filtre firmographique déterministe dans Clay. Traduit les portes strictes de la signature en filtres Clay et les exécute d’abord pour réduire l’univers à environ 500-3 000 candidats. Supprime tout ce qui est dans la liste d’exclusion à cette étape. Faire ça avant le scoring réduit le coût LLM d’environ 30-100x car la plupart des rejets sont des inadéquations firmographiques évidentes qui ne nécessitent aucun raisonnement.
  4. Enrichissement et corroboration des signaux d’intention. Pour chaque candidat restant, demande à Clay d’enrichir la stack technologique, les variations de recrutement et les annonces des 90 derniers jours, puis demande à Claude des scores de correspondance par signal avec citations. Tout signal d’intention unique nécessite un signal corroborant primaire — un changement d’emploi LinkedIn plus un communiqué de presse, par exemple. Les affirmations d’intention de source unique sont scorées à 0 avec la raison « uncorroborated » plutôt que devinées.
  5. Classement, dédoublonnage et écriture par lot dans Clay. Trie par score total, dédoublonne sur la colonne société mère, et écrit les target_list_size premières lignes dans une nouvelle table Clay en un seul batch. Les écritures par ligne brûlent des crédits et laissent un état incohérent en cas d’interruption ; les écritures par batch non.
  6. Production du rapport de sortie. Un document Markdown avec la signature de graine en tête, le tableau de candidats classé, une répartition par type de signal, les décomptes de signalements d’exclusion et les métadonnées d’exécution. Le réviseur lit ceci avant de travailler dans la table Clay.

Réalité des coûts

Les grands leviers de coût sont les crédits d’enrichissement Clay et les tokens Claude. Budgets approximatifs par exécution, ancrés sur un target_list_size de 100 contre un univers filtré firmographiquement de 1 800-2 200 candidats :

  • Tokens Claude (extraction de signature + scoring par candidat). Environ 500k-700k tokens d’entrée et 80k-120k tokens de sortie sur Claude Opus par exécution. Au tarif affiché d’Opus 4.7, ça atterrit autour de 9-14 $ par exécution. Sur Claude Sonnet, la même boucle est autour de 1,50-2,50 $ par exécution avec une perte de qualité mesurable sur l’étape d’extraction de signature (le raisonnement de pattern de graine bénéficie du modèle plus grand). Recommandation : Opus pour l’étape de signature, Sonnet pour l’étape de scoring par candidat.
  • Crédits Clay. Environ 800-1 000 crédits d’enrichissement par exécution pour un output de 100 lignes, supposant 2 000 candidats entrant dans l’étape d’enrichissement. Au tarif Clay Pro, c’est environ 24-30 $ de coût en crédits par exécution ; sur le niveau Explorer les crédits sont plus serrés et vous devriez baisser le target_list_size à 50 ou pré-filtrer plus fort.
  • À l’échelle. Une équipe exécutant ceci hebdomadairement par région (par exemple, quatre pods AE) arrive à environ 1 300-2 000 $ par mois combinés (150-200 $ de Claude, le reste en crédits Clay). C’est bien en dessous du coût d’un seul siège ZoomInfo SalesOS et produit une liste plus fraîche, mais ça requiert que le rubric et le fichier d’exclusion soient maintenus à jour — les inputs obsolètes sont là où le coût dérape (vous payez des crédits pour enrichir des comptes qui n’auraient jamais dû passer l’Étape 1).

Le pattern de dérapage de coût dominant est d’appeler le skill de manière répétée avec une porte firmographique lâche et regarder l’univers de candidats exploser. La garde est à l’Étape 3 : si Clay retourne plus de 5 000 candidats, le skill resserre une fourchette et ré-exécute plutôt qu’enrichir l’ensemble.

Métriques de succès

La métrique à observer est le taux auquel les AE acceptent le draft de liste dans leur set de travail sans retouche manuelle. Cible : 70 %+ accepté (c’est-à-dire que sur 100 candidats classés, au moins 70 atterrissent dans la file outbound de quelqu’un sans être supprimés ou réétiquetés). En dessous de 50 % d’acceptation, le rubric est faux, la liste de graines est biaisée, ou le fichier d’exclusion est obsolète — diagnostiquez dans cet ordre.

Secondaire : taux de réservation de réunion sur les comptes acceptés par rapport au taux de base outbound de l’équipe. Le skill amortit son coût en crédits quand ce taux est au moins égal au taux de base ; la valeur ajoutée est la réduction du temps de construction de liste, pas nécessairement une augmentation immédiate du taux de conversion.

Alternatives

  • vs LinkedIn Sales Navigator + filtrage manuel. Sales Nav est le bon outil pour les listes tier-1 construites manuellement et pour la prospection individuelle sur un candidat. C’est le mauvais outil pour produire 100 lookalikes classés chaque semaine — les filtres de recherche sauvegardée ne capturent pas les signaux d’intention, et le temps de filtrage manuel par liste est d’environ 3-5 heures d’une semaine SDR. Ce skill remplace ces 3-5 heures par 5 minutes de revue d’un draft classé.
  • vs ZoomInfo SalesOS Intent. SalesOS est mature, a de bonnes données d’intention sur les comptes entreprise, et est la bonne réponse si vous avez un mouvement entreprise et le budget pour 35k-80k $/an de sièges. Pour un mouvement mid-market dans une équipe plus petite, ce skill plus Clay Pro représente environ 80 % du signal à 5-10 % du coût, avec comme compromis que vous possédez le rubric et la liste d’exclusion plutôt que de vous fier au scoring du vendeur.
  • vs Apollo Living Data. La fonctionnalité lookalike d’Apollo est la plus proche en forme de ce skill et ne nécessite qu’un clic plutôt qu’une configuration de 45 minutes. Le scoring lookalike d’Apollo est opaque (vous ne pouvez pas voir les pondérations de signal ni les remplacer) et les outputs ont tendance à sur-indexer sur la similarité firmographique. Ce skill rend le rubric et les pondérations inspectables et impose la corroboration par signal ; le coût est le temps de configuration et l’obligation de maintenir les fichiers de référence à jour.
  • vs rien (statu quo, l’AE construit la liste). Les listes construites par les AE sont exhaustives sur les comptes connus de l’AE et faibles sur les lookalikes que l’AE n’a pas entendus parler. Ce skill est l’inverse — il est mauvais sur les comptes stratégiques nommés et bon pour faire remonter les 100 prochains lookalikes. Le pattern honnête est d’exécuter les deux en parallèle : l’AE possède la liste nommée, le skill produit le draft lookalike.

Points de vigilance

  • Données firmographiques de mauvaise qualité depuis des sources publiques. Les chiffres d’effectifs et de revenus des agrégateurs accusent un retard de 6-18 mois sur la réalité et sont erronés de 30-50 % sur les entreprises en phase de croissance. Protection : le skill traite toute source firmographique unique comme directionnelle et exige un accord entre deux sources indépendantes avant d’appliquer une porte stricte. Les conflits remontent dans le rapport de sortie (« LinkedIn dit 120, BuiltWith dit 380 — signalé pour revue manuelle ») plutôt que d’être résolus silencieusement.
  • Bruit des signaux d’intention. Un signal « a recruté un VP des Ventes » extrait de LinkedIn seul classe mal les promotions, rôles de conseil et inflation de titre comme nouvelles embauches nettes. Protection : l’Étape 4 exige un signal corroborant primaire (communiqué de presse, preuve LinkedIn sous un angle différent) avant qu’un signal d’intention score au-dessus de 0 ; les affirmations non corroborées sont scorées à 0 avec la raison enregistrée pour l’audit.
  • Empoisonnement de liste depuis des bases de données obsolètes. Certaines sources d’enrichissement Clay contiennent des entreprises zombies — acquises, fusionnées ou défuntes — qui passent les filtres mais ne peuvent pas acheter. Protection : supprimez tout candidat dont le site web retourne un 4xx/5xx sur la vérification de la page d’accueil, n’a aucune activité LinkedIn dans les 90 derniers jours, ou dont le champ société mère se résout en un acquéreur connu dans le fichier d’exclusion. Le décompte des suppressions apparaît dans les métadonnées d’exécution pour que l’opérateur puisse repérer un pic (signe de dégradation du fichier d’exclusion ou de la source d’agrégateur).
  • Biais de graine. Une liste de graines de 10 victoires d’un seul AE dans un seul secteur produit une liste qui ressemble au territoire de cet AE. Protection : le skill avertit si plus de 60 % des graines partagent le même AE, secteur ou mois de clôture, et demande à l’opérateur d’élargir la graine avant de continuer.
  • Sur-ajustement du filtre. Une signature si serrée qu’elle ne correspond qu’aux 14 graines produit 0-30 candidats et paraît précise mais est inutile. Protection : si l’Étape 3 retourne moins de 200 candidats, le skill élargit les fourchettes d’effectifs et de revenus d’un cran et ré-exécute plutôt que de procéder avec un univers affamé.
  • Fichier d’exclusion obsolète. Si l’export de la liste clients a deux mois, un client peut passer à travers et se retrouver en outbound. Protection : le skill avertit dans le rapport de sortie quand last_refreshed dans le fichier d’exclusion est plus vieux de 14 jours.

Stack

  • Clay (Pro ou supérieur) — substrat d’enrichissement, filtre firmographique et table de destination. Le Pro est le plancher pratique pour la boucle lookalike.
  • Claude (Opus 4.7 pour l’extraction de signature, Sonnet pour le scoring par candidat) — raisonnement de signature sur les notes why_we_won des graines et scoring de corroboration par signal avec citations. Diviser la sélection de modèle entre les deux étapes est là où le compromis coût-qualité atterrit le mieux.
  • CRM (n’importe lequel) — source de la liste de graines, liste clients, liste d’opportunités et liste closed-lost qui alimente le fichier d’exclusion. Le skill ne lit pas directement le CRM ; l’opérateur exporte des CSVs.
  • Destination outbound (Outreach, Salesloft, Apollo, personnalisée) — où va la liste revue après acceptation par l’AE. Le skill s’arrête à la table Clay par conception.

Files in this artifact

Download all (.zip)