La teva factura de Clay no és un problema de preu. És un problema d’arquitectura.
Clay no és car. Enriquir sense arquitectura sí. Aquí tens la deduplicació, l’ordre de les waterfalls, l’enriquiment per nivells i els filtres d’email verificat que retallen la despesa de crèdits sense perdre cobertura.
Oriol Serra30 jul 2026 · 7 min de lectura
Cada poques setmanes algú em diu que Clay s’ha tornat massa car i que està pensant a treure’l. Gairebé cap té un problema de preu. Tenen un problema d’arquitectura. Van obrir l’eina, van començar a apilar columnes d’enriquiment, van arrossegar-hi tots els proveïdors que van trobar i van executar-ho sobre la taula sencera. Clay cobra crèdits per crida d’enriquiment. Fer clic sense rumb és, literalment, gastar diners.
La solució no és una eina més barata. És tractar l’enriquiment com un sistema amb una seqüència definida, filtres durs i controls de cost, en lloc d’un full de càlcul que remenes fins que apareixen emails. Aquesta és l’arquitectura que instal·lem per als clients, i els errors que està dissenyada per evitar.
La configuració per defecte és la configuració cara
La manera com la gent fa servir Clay tot just tret de la capsa és: una taula, tots els contactes, tots els proveïdors, executar-ho tot. Aquesta és la configuració més cara possible i normalment ni tan sols la més precisa. Un CRM sense dades enriquides és un Rolodex amb pretensions. Però enriquir-ho tot a cegues només vol dir que pagues preu complet per confirmar dades que ja tenies, sobre gent que mai no hauries contactat, amb proveïdors que no cobreixen el teu ICP.
Cinc canvis capgiren això.
Deduplica abans d’enriquir, no després
L’enriquiment més barat és el que no executes mai. Abans de gastar ni un crèdit, la llista es contrasta amb el que ja hi ha al CRM. Separem això en una Sources Table (només identificadors mínims, deduplicada primer) que alimenta una Data Table on passa l’enriquiment real. Aparella empreses per domini i contactes per email. Si el domini ja existeix a HubSpot, salta l’empresa sencera. Si l’email existeix, salta el contacte però conserva l’empresa si és nova.
En un build de mid-market el HubSpot del client ja tenia ~3.700 empreses i ~18.600 contactes. Enriquir una llista nova sense contrastar-la abans amb això hauria significat pagar per tornar a enriquir milers de registres que ja teníem. Deduplicar no és un pas de neteja que fas al final. És el primer filtre, i és gratis.
Ordena el teu waterfall per cost i taxa d’encert, i atura’t al primer encert
«Enriquiment en waterfall» es fa servir com si volgués dir «fes servir molts proveïdors». No és això. Un waterfall vol dir que els proveïdors s’executen en seqüència, i cadascun només es dispara si l’anterior va tornar buit. L’ordre importa enormement, perquè pagues per consulta. Posa primer el proveïdor més barat i amb millor taxa d’encert per al teu ICP concret, i atura’t en el moment que aconsegueixis un encert vàlid.
Vam fer una prova de cost controlada sobre una llista de retail de moda mid-market a Europa: sis contactes, waterfall complet. Els números ho expliquen millor que jo:
- PDL (People Data Labs): ~23,5 crèdits per al lot, 0 emails trobats per a aquell ICP. El més car, el pitjor rendiment.
- Hunter: ~1,5 crèdits, 4 de 6 emails trobats. El més barat, la millor taxa d’encert.
Executat a cegues, l’stack complet va cremar ~40 crèdits per a sis contactes. Ordenat correctament (el més barat i efectiu primer, aturar-se al primer encert) la mateixa feina surt per uns 5 a 15 crèdits per empresa. Una execució anterior amb un sol proveïdor i sense lògica de waterfall va costar 227 crèdits per a 25 comptes i 70 contactes. Les mateixes dades, un ordre de magnitud de diferència en despesa, purament per la seqüència.
La lliçó no és «Hunter bo, PDL dolent». És que el rendiment de cada proveïdor depèn de l’ICP, així que fes el benchmark sobre la teva pròpia llista, ordena per cost per encert i no deixis mai que un proveïdor car s’executi primer «per si de cas».
Descobriment enfront de revelació
La mateixa disciplina s’aplica al descobriment de persones. Fes servir el pas de cerca gratuït per trobar noms i URLs de LinkedIn; paga la revelació només sobre els registres que sobreviuen als teus filtres. Tracta certs proveïdors com a font només de noms i LinkedIn i no et refiïs dels seus emails ni telèfons per a la teva regió sense verificar-los. Un proveïdor excel·lent per a SaaS dels EUA pot ser gairebé inútil per a perfils d’operacions europeus.
Enriqueix per nivells, no per fila
No tots els registres mereixen la mateixa despesa. Abans de l’enriquiment profund, cada registre rep un nivell segons el seu encaix amb l’ICP: els mostrem al CRM com a Hot / Warm / Consider / Ignore, i el nivell viatja com a propietat per tot el pipeline. Els registres de nivell Ignore no reben el waterfall complet. Els de nivell Hot reben el tractament profund i més car perquè són els que els teus reps treballaran de debò.
Aquesta és la palanca més gran sobre el cost, perquè el comportament per defecte (enriquir tothom igual) gasta els teus crèdits més cars en els comptes amb menys probabilitat de convertir. Enriquir per nivells inverteix la proporció. El teu pressupost segueix el teu ICP en lloc del teu nombre de files.
Condiciona cada escriptura al CRM a un email verificat
Aquesta és una regla que no trenquem mai: res no s’escriu a HubSpot sense un email verificat. Enriquir no és verificar. La majoria de proveïdors et donen un email; no confirmen que sigui lliurable. L’enriquiment natiu de Clay troba l’adreça, i després un pas de verificació a part, amb LeadMagic, NeverBounce o ZeroBounce, la valida abans de deixar entrar res al CRM.
Salta’t això i no només tindràs dades brutes. Cremaràs la reputació d’enviament del client el dia que comenci amb outbound. Els emails sense verificar reboten, els rebots enfonsen el teu domini, i ara tota la motion rendeix per sota per un pas que algú es va saltar per estalviar cinc minuts. El filtre d’email verificat és una condició dura del pipeline, no un extra desitjable.
Mantén els senyals en brut fora de Clay, i després buida la taula
Clay és un banc de treball, no un magatzem. Deixar milers de files enriquides dins de les taules és alhora un cost i un risc. El nostre patró: enriquir, empènyer el registre net al CRM, escriure els senyals en brut en un magatzem fora de Clay (nosaltres fem servir Supabase, amb clau per URL de LinkedIn més canal d’origen) i després buidar la taula de Clay. Conserves cada senyal que vas pagar, la pots reutilitzar sense tornar a enriquir, i no pagues per emmagatzemar dades a l’eina menys indicada per fer-ho.
Baranes: topalls, columnes de validació i senyals honestos
Uns quants controls que eviten que el sistema sagni crèdits en silenci o lliuri escombraries:
- Topalls de despesa. Per a qualsevol execució gran, posa un topall dur al voltant del 150% del teu cost estimat. Evites la despesa descontrolada sense tallar de cop execucions legítimes.
- Columnes de validació. Porta camps de control explícits (size_valid, title_valid, region_valid) i marca qualsevol dada deduïda d’un patró d’email en lloc de confirmada. Un enriquiment dolent amb aire de segur és pitjor que no enriquir.
- Senyals honestos. Si un senyal de propensió (finançament, expansió, nou lideratge, una eina de la competència en ús) no es pot lligar a una font pública verificable, es marca com a desconegut, mai com a no, i mai com a sí sense una font a les notes. Un senyal que no pots defensar és soroll que estàs pagant per generar.
Com es veu quan està bé
En conjunt, l’arquitectura és avorrida en el millor sentit: deduplicar primer contra el CRM, executar un waterfall ordenat per ICP que s’atura al primer encert, gastar en profunditat només en els nivells alts, condicionar cada escriptura a un email verificat i emmagatzemar els senyals fora de l’eina. L’objectiu que ens exigim és més del 90% de cobertura en els camps que realment importen, amb una fracció de la despesa en crèdits de l’enfocament d’executar-ho tot.
La majoria dels problemes de GTM són sistemes trencats, no eines dolentes. Clay no és car. Enriquir sense arquitectura sí.
Arregla el sistema que gasta els crèdits i la factura s’arregla sola.
El nostre mòdul Data Enrichment & List Building instal·la exactament aquest pipeline (waterfalls ordenats per ICP, enriquiment per nivells i filtre d’email verificat) amb una garantia de més del 90% de cobertura de l’ICP. Si les vostres dades del CRM ja són un desastre a sota, comenceu per la neteja del CleanOps Protocol, o passeu la CRM Decay Calculator per veure què us estan costant al mes les dades dolentes.
Parlem de com hauria de ser realment la vostra despesa en enriquiment.
