Cómo sincronizar Clay con HubSpot sin destrozar el CRM

Vuestro CRM es un sistema de registro, no un borrador

Clay es un banco de trabajo. Está pensado para ser caótico: filas a medio enriquecer, errores de proveedores, valores adivinados, columnas que creasteis para probar una hipótesis y olvidasteis borrar. No pasa nada, porque Clay es desechable. HubSpot no lo es. HubSpot es la columna vertebral de la que cuelgan vuestros reps, vuestro enrutamiento, vuestro scoring y vuestro reporting. Todo lo que cae ahí lo usa una persona o una automatización en cuestión de horas.

Así que la primera decisión no es «cómo conecto Clay con HubSpot». Es «cuál es el conjunto de campos más pequeño y limpio que HubSpot necesita de verdad, y en qué condiciones se deja pasar una fila». Cada regla de abajo es una condición de esa puerta.

Regla 1: nada se escribe en HubSpot sin un email verificado

Es la regla que más daño evita, y es la que más gente se salta porque parece agresiva. La llamamos la puerta del email verificado: ninguna fila se escribe en HubSpot si el email no ha pasado la verificación, no basta con haberlo encontrado.

Un email encontrado es una suposición. Un email verificado es entregable. Son objetos distintos y solo uno merece estar en vuestro CRM. Si enviáis emails encontrados pero sin verificar, pasan tres cosas aguas abajo. Vuestra tasa de rebote sube y quema vuestros dominios de envío. Vuestros reps pierden el tiempo con registros que nunca fueron alcanzables. Y vuestro reporting miente sin hacer ruido, porque «contactos creados» ahora incluye contactos que no existen.

En la práctica es una sola columna condicional al final de vuestra tabla de Clay: solo las filas con email_status = verified pueden sincronizarse. Todo lo demás se queda en Clay, nunca llega al CRM y nunca os cuesta una creación desperdiciada. Si la fuente es un proveedor como Apollo, tratad sus emails y teléfonos como no verificados para cualquier ICP fuera de Estados Unidos y retenedlos detrás de la puerta hasta que un paso de verificación los deje pasar.

Regla 2: deduplicad en Clay, porque HubSpot estructuralmente no puede

No confiéis en que HubSpot pille vuestros duplicados al entrar. No puede, y entender por qué es la clave de todo.

HubSpot solo detecta contactos duplicados por la propiedad de email y por su propio ID interno de registro. No ofrece lógica de matching personalizada y no avisa a vuestros reps cuando crean a mano un registro que ya existe. Internamente lo decimos sin rodeos: HubSpot no tiene un problema de duplicados, tiene un problema de matching que no os dejan arreglar. Así que si dos filas de Clay corresponden a la misma persona con dos emails distintos, HubSpot creará las dos tan tranquilo.

La solución es deduplicar aguas arriba, en Clay, antes de que se sincronice nada. Montad una Sources Table con identificadores mínimos y deduplicad ahí primero, después enriqueced y después volved a deduplicar en vuestra Final Table contra una identidad canónica (dominio para empresas, email verificado o una clave compuesta para personas) antes del envío. Configurad la propia sincronización para que haga matching por email en los contactos y por dominio en las empresas, y elegid «update existing» en lugar de «create new», para que una coincidencia repare un registro en vez de clonarlo. La deduplicación no es una limpieza que se hace después. Es una condición previa de la sincronización.

Regla 3: sincronizad el nivel, no solo el contacto

Un contacto sin prioridad es un contacto que vuestro equipo tiene que volver a clasificar a mano. Por eso nunca sincronizamos a una persona sin más. El nivel viaja como una propiedad del registro. Es el patrón de enrichment por niveles: el encaje y la intención se puntúan en Clay y llegan a HubSpot como campos, así que en cuanto un contacto existe ya sabe cuánto vale.

En concreto, puntuamos encaje e intención como dos números separados (el encaje es un ICP_score construido a partir de sector, tamaño, rol y encaje tecnológico), nunca un único score mezclado, y mostramos en el registro un nivel legible por personas: Hot, Warm, Consider o Ignore. Ese nivel es lo que leen el enrutamiento y el reporting. Un registro Hot puede disparar un SLA de enrutamiento de 5 minutos. Un registro Ignore puede crearse y aparcarse sin llegar nunca a un rep. La misma sincronización, un coste aguas abajo completamente distinto, y la diferencia es una propiedad que decidisteis hacer cruzar la puerta.

Regla 4: preparad vuestros campos, no sobrescribáis los principales

Cada campo que sincronizáis es una incorporación permanente a vuestro modelo de datos, y un CRM inflado (encontramos a menudo más de 80 propiedades que nadie lee) es en sí mismo una fuga. Así que sed implacables con lo que cruza y preparad cómo aterriza.

Escribid primero los valores enriquecidos en campos personalizados con un espacio de nombres claro. Ponedles un prefijo para que su origen sea evidente (por ejemplo, el prefijo Clay_) y pasad un valor a un campo principal del CRM solo cuando supere un umbral de confianza y vuestras reglas de propiedad lo permitan. Ese paso intermedio es lo que impide que un enrichment de baja confianza sobrescriba en silencio un valor que un rep introdujo a mano. Ya puestos, mapead los tipos con exactitud: texto enviado a una propiedad desplegable, una fecha en el formato equivocado o un número escrito en un campo de texto de una línea fallan en silencio y corrompen el campo para todo el mundo. Enviad primero de 10 a 20 registros y revisadlos en HubSpot antes de lanzar la lista completa.

Regla 5: dejad las señales en bruto completamente fuera del CRM

No todo lo que habéis reunido en Clay son datos de CRM. Gran parte es señal en bruto: marcas de propensión, resultados de scraping, las catorce columnas intermedias que necesitasteis para llegar a un veredicto. Nada de eso pertenece a HubSpot, donde inflaría el modelo y confundiría a cualquier persona que abra el registro.

Nuestro patrón es enviar a HubSpot solo el registro limpio y listo para decidir, y escribir las señales en bruto en un almacén fuera del CRM (usamos Supabase, con la URL de LinkedIn más el canal de origen como clave), y después borrarlas de Clay para controlar el coste en créditos. HubSpot se queda con el veredicto. El almacén guarda las pruebas. Los dos siguen unidos por un ID, no copiándolo todo en el CRM y esperando que siga ordenado.

Regla 6: la sincronización se romperá en silencio, así que montad la alarma

Esta es la parte que casi nadie construye, y es la que al final sale más cara. Las sincronizaciones y los webhooks no fallan con estruendo. Fallan en silencio, y el informe sigue cargando, así que nadie se da cuenta hasta que el número sale mal en una revisión de pipeline.

Lo hemos vivido. En un proyecto, alguien que tocaba un ajuste que no tenía nada que ver borró un webhook que alimentaba Clay con respuestas, y pasó un mes sin que nadie viera el hueco. No saltó ningún error. Los datos simplemente dejaron de llegar. La lección es que una sincronización que no podéis ver es una sincronización de la que no os podéis fiar.

Por eso montamos un chequeo de salud automático semanal (usamos n8n) que mapea los datos clave, confirma que esa semana registros nuevos cruzaron de verdad la puerta y marca cualquier rotura para revisión manual. Y el principio que manda cuando algo no coincide limpiamente: marcad el registro para revisión en lugar de forzar la fusión, porque una fusión insegura que sobrescribe una fecha de primer toque es peor que una coincidencia perdida. Comprobad que las tuberías funcionan, no solo que el dashboard sigue cargando.

La versión corta

Si queréis una checklist para contrastar vuestra propia sincronización, son seis puertas: verificad el email antes de escribir nada; deduplicad en Clay porque HubSpot no puede; haced cruzar el nivel como propiedad; preparad los campos enriquecidos antes de pasarlos a los principales; guardad las señales en bruto en un almacén fuera del CRM; y poned una alarma semanal sobre todo el conjunto para que no pueda romperse en silencio.

Nada de esto va de Clay contra HubSpot. Va de decidir, a propósito, qué puede contener vuestro sistema de registro. Acertad con la arquitectura y las herramientas son un detalle. Equivocaos y ningún ajuste del conector os salvará.

Si vuestra sincronización de Clay a HubSpot es ahora mismo una tubería y notáis que el CRM empieza a pudrirse, ese es exactamente el hueco que cierra nuestro módulo Data Enrichment and List Building, y es la columna vertebral del proyecto CRM Spine System. Instalamos la puerta una vez para que vuestro CRM deje de llenarse de datos de los que no os podéis fiar.