Empresas matriz y filial en HubSpot y arquitectura de cuentas multientidad

Lo que HubSpot os da de verdad

Vale la pena ser precisos, porque casi toda la confusión viene de gente que espera un modelo de datos y recibe un campo.

Una empresa filial puede tener exactamente una matriz. Eso sirve para una estructura de holding limpia y falla en cuanto tenéis una sede que vende a dos divisiones, o un distribuidor que es a la vez cliente y canal. Las acciones nativas de workflow sobre matriz y filial son escasas, así que cualquier herencia que queráis (propietario, territorio, tier, SLA) hay que construirla a propósito. No baja sola por la jerarquía.

Y los reps leen el registro matriz como «todo lo de este grupo». No muestra casi nada a menos que construyáis la agregación. Así que la jerarquía se vincula, el registro matriz se queda vacío, la confianza muere y todo el mundo vuelve a preguntar en Slack.

Luego están las dos mecánicas que crean el lío en silencio desde el principio.

El dominio es el identificador único de las empresas al importar. El email para los contactos, el dominio para las empresas. La importación fusiona o sobrescribe cuando hay coincidencia en lugar de crear ambos. Eso significa que en cuanto importáis una lista de sedes que comparten un dominio corporativo, HubSpot las colapsa en un solo registro de empresa y nadie recibe un error. Vuestras tres plantas en tres países se han convertido en una fila, y la única prueba es un recuento de deals que parece ligeramente raro.

La creación y asociación automática de empresas se inventa registros a partir de los dominios de email. HubSpot lee el dominio del email de un contacto, fabrica una empresa y la asocia. Ese interruptor debería estar apagado en casi todos los portales que tocamos. Hemos visto cómo una integración de formularios de anuncios lo volvía a encender y llenaba un portal de cientos de empresas duplicadas en pocas semanas. Limpiar con el grifo abierto es teatro.

Tres problemas que parecen uno

«Tenemos empresas duplicadas» son tres problemas distintos con el mismo abrigo, y la solución de uno dañará los otros dos.

La misma entidad, dos veces. Una entidad legal, dos registros, el mismo dominio normalizado. Es un problema de coincidencia. Fusionadla.

Entidades distintas, un dominio. Acme Iberia y Acme France viven las dos en acme.com. Dos entidades legales, dos clientes en el ERP, posiblemente dos monedas, un dominio. Es un problema de modelado. Fusionadlas y habréis destruido información comercial real que alguien necesitará en la renovación.

La misma entidad, dominios distintos. Acme Group SL en acmegroup.es y la empresa operativa en acme.com. Es un problema de resolución, y es el que os castiga por adivinar. Nunca hacemos coincidir por nombre de empresa justo por esto: la coincidencia difusa por nombre suprime a Acme y le manda emails a Acme Group SL, así que las coincidencias por nombre se marcan para revisión en lugar de fusionarse automáticamente.

En el marco de fugas de ingresos que usamos en las auditorías, esto cae de lleno en la Fuga #2, calidad de datos y enrichment, y aflora como la Fuga #4, un CRM inflado con un pipeline del que nadie se fía. Es un problema de prevención, no de limpieza.

Decidid qué es un registro de empresa

Cuatro preguntas, respondidas por escrito, antes de que nadie vincule una matriz.

¿Un registro es una entidad legal, una sede o una unidad de compra? Elegid una y mantenedla. Las cuentas industriales y multisede casi siempre quieren la sede como registro, porque ahí viven el territorio, el SLA de servicio y la dirección de envío. Las cuentas de software suelen querer la entidad legal, porque ahí vive el contrato.

¿Cuál es la clave de unión? Escribid la jerarquía de identidad como una lista ordenada, no como folclore. La nuestra suele quedar así: ID de cliente de facturación o del ERP, luego ID de tenant, luego dominio normalizado, luego nombre. El nombre siempre se marca para revisión y nunca se fusiona automáticamente. Si los ingresos no se sincronizan, normalmente no es porque la integración se rompiera. Es porque dos sistemas usan como clave dos identidades distintas.

¿Qué registro es dueño de los ingresos? Un deal es un evento. Una empresa es el cliente. Si los ingresos se reflejan en el deal o en el contacto en lugar de en la empresa, las renovaciones y las ampliaciones se dispersan y ningún registro puede responder «cuánto vale este cliente».

¿Qué se agrega y qué no? Los ingresos se agregan. La supresión se agrega, porque la relación es con la empresa y no con el buzón. El propietario no se agrega. El territorio no se agrega. El SLA no se agrega. En los proyectos industriales esto lo es todo: en el proyecto de operaciones de servicio de Elesa+Ganter, la propiedad va por zona y código postal con SLA y escalado encima, lo que significa que el propietario vive en el registro de la sede y el registro del grupo no tiene por qué sobrescribirlo.

Ahí es también donde el apretón de manos por ID se gana el sueldo. La producción y el ERP se quedan en su propia base de datos, unidos al CRM por IDs en lugar de duplicados dentro de él. El producto 85421 se vendió al cliente 248. En una cuenta industrial, el apretón de manos es la mayor parte del trabajo. Escribimos más sobre esa separación en Arquitectura de CRM: vuestras herramientas no son el problema.

Cerrad el grifo y luego construid una única vía de creación

El orden de la limpieza importa más que la técnica de limpieza.

Apagad la autocreación nativa y confirmad que sigue apagada, revisando también lo que la encendió. Las integraciones de formularios de anuncios y los flujos de reserva de calendario son reincidentes, y la volverán a activar cuando hayáis terminado.

Después buscad vuestros huérfanos, porque apagar la autocreación abre un hueco nuevo. En un proyecto, la creación de empresas solo pasaba por la vía de outbound en Clay. Todas las demás vías de entrada (reservas de reuniones, formularios, creación manual) generaban contactos con dominios de empresa perfectamente válidos y ninguna empresa asociada. La solución fue un único workflow que se encarga de la asociación de empresas sea cual sea la vía de entrada: inscribir con un dominio de empresa válido más un tipo de cuenta real más ninguna empresa asociada, buscar el dominio, asociar a la empresa canónica si existe, crearla si no existe y dejarla en revisión manual si el dominio es genérico o compartido.

La parte innegociable: lo que sea que cree empresas tiene que usar la misma normalización de dominios y la misma lógica de selección de empresa canónica que todo lo demás. Si Clay normaliza los dominios de una manera y vuestro workflow de HubSpot de otra, no tenéis un modelo de empresas. Tenéis dos. Más sobre cómo mantenerlos alineados en Cómo sincronizar Clay con HubSpot sin destrozar vuestro CRM.

Fusionad sin destruir la jerarquía

Nuestra deduplicación de empresas va por niveles, con paradas duras, y se ejecuta después de los contactos.

Primero contactos, luego empresas. Siempre. Pasar una ronda de empresas sobre contactos desalineados destroza las asociaciones.

El nivel 1 es el dominio normalizado exacto y el nivel 2 es nombre más raíz del dominio, y esos se fusionan automáticamente. Los niveles 3 a 5 los valida la IA y los revisa una persona antes de que se escriba nada. Las escrituras siguen dependiendo de un botón. Nadie lo pone en ejecución automática.

Las paradas duras son la parte interesante, porque son justo las protecciones multientidad:

• Nunca fusionéis entre dos dominios rellenos y distintos.
• Un desajuste de ID de facturación o de tenant es una parada total. Nunca se fusionan dos clientes que pagan en un solo registro.
• Los conflictos de propietario se marcan y se resuelven a propósito, porque una fusión mueve una empresa de un rep a otro y reescribe la atribución en silencio.
• Los registros ya marcados para borrar nunca entran en la lógica de niveles.

Exportad antes de fusionar. La tabla de restauración es una red de seguridad, no una garantía. Validad el resultado con una muestra del diez por ciento.

Un detalle operativo que sorprende: los grupos de tres o más duplicados no se colapsan en una sola pasada. La fusión gestiona un par principal y secundario cada vez, así que volvéis a resolver los IDs canónicos contra el registro que sobrevive y lo ejecutáis otra vez, y otra, hasta que el grupo desaparece. Después pasad una ronda de colisiones posfusión en este orden: dominio, nombre estricto, nombre flexible. Un duplicado residual tras una pasada significa que el grupo era grande, no que algo se haya roto.

Y la regla permanente: marcar para revisión antes que forzar la fusión. Una fusión insegura que sobrescribe los datos de primer contacto es peor que una coincidencia perdida.

Construid la agregación o la jerarquía es decoración

El registro matriz responde «cuánto vale este cliente» solo si lo hacéis responder. Nada se agrega solo.

Construid propiedades a nivel de grupo en la matriz: ingresos totales del grupo, pipeline abierto de todas las filiales, número de entidades o sedes y último contacto relevante en cualquier punto del grupo. Después reportad en los dos niveles a propósito. Los informes de deals y de servicio van en el registro de la sede, donde ocurre el trabajo. Los informes de ingresos y renovaciones van en el registro del grupo, donde está el dinero.

Cuando migréis los ingresos fuera de los campos equivocados para hacer esto, ocultad las propiedades antiguas y demostrad la paridad de los informes contra la exportación antes de borrar nada. El orden de retirada es ocultar, demostrar y después borrar.

Cómo se ve cuando está bien

Podéis responder, sin abrir una hoja de cálculo: cuánto vale este grupo, a cuántas entidades vendemos, quién es el propietario de cada sede y qué registro es el único cliente verdadero. Las empresas nuevas entran por exactamente una vía con un único estándar de normalización. Dos entidades en un dominio siguen siendo dos registros a propósito, y hay un motivo escrito. Y nadie en vuestro equipo tiene que preguntar en Slack si el registro de Acme es el bueno.

Si la respuesta honesta es que no sabéis cuántos registros de empresa tenéis para vuestra cuenta más grande, eso es una fuga con un número asociado, no un problema de orden. Nuestra Auditoría de fugas de ingresos la cuantifica, y el módulo de Fundamentos de CRM y Arquitectura de datos es donde reconstruimos el modelo de cuentas como es debido. Empezad por el que os dé antes un número honesto.