El problema
El cliente tenía registros detallados de cliente a través de varios sistemas centrales operativos. Cada sistema usaba sus propios identificadores. Un solo cliente podía estar ligado a múltiples cuentas, compartir cuentas con otros clientes a través de relaciones conjuntas o de firmante autorizado, y pertenecer a una o más agrupaciones de hogar. Los equipos de marketing y servicio usaban un CRM para campañas, segmentación y reportes, pero los datos tenían que cargarse a mano. Eso significaba exportaciones CSV desde cada sistema central, reconciliación manual, deduplicación manual y cargas manuales al CRM en una rotación que nadie quería adueñarse. Cada carga introducía errores. Cada campaña construida sobre esos datos heredaba los errores. Cada excepción le costaba a alguien horas de limpieza.
El cliente quería que el trabajo manual desapareciera. Necesitaban una sincronización nocturna, automatizada y auditable que manejara correctamente las relaciones multi-parte, respetara las reglas de privacidad de datos y diera al equipo reportes claros de qué corrió, qué se sincronizó y qué falló.
El trabajo
El fundador de Alloy12 lideró el proyecto. El trabajo comenzó con un modelo de datos en el CRM que realmente pudiera representar la realidad del cliente, que era la parte difícil. El modelo de contacto por defecto del CRM asumía una persona, un registro, una cuenta. La realidad del cliente era muchas personas, muchas cuentas, muchos hogares, con relaciones muchos-a-muchos en todos lados e información de rol en cada relación (primario, conjunto, autorizado, etc.).
La solución entregada usó objetos personalizados en el CRM para personas, cuentas y hogares, con etiquetas de asociación y propiedades que capturaban el rol de cada relación. Un conjunto de scripts de middleware en Node.js corría de forma agendada. Cada script extraía de una tabla fuente específica en los sistemas centrales del cliente, resolvía llaves, revisaba asociaciones existentes en el CRM para evitar duplicados y creaba o actualizaba los enlaces faltantes vía el API batch del CRM. Limitación de tasa, backoff exponencial y logueo estructurado se construyeron desde el inicio, para que la carga pudiera correr a través de los límites de API del CRM sin intervención manual.
La validación pre-ejecución detectó problemas de columnas y esquema antes de que una carga empezara. Los guardias en tiempo de ejecución marcaron registros con llaves faltantes, capturaron errores de API y reintentaron fallas transitorias. La reconciliación post-ejecución produjo un conteo de registros enlazados, registros saltados con explicaciones y cualquier registro con error. Los runbooks documentaron cómo correr, revertir y reprocesar. Secretos y tokens de acceso se almacenaron en bóvedas encriptadas, los identificadores sensibles se enmascararon en los logs y las exportaciones se encriptaron en reposo.
Un proyecto separado de middleware manejó cargas basadas en CSV desde los sistemas centrales hacia una herramienta distinta de automatización de marketing, con lógica de agrupación y selección de fila representativa para cuentas que tenían múltiples entradas por cliente. Los mismos patrones aplicaron: observador de archivos, procesamiento automático al llegar un archivo, sincronización en lote y logueo estructurado.
Qué cambió
Las importaciones CSV manuales se detuvieron. La sincronización nocturna corrió sin intervención humana. Los equipos de marketing y servicio obtuvieron datos precisos y actualizados cada mañana con visibilidad clara de qué se sincronizó y qué necesitaba atención. La calidad de datos de la que dependían las campañas pasó a ser una propiedad del sistema en vez de una responsabilidad de una persona. El equipo recuperó las horas que gastaba en trabajo de CSVs y las movió a estrategia real de campañas y cliente.
Stack técnico
El trabajo combinó middleware ETL personalizado en Node.js, una capa de staging en PostgreSQL cuando aplicaba, una plataforma CRM con modelado de objetos personalizados, HubSpot v4 Associations API para gestión de relaciones, observadores de archivos para pipelines disparados por CSV, p-limit para concurrencia segura en tasa de llamadas, y reportes estructurados en JSON y CSV para auditoría.
Por qué esto importa para tu negocio
Toda empresa tiene este problema de alguna forma. Los sistemas centrales tienen la verdad. El CRM es donde pasa el trabajo. Mantenerlos sincronizados usualmente se resuelve con un ritual trimestral de hojas de cálculo que se rompe en el peor momento posible. Alloy12 construye la plomería que hace que la sincronización sea aburrida. Si tu equipo gasta tiempo significativo en trabajo manual de datos para mantener tu CRM usable, ese trabajo puede desaparecer en unas semanas.