La arquitectura de un CRM personalizado debe representar cómo trabaja la empresa, no solo dónde guarda los contactos. Para que el sistema sea útil y mantenible, hay que definir qué información es común, qué procesos pertenecen a cada área y cómo se conectará con el resto de aplicaciones. Esa estructura condiciona tanto las tareas cotidianas —por ejemplo, asignar una oportunidad— como los cambios futuros.
Un CRM (gestor de relaciones con clientes) puede construirse como una aplicación modular, con una base de datos común y límites claros entre funciones. No hace falta empezar con microservicios ni diseñar una plataforma compleja: la decisión adecuada depende del volumen, las integraciones, los equipos que desarrollarán el producto y la velocidad a la que cambian los procesos.
Separar el modelo de negocio de las pantallas
Una interfaz muestra información y permite actuar sobre ella, pero no debería ser la única definición de las reglas del CRM. Si la lógica de asignación de clientes está escondida en un formulario, una futura aplicación móvil o una integración podría aplicar reglas distintas. Por eso, la arquitectura suele separar la presentación, las reglas de negocio y el acceso a los datos.
Una estructura por responsabilidades
- Interfaz: pantallas web o móviles, búsquedas, formularios y vistas adaptadas a cada perfil.
- Aplicación: operaciones como crear una oportunidad, registrar una interacción o cambiar un cliente de responsable.
- Dominio: entidades y reglas del negocio, por ejemplo, qué condiciones debe cumplir una oportunidad para pasar a una fase determinada.
- Persistencia: almacenamiento, consultas, transacciones y migraciones de datos.
- Integraciones: intercambio de información con correo, facturación, soporte u otras herramientas.
Esta separación no exige que cada responsabilidad viva en un servidor distinto. En una primera versión, todas pueden formar parte de una aplicación modular desplegada como una sola unidad. Lo importante es que los módulos no dependan de detalles internos de otros sin una razón clara.
Diseñar los datos alrededor de las relaciones reales
Un modelo inicial podría incluir empresas, personas, oportunidades, actividades y usuarios. La dificultad está en precisar sus relaciones. Una persona puede trabajar para una empresa; una oportunidad puede implicar a varias personas; una actividad puede estar relacionada con una oportunidad o con una cuenta. Si se asume que cada contacto solo pertenece a una empresa, ese supuesto puede convertirse en una limitación difícil de corregir.
Identificadores, historial y datos duplicados
Cada entidad necesita una identidad estable, independiente de campos que pueden cambiar, como el correo electrónico o el nombre de una empresa. Las integraciones también requieren conservar el identificador que utiliza cada sistema externo. Así se puede relacionar un registro del CRM con su equivalente en otra aplicación sin depender de coincidencias aproximadas.
También hay que distinguir entre el estado actual y el historial. Si se sobrescribe el responsable de una oportunidad, se pierde la posibilidad de saber quién la gestionaba antes. Un registro de cambios o una entidad de asignaciones con fechas permite reconstruir esa evolución. No todas las modificaciones necesitan el mismo nivel de detalle: el historial de propiedad, consentimiento o importe puede ser más importante que registrar cada ajuste visual.
En un ejemplo hipotético, una empresa quiere saber qué campaña originó una oportunidad y qué interacciones precedieron a su conversión. Guardar únicamente el nombre de la campaña como texto libre en la oportunidad dificulta comparar resultados. Una relación con una entidad de campañas y actividades vinculadas permite consultar la atribución sin depender de variaciones en la escritura.
Convertir los procesos comerciales en reglas explícitas
Antes de programar automatizaciones, hay que describir qué inicia cada proceso, quién puede ejecutarlo, qué condiciones lo bloquean y qué resultado queda registrado. «Avisar al comercial» no especifica por sí solo si el aviso debe enviarse al crear la oportunidad, cuando se acerca una fecha o si faltan datos para avanzar.
Una regla concreta podría ser: cuando una oportunidad pasa a «propuesta enviada», el sistema guarda la fecha del cambio y crea una tarea de seguimiento para la persona responsable. La arquitectura debe decidir si esa operación se realiza en una única transacción y qué ocurre si falla la creación de la tarea. Si una parte se completa y otra no, el CRM puede mostrar un estado incoherente.
Para automatizaciones sencillas, las reglas pueden residir en el módulo que gestiona las oportunidades. Si los procesos se vuelven configurables por usuarios de negocio o tienen muchos pasos y excepciones, puede justificarse un componente específico de flujos. Añadirlo desde el principio, sin procesos que lo necesiten, aumenta la complejidad de configuración y de pruebas.
Elegir una arquitectura que encaje con la escala
Una aplicación monolítica modular suele ser una opción razonable cuando un equipo desarrolla y despliega el CRM como un producto coordinado. Facilita las transacciones entre módulos y evita distribuir prematuramente las operaciones. Sus límites aparecen si los módulos quedan muy acoplados, si las entregas de distintas áreas se bloquean entre sí o si hay necesidades operativas muy diferentes.
Los microservicios separan módulos en procesos desplegables de forma independiente, pero introducen comunicación de red, observabilidad distribuida y consistencia eventual en ciertos flujos. No resuelven por sí mismos un modelo de datos confuso. Para un CRM con pocos equipos y cambios coordinados, el coste de esa separación puede superar su beneficio; para áreas con ritmos de despliegue y responsabilidades realmente independientes, puede ser una alternativa.
Una decisión intermedia consiste en mantener una aplicación modular y extraer un servicio solo cuando exista un motivo medible: carga diferenciada, aislamiento operativo, propiedad clara de un equipo o una integración que necesite escalar por separado. El módulo extraído debe tener una frontera de datos definida. Si ambos componentes escriben directamente en las mismas tablas, la separación suele ser más aparente que real.
Integrar sin convertir el CRM en una colección de dependencias
Las conexiones con correo, facturación, soporte o herramientas de marketing requieren decidir qué sistema es responsable de cada dato. Por ejemplo, el CRM puede ser el origen de los datos comerciales mientras que la aplicación de facturación gestiona facturas y cobros. Si ambos sistemas permiten modificar el mismo campo sin una regla de prioridad, aparecerán discrepancias difíciles de resolver.
Para llamadas iniciadas por otra aplicación, una API (interfaz de programación de aplicaciones) puede exponer operaciones controladas, como consultar una cuenta o registrar una actividad. Para notificar cambios, los eventos o webhooks evitan que cada sistema tenga que consultar continuamente si hay novedades. La elección depende de si el consumidor necesita una respuesta inmediata, recibir cambios o recuperar información de forma periódica. El desarrollo de APIs debe contemplar también autenticación, validación, límites de uso y versiones compatibles.
Las integraciones asíncronas suelen necesitar una cola de mensajes o un mecanismo equivalente. Si el servicio de correo no responde, el CRM puede conservar el trabajo pendiente y reintentarlo, en lugar de bloquear la operación del usuario. Para evitar duplicados, cada operación debe poder reconocerse, por ejemplo, mediante un identificador idempotente: al recibir de nuevo la misma solicitud, el sistema no crea dos actividades.
Permisos, privacidad y mantenimiento desde el diseño
Los permisos deberían corresponder a acciones y datos: ver una cuenta, editar una oportunidad, exportar contactos o administrar usuarios no son necesariamente el mismo privilegio. Un control por roles puede cubrir perfiles habituales, mientras que restricciones por equipo, cartera o territorio añaden alcance cuando el negocio lo requiere. Las comprobaciones deben aplicarse en el servidor, no solo ocultando botones en la interfaz.
El registro de auditoría ayuda a responder quién cambió un dato y cuándo. También hace falta separar ese registro de los eventos técnicos de diagnóstico: los registros de errores no deberían almacenar indiscriminadamente información personal que no necesitan para investigar una incidencia. Las políticas de conservación y acceso deben definirse según el uso y las obligaciones aplicables al proyecto, no dejarse al comportamiento por defecto de cada herramienta.
El mantenimiento forma parte de la arquitectura. Migraciones versionadas permiten cambiar el esquema de forma controlada; pruebas automatizadas protegen las reglas críticas, como el cálculo de asignaciones; y métricas sobre errores de integración ayudan a detectar datos que no llegan a su destino. Un diseño documentado debe explicar también cómo restaurar una copia de seguridad y cómo incorporar una nueva integración sin romper las existentes.
Para concretar estas decisiones, resulta útil describir primero dos o tres recorridos completos —desde la entrada de un contacto hasta el seguimiento de una oportunidad, por ejemplo— y anotar datos, permisos, reglas e intercambios implicados. Esa descripción permite comparar requisitos con las capacidades de un CRM a medida y distinguir lo imprescindible para la primera versión de las funciones que pueden añadirse cuando exista una necesidad demostrable.
