Arquitectura CRM

La consultoría de arquitectura CRM empieza por el trabajo que ocurre entre el primer contacto y el cierre de la relación. Analizamos cómo entra una consulta, cuándo se considera cualificada, quién responde por la siguiente acción, qué evidencia permite avanzar, cómo se entrega la cuenta al equipo de servicio y cómo se registran renovación, ampliación, soporte o cierre. El modelo también contempla excepciones reales: varios compradores, distribuidores, compras largas, oportunidades reabiertas y cuentas atendidas por más de un equipo.

El alcance escrito enumera unidades, etapas, tipos de registro, usuarios, funciones, fuentes, canales, informes, automatizaciones, histórico que se migrará, entornos, formación, aceptación y responsabilidad posterior. Un CRM nuevo para un equipo comercial no equivale a un sistema multinacional que conecta marketing, finanzas, atención y entrega. Limpiar una cuenta existente no implica rehacerla por completo; un prototipo tampoco es operación en producción.

Revisamos la capacidad nativa antes de recomendar personalización. Salesforce, HubSpot, Microsoft Dynamics 365, Pipedrive, Zoho o una interfaz propia pueden ser adecuados, pero no prometemos plataforma hasta comprobar requisitos, plan contratado, disponibilidad regional, API, seguridad y coste total. La arquitectura distingue configuración, extensión, integración y software a medida. Implantar un CRM no garantiza ventas, ciclos más cortos ni adopción; sí podemos verificar procesos, permisos, datos, automatizaciones, informes y escenarios acordados.

El modelo de datos representa el negocio, no la primera hoja de cálculo encontrada. Contactos, empresas, leads, oportunidades, productos, suscripciones, casos, sedes, socios y actividades solo se separan cuando describen entidades distintas con reglas distintas. Cada campo tiene definición empresarial, tipo, valores válidos, sensibilidad, fuente, responsable y conservación. Un objeto personalizado se crea porque la relación lo exige, no porque añadir otra tabla resulte fácil.

Las reglas de identidad impiden que una persona, cuenta u oportunidad se multiplique sin control. Establecemos claves, umbrales, prevalencia, autoridad para fusionar y excepciones para direcciones compartidas, filiales, franquicias y personas vinculadas a varias organizaciones. El correo no siempre es un identificador único fiable. La fusión automática se limita, registra y, cuando sea posible, permite volver atrás; los casos dudosos pasan a una cola humana con responsable.

La propiedad del registro no es lo mismo que su visibilidad. Una persona puede responder por la acción, un equipo regional tener acceso, marketing gobernar el consentimiento y finanzas controlar un campo de facturación. Los campos obligatorios aparecen cuando la etapa los necesita, sin empujar a inventar datos. Los cambios relevantes del esquema se versionan y prueban contra informes, automatizaciones e integraciones; los campos antiguos se retiran con intención y no quedan como verdades rivales.

El diseño del pipeline comercial funciona cuando cada etapa corresponde a un hecho reconocible. Cualificado puede requerir encaje confirmado y un problema identificado; propuesta enviada, una versión registrada; compromiso, una vía de decisión concreta en vez de una probabilidad esperanzada. Se documentan entrada, salida, retroceso, motivos de pérdida, inactividad y reapertura. La categoría de previsión se separa de la etapa si responde a otra pregunta.

Las colas y reglas de propiedad hacen visible la próxima acción. La asignación puede considerar región, idioma, producto, capacidad, relación previa o especialidad regulada, pero necesita una alternativa cuando faltan datos o nadie está disponible. La automatización se limita a pasos estables y autorizados: crear tareas, sincronizar estados, preparar mensajes para revisión o encaminar excepciones. No deduce consentimiento, inventa datos ni cierra asuntos importantes mediante un juicio opaco del modelo.

Los informes siguen el contrato del ciclo de vida. Conversión, velocidad, antigüedad, fuente, cobertura y previsión nombran población, momento y exclusiones. Mover una etapa por comodidad administrativa no puede convertirse en una señal falsa de compra. La actividad no demuestra por sí sola calidad de relación, intención ni ingresos futuros. La dirección debe poder revisar los registros que forman un agregado y su estado de calidad.

La migración comienza con inventario y selección. Evaluamos fuente, responsable, volumen, calidad, sensibilidad, histórico, adjuntos, duplicados y obligaciones de borrado. Los datos de configuración y los registros de clientes requieren tratamientos distintos. Mapeamos campos y valores, transformamos muestras, ensayamos, conciliamos cantidades y totales clave, registramos rechazos y acordamos el cambio. Antes de modificar la fuente anterior se conserva una copia conforme al plan de recuperación escrito.

Las integraciones declaran dirección, autoridad y comportamiento ante fallos. Para cada conexión se define sistema maestro, actualizaciones permitidas, conflicto, frecuencia, identificador, registro y responsable de reintentos. Webhooks, API, archivos y middleware ofrecen garantías distintas. Una flecha en dos sentidos dentro de un diagrama no constituye un contrato de integración.

El acceso aplica el privilegio mínimo. Ver, editar, exportar, borrar, configurar y administrar son facultades distintas. Los datos sensibles de clientes, salud, finanzas o personal pueden exigir controles de campo y fila, límites regionales, conservación y auditoría. Las cuentas técnicas tienen propietario, permisos acotados, secretos gestionados y revocación. Comprobamos qué puede registrar y conservar el plan contratado; instalar un CRM no crea por sí solo privacidad ni cumplimiento legal.

La aceptación recorre escenarios completos: captar una consulta, cualificar, crear relaciones, asignar, avanzar con evidencia, producir una salida, entregar al servicio, resolver duplicados, retirar consentimiento, informar una excepción y recuperar una integración fallida. Los permisos se prueban con cada función y no solo con el administrador. Se concilian muestras y totales, se observan automatizaciones y se abren vistas móviles y exportaciones críticas.

La formación se organiza por tareas y decisiones, no como visita de botones. Las personas aprenden el significado de cada etapa, qué registrar, dónde está la acción, cómo tratar una excepción y cómo comunicar un defecto. Administración recibe diccionario de datos, modelo de funciones, inventario de automatizaciones, mapa de integraciones, registro de versión y manual operativo. Adopción no equivale a inicios de sesión: también revisamos registros sin dueño, tareas vencidas, duplicados, atajos manuales, soporte y calidad de las reuniones de pipeline.

La operación asigna responsabilidad por versiones del proveedor, credenciales caducadas, sincronización fallida, colas, almacenamiento, límites API, permisos y deriva de informes. Horarios, respuesta, capacidad de cambio y escalado quedan escritos; no se presupone soporte permanente ni administración ilimitada. La IA puede resumir registros aprobados, sugerir una acción o redactar para revisión, pero no inventa hechos, deduce consentimiento ni recibe autoridad comercial autónoma sin una evaluación y aprobación separadas.