Com sincronitzar Clay amb HubSpot sense destrossar el CRM

El vostre CRM és un sistema de registre, no un esborrany

Clay és un banc de treball. Està pensat per ser caòtic: files mig enriquides, errors de proveïdors, valors endevinats, columnes que vau crear per provar una hipòtesi i vau oblidar esborrar. No passa res, perquè Clay és d’un sol ús. HubSpot no ho és. HubSpot és la columna vertebral de la qual pengen els vostres reps, el vostre enrutament, el vostre scoring i el vostre reporting. Tot el que hi cau ho fa servir una persona o una automatització en qüestió d’hores.

Així que la primera decisió no és «com connecto Clay amb HubSpot». És «quin és el conjunt de camps més petit i net que HubSpot necessita de debò, i en quines condicions es deixa passar una fila». Cada regla d’aquí sota és una condició d’aquesta porta.

Regla 1: res s’escriu a HubSpot sense un email verificat

És la regla que més mal evita, i és la que més gent se salta perquè sembla agressiva. L’anomenem la porta de l’email verificat: cap fila s’escriu a HubSpot si l’email no ha passat la verificació, no n’hi ha prou d’haver-lo trobat.

Un email trobat és una suposició. Un email verificat és lliurable. Són objectes diferents i només un mereix ser al vostre CRM. Si envieu emails trobats però sense verificar, passen tres coses aigües avall. La vostra taxa de rebot puja i crema els vostres dominis d’enviament. Els vostres reps perden el temps amb registres que mai van ser abastables. I el vostre reporting menteix sense fer soroll, perquè «contactes creats» ara inclou contactes que no existeixen.

A la pràctica és una sola columna condicional al final de la vostra taula de Clay: només les files amb email_status = verified es poden sincronitzar. Tota la resta es queda a Clay, mai arriba al CRM i mai us costa una creació malbaratada. Si la font és un proveïdor com Apollo, tracteu-ne els emails i els telèfons com a no verificats per a qualsevol ICP fora dels Estats Units i retingueu-los darrere la porta fins que un pas de verificació els deixi passar.

Regla 2: dedupliqueu a Clay, perquè HubSpot estructuralment no pot

No confieu que HubSpot enxampi els vostres duplicats en entrar. No pot, i entendre per què és la clau de tot.

HubSpot només detecta contactes duplicats per la propietat d’email i pel seu propi ID intern de registre. No ofereix lògica de matching personalitzada i no avisa els vostres reps quan creen a mà un registre que ja existeix. Internament ho diem sense embuts: HubSpot no té un problema de duplicats, té un problema de matching que no us deixen arreglar. Així que si dues files de Clay corresponen a la mateixa persona amb dos emails diferents, HubSpot les crearà totes dues tan tranquil.

La solució és deduplicar aigües amunt, a Clay, abans que se sincronitzi res. Munteu una Sources Table amb identificadors mínims i dedupliqueu-hi primer, després enriquiu i després torneu a deduplicar a la vostra Final Table contra una identitat canònica (domini per a empreses, email verificat o una clau composta per a persones) abans de l’enviament. Configureu la mateixa sincronització perquè faci matching per email als contactes i per domini a les empreses, i trieu «update existing» en lloc de «create new», perquè una coincidència repari un registre en comptes de clonar-lo. La deduplicació no és una neteja que es fa després. És una condició prèvia de la sincronització.

Regla 3: sincronitzeu el nivell, no només el contacte

Un contacte sense prioritat és un contacte que el vostre equip ha de tornar a classificar a mà. Per això mai sincronitzem una persona sense més. El nivell viatja com una propietat del registre. És el patró d’enrichment per nivells: l’encaix i la intenció es puntuen a Clay i arriben a HubSpot com a camps, així que tan bon punt un contacte existeix ja sap quant val.

En concret, puntuem encaix i intenció com dos números separats (l’encaix és un ICP_score construït a partir de sector, mida, rol i encaix tecnològic), mai un únic score barrejat, i mostrem al registre un nivell llegible per persones: Hot, Warm, Consider o Ignore. Aquest nivell és el que llegeixen l’enrutament i el reporting. Un registre Hot pot disparar un SLA d’enrutament de 5 minuts. Un registre Ignore es pot crear i aparcar sense arribar mai a un rep. La mateixa sincronització, un cost aigües avall completament diferent, i la diferència és una propietat que vau decidir fer creuar la porta.

Regla 4: prepareu els vostres camps, no sobreescriviu els principals

Cada camp que sincronitzeu és una incorporació permanent al vostre model de dades, i un CRM inflat (sovint hi trobem més de 80 propietats que ningú llegeix) és en si mateix una fuita. Així que sigueu implacables amb el que creua i prepareu com aterra.

Escriviu primer els valors enriquits en camps personalitzats amb un espai de noms clar. Poseu-los un prefix perquè el seu origen sigui evident (per exemple, el prefix Clay_) i passeu un valor a un camp principal del CRM només quan superi un llindar de confiança i les vostres regles de propietat ho permetin. Aquest pas intermedi és el que impedeix que un enrichment de baixa confiança sobreescrigui en silenci un valor que un rep va introduir a mà. Ja posats, mapegeu els tipus amb exactitud: text enviat a una propietat desplegable, una data en el format equivocat o un número escrit en un camp de text d’una línia fallen en silenci i corrompen el camp per a tothom. Envieu primer de 10 a 20 registres i reviseu-los a HubSpot abans de llançar la llista completa.

Regla 5: deixeu els senyals en brut completament fora del CRM

No tot el que heu reunit a Clay són dades de CRM. Gran part és senyal en brut: marques de propensió, resultats de scraping, les catorze columnes intermèdies que vau necessitar per arribar a un veredicte. Res d’això pertany a HubSpot, on inflaria el model i confondria qualsevol persona que obri el registre.

El nostre patró és enviar a HubSpot només el registre net i llest per decidir, i escriure els senyals en brut en un magatzem fora del CRM (fem servir Supabase, amb la URL de LinkedIn més el canal d’origen com a clau), i després esborrar-los de Clay per controlar el cost en crèdits. HubSpot es queda amb el veredicte. El magatzem guarda les proves. Tots dos continuen units per un ID, no copiant-ho tot al CRM i esperant que continuï ordenat.

Regla 6: la sincronització es trencarà en silenci, així que munteu l’alarma

Aquesta és la part que gairebé ningú construeix, i és la que al final surt més cara. Les sincronitzacions i els webhooks no fallen amb estrèpit. Fallen en silenci, i l’informe continua carregant, així que ningú se n’adona fins que el número surt malament en una revisió de pipeline.

Ho hem viscut. En un projecte, algú que tocava un ajust que no hi tenia res a veure va esborrar un webhook que alimentava Clay amb respostes, i va passar un mes sense que ningú veiés el forat. No va saltar cap error. Les dades simplement van deixar d’arribar. La lliçó és que una sincronització que no podeu veure és una sincronització de la qual no us podeu refiar.

Per això muntem un control de salut automàtic setmanal (fem servir n8n) que mapeja les dades clau, confirma que aquella setmana registres nous van creuar de debò la porta i marca qualsevol trencament per a revisió manual. I el principi que mana quan alguna cosa no coincideix netament: marqueu el registre per a revisió en lloc de forçar la fusió, perquè una fusió insegura que sobreescriu una data de primer toc és pitjor que una coincidència perduda. Comproveu que les canonades funcionen, no només que el dashboard continua carregant.

La versió curta

Si voleu una checklist per contrastar la vostra pròpia sincronització, són sis portes: verifiqueu l’email abans d’escriure res; dedupliqueu a Clay perquè HubSpot no pot; feu creuar el nivell com a propietat; prepareu els camps enriquits abans de passar-los als principals; guardeu els senyals en brut en un magatzem fora del CRM; i poseu una alarma setmanal sobre tot el conjunt perquè no es pugui trencar en silenci.

Res d’això va de Clay contra HubSpot. Va de decidir, expressament, què pot contenir el vostre sistema de registre. Encerteu l’arquitectura i les eines són un detall. Equivoqueu-vos i cap ajust del connector us salvarà.

Si la vostra sincronització de Clay a HubSpot és ara mateix una canonada i noteu que el CRM comença a podrir-se, aquest és exactament el forat que tanca el nostre mòdul Data Enrichment and List Building, i és la columna vertebral del projecte CRM Spine System. Instal·lem la porta una vegada perquè el vostre CRM deixi d’omplir-se de dades de les quals no us podeu refiar.