Arquitectura de CRM: el problema no son las herramientas

Qué significa de verdad «arquitectura»

Llamamos a la empresa Architects a propósito. Las empresas no nos compran un CRM. Nos compran el diseño de cómo encajan sus sistemas. Ese diseño se reduce a cuatro preguntas:

1. Qué sistemas existen y para qué sirve de verdad cada uno.
2. Cómo se conectan entre sí.
3. Qué pasos hay dentro de cada sistema, y en qué orden.
4. Qué personas y equipos intervienen en cada paso.

Responded a esas cuatro con honestidad y la herramienta pasa a ser un detalle de implementación. Equivocaos en ellas y ninguna herramienta os salva. Esta es la línea que nos separa de los partners de HubSpot, las agencias de generación de leads y los integradores de ERP. Ellos venden una herramienta y heredan la arquitectura que ya tuvierais. Nosotros no estamos casados con ninguna herramienta: Clay, HubSpot, SAP, lo que venga después. Decide la arquitectura, no el proveedor.

Imaginad la empresa como un edificio

La forma más clara de ver vuestra propia operación es dibujarla como un edificio visto desde arriba y después hacerle un corte. Cuatro niveles.

Nivel 01, los equipos

Marketing, ventas, customer success, producción, finanzas. Cada uno ocupa su propia planta y hace su propio trabajo.

Nivel menos 01, el canal humano

Slack, email, reuniones, el pasillo. Aquí es donde las personas hablan entre sí. Es real, es necesario y es donde casi todo el mundo cree que de verdad funciona la empresa.

Nivel 02, los sistemas

CRM, base de datos de producción, ticketing, facturación o ERP. Aquí es donde las máquinas hablan entre sí. Los registros se mueven aquí.

Nivel 03, el registro maestro

Donde existe, una base de datos situada por encima de los sistemas que guarda la versión oficial de la verdad. Los sistemas sincronizan hacia ella y desde ella, de modo que cuando algo pasa en el mundo real cae en un solo sitio y se propaga a todos los demás.

Y ahora, lo importante. Los equipos empujan y tiran en vertical hacia su propio sistema. Los sistemas hablan en horizontal entre sí. Las personas hablan en horizontal entre sí. Nada cruza por sí solo entre la capa humana y la capa de máquinas.

Ese hueco es el fallo. Cuando ventas y marketing necesitan coordinarse, lo hacen por el canal humano, que parece comunicación y no deja ningún registro. Las máquinas que tienen encima nunca se enteran de que pasó algo. Marketing lanza una campaña, ventas no puede ver qué leads vinieron de ella y dos trimestres después nadie puede hacer un forecast porque la prueba de lo que pasó de verdad vivió y murió en un hilo de Slack. Dicho claro: una conversación no es un registro.

El error que mata el reporting sin hacer ruido

Cada dashboard que vais a querer depende de una sola cosa: ¿se escribieron en la capa de máquinas los eventos que importan? Si no, estáis reconstruyendo la historia de memoria, y la memoria no suma. Por eso «hazme un informe mejor» es casi siempre la petición equivocada. La parte difícil nunca es el informe. Son los datos y la lógica que lo alimentan.

La fuga es dinero real. Leads que nunca se enrutan, deals que se estancan porque nadie es su dueño, forecasts que fallan lo bastante como para tumbar un plan de contratación. Todo CRM se degrada en silencio, y nosotros cuantificamos esa degradación como ingresos en riesgo cada mes. Casi nunca es una partida de herramientas. Es arquitectura, apareciendo en la cuenta de resultados.

Qué sistema sirve a qué equipo

Una regla evita la mayor parte del desorden: el CRM sirve solo a los equipos comerciales. Marketing, ventas, customer success. Guarda lo que tiene que ver con clientes, y nada más.

Producción no pertenece al CRM y nunca hay que meterla a la fuerza. Funciona con su propia base de datos: materias primas en stock, compras hechas, unidades enviadas este mes. Esos datos no pintan nada en un CRM porque no tratan de un cliente. Los dos sistemas se unen por IDs, no por duplicación. El producto 85421 se vendió al cliente 248. Ese apretón de manos es la unión, y hacerlo bien es la mayor parte del trabajo en cualquier cuenta industrial.

Construimos exactamente esto para Elesa and Ganter, un fabricante industrial que trabaja con HubSpot junto a SAP: enrutado de tickets y propiedad por zona y código postal, lógica de SLA y escalado, números de teléfono normalizados a un único estándar y una escritura de vuelta limpia hacia SAP para que los dos sistemas siguieran sincronizados en lugar de pelearse. El resultado no es «un CRM más bonito». Son dos sistemas que por fin están de acuerdo sobre quién compró qué.

La identidad es la base, no un ajuste

Antes de que se mueva un solo registro, decidís qué es un registro y qué campo es la fuente de la verdad. Lo llamamos la jerarquía de identidad, y en una cuenta SaaS suele ir Stripe, luego Tenant, luego Domain, luego Name, en ese orden de confianza. Suena académico hasta que veis a una empresa intentar sumar sus propios ingresos y descubrir tres cosas a la vez: un registration_email y un billing_email que apuntan a dos «clientes» distintos, un Tenant ID y un Stripe Customer ID que nunca se reconciliaron, y los ingresos de los deals guardados como texto en lugar de números, así que no se pueden sumar. Nada de eso son bugs de la herramienta. Son decisiones de arquitectura que nunca se tomaron.

Por eso cada proyecto que hacemos tiene una barrera obligatoria llamada Client Approval on Data Model antes de conectar un solo workflow. Aprobáis las reglas de identidad, los objetos y cómo se relacionan, en un diagrama de flujo, en lenguaje llano, antes de que toquemos nada. Saltarse esa barrera es la manera de conseguir una construcción muy rápida de lo que no era.

Dónde encajan de verdad la IA y Clay

Los equipos ven Clay o un agente de IA y dan por hecho que es una arquitectura nueva. No lo es. Es un nuevo inquilino de una que ya existe. Clay se sienta junto al CRM en el nivel de sistemas y absorbe las tareas que los equipos comerciales hacían a mano: enriquecimiento, construcción de listas, scoring. Esas tareas salen de la planta humana y se convierten en un sistema adyacente. La forma del edificio no cambia. Decir esto en voz alta ahorra a los clientes el error más caro del mercado actual, que es comprar herramientas para tapar una arquitectura que nadie dibujó nunca.

Migrar es un problema de sistema operativo

El lift and shift copia el desorden en una casa nueva. Una migración es un problema de sistema operativo, no de transferencia de datos. Cuando pasamos a Tech Barcelona de Zoho a HubSpot, un proyecto que tocaba hasta cincuenta mil registros, no hicimos «exportar e importar». Primero rediseñamos el modelo de datos, hicimos el cambio por fases y lo envolvimos en gobernanza y validación de QA, porque el objetivo nunca fue trasladar los datos. Era cambiar lo que los datos significan a partir de ahora. Si migráis sin rehacer la arquitectura, habéis pagado por reproducir vuestros viejos problemas en un editor más caro.

Cómo auditar vuestra propia arquitectura en diez minutos

No vayáis a buscar «nuestra arquitectura». Casi nadie, directores incluidos, conoce la palabra en este sentido, y preguntarlo hace que la gente se sienta tonta. Haced una pregunta más sencilla: ¿cuál es vuestro proceso comercial? Un director de ventas que no sabe responder a eso es un pintor que no sabe nombrar su pintura, y el titubeo en sí ya es el primer diagnóstico.

Después recorredlo, paso a paso, y marcad cada rotura:

• ¿De dónde vienen los leads?
• ¿Quién los recoge, y cómo? («Ella los busca en Google» es manual. Marcadlo.)
• ¿Cómo se enriquecen? («No se enriquecen». Marcadlo.)
• ¿Cómo les hacéis scoring y cómo sabéis si algo es ICP? («No lo hacemos». Marcadlo.)
• ¿Qué pasa después de la reunión, y dónde queda registrado?
• Si marketing lanza algo, ¿dónde lo ve ventas?
• ¿Cómo hacéis el forecast del año que viene?

Esa última pregunta es la definitiva, sobre todo en empresas consolidadas que facturan entre 70 y 120 millones. La respuesta es casi siempre alguna versión de «más o menos, por lo que los clientes nos dicen que van a pedir, y lo tienen apuntado en algún sitio». Cada «marcadlo» es un punto donde la capa humana y la capa de máquinas no lograron conectarse. Contadlos. Ese total es vuestra arquitectura, la hayáis diseñado o no.

El cambio de enfoque

Un CRM os dice qué está pasando. No hace que nadie venda mejor, y no se va a diseñar solo. La herramienta que compráis es la última decisión, no la primera. Decidid para qué sirven vuestros sistemas, cómo se conectan y dónde vive la verdad. Después elegid el software que encaje. Hacedlo en ese orden y la discusión sobre la plataforma casi desaparece, porque cualquier herramienta competente puede sostener una buena arquitectura y ninguna puede rescatar una mala.

Si ya sospecháis que el cableado bajo vuestro CRM es el verdadero problema, para eso está pensado exactamente nuestro trabajo de CRM Foundation and Data Architecture . Dibujamos el edificio antes de construirlo, conseguimos vuestra aprobación del modelo de datos y después conectamos los sistemas para que la verdad caiga en un solo sitio y se propague. Empezad por vuestro proceso comercial. Todo lo que merece un informe depende de tenerlo sobre papel.