Customer 360.
Una sola vista de tu cliente, donde sea que viva el dato.
Reconciliá la identidad de un mismo cliente entre CRM, ERP, e-commerce, programa de loyalty, contact center y data warehouse. Con MuleSoft armás un servicio de golden record que recupera la verdad de cada sistema, aplica reglas de supervivencia y entrega una respuesta consolidada a cada canal en menos de un segundo.
¿Qué resuelve Customer 360 con MuleSoft?
El cliente vive duplicado e inconsistente entre el CRM, el ERP, el e-commerce, el loyalty, el contact center y el data warehouse. Cada equipo ve un pedazo: ventas no sabe que el cliente acaba de comprar online, marketing manda promos de productos ya comprados, finanzas no reconoce el documento porque viene escrito distinto. Customer 360 con MuleSoft entrega una vista federada en tiempo real y un golden record con reglas de supervivencia, sin obligarte a un MDM tradicional.
- Resolución de identidad por documento, email y teléfono normalizados.
- Golden record con reglas de supervivencia configurables por campo.
- Respuesta consolidada en tiempo real para contact center, app móvil y portales.
- Activación opcional de Data Cloud cuando hace falta persistencia y analytics.
Sistemas típicos involucrados
Las familias de sistemas que conviven en un proyecto Customer 360 enterprise.
CRM
Salesforce Sales Cloud y Service Cloud como sistema de relación con el cliente.
ERP
SAP S/4HANA, SAP ECC, Oracle EBS, NetSuite, Microsoft Dynamics 365 como autoridad de datos fiscales y financieros.
E-commerce
Vtex, Magento, Salesforce Commerce, Shopify Plus, Tienda Nube como fuente de comportamiento y preferencias.
Datos y loyalty
Snowflake, BigQuery, Redshift, Comarch, Annex Cloud para persistencia analítica y programa de puntos.
Arquitectura objetivo
API-Led Connectivity en tres capas, con un golden record service como pieza central.
+----------------+ +----------------+ +----------------+
| Salesforce | | SAP / ERP | | E-commerce |
+--------+-------+ +--------+-------+ +--------+-------+
| | |
| System API | System API | System API
v v v
+---------------------------------------------------------------+
| Capa System APIs (sf-customer, sap-customer, ...) |
+----------------------------+----------------------------------+
|
| Process API
v
+---------------------------------------------------------------+
| Customer Golden Record Service |
| - Match & merge (deterministic + fuzzy) |
| - Survivorship rules |
| - Identity graph (DNI / RUC / CUIT / CPF + email + phone) |
+----------------------------+----------------------------------+
|
+--------------------+---------------------+
| | |
v v v
+---------------+ +------------------+ +-----------------+
| customer-360 | | Data Cloud / | | Event Stream |
| Experience | | Snowflake (sink)| | (customer. |
| API | | | | updated) |
+---------------+ +------------------+ +-----------------+
|
Consumers: app móvil, contact center, marketing, portalesSystem APIs
Una API por sistema fuente (sf-customer-sapi, sap-customer-sapi, magento-customer-sapi). Abstraen las particularidades de cada sistema y devuelven contratos estables alineados al lenguaje de negocio.
Process APIs
customer-golden-pa hace scatter-gather sobre las System APIs, aplica reglas de matching (exacto y fuzzy) y reglas de supervivencia por campo. Devuelve el golden record con la trazabilidad de cada atributo.
Experience APIs
customer-360-eapi sirve a cada canal con el shape que necesita: el contact center recibe enriquecimiento con interacciones recientes; la app móvil, una versión más liviana; marketing, las preferencias y consentimientos.
Flujo paso a paso
Cómo se resuelve una consulta de cliente desde el contact center, end-to-end.
- 1 El agente del contact center recibe la llamada entrante. El IVR identifica al cliente por número de teléfono o documento.
- 2 La aplicación del agente llama a la Experience API customer-360-eapi. El gateway autentica el llamado con OAuth client credentials.
- 3 La Experience API normaliza los identificadores (limpia separadores del documento, agrega prefijo país al teléfono, hashea el email).
- 4 La Experience API invoca a la Process API customer-golden-pa con los identificadores normalizados.
- 5 La Process API ejecuta un scatter-gather sobre todas las System APIs configuradas (CRM, ERP, e-commerce, loyalty) en paralelo, con timeout corto por fuente.
- 6 Cada System API responde con la versión del cliente que conoce. Las identidades se vinculan por documento, email y teléfono.
- 7 La Process API aplica reglas de matching (exacto y fuzzy sobre nombres, normalización documental por país) y produce un set de identidades consolidadas.
- 8 Se aplican reglas de supervivencia por campo: el nombre fiscal viene del ERP, el email más reciente prevalece, las preferencias de marketing las gana el CRM.
- 9 La Process API devuelve el golden record con un atributo _sources que indica de dónde vino cada campo y un flag partial cuando alguna fuente no respondió.
- 10 La Experience API enriquece con datos contextuales (últimas interacciones, tickets abiertos, oportunidades activas) y cachea en Object Store con TTL corto.
- 11 La respuesta consolidada llega al agente en menos de un segundo. La conversación arranca con contexto completo del cliente, no con preguntas redundantes.
Patterns aplicados
Los patrones de integración que sostienen el caso en producción.
Scatter-Gather
Consulta en paralelo a cada System API para minimizar la latencia de la respuesta consolidada.
Cache aside
Object Store con TTL corto para callers repetidos (mismo agente reabriendo la misma ficha).
Fallback chain
Si una fuente no responde, se devuelve el golden parcial con flag partial: true en lugar de fallar completo.
Anti-Corruption Layer
Cada System API abstrae las particularidades del sistema fuente y devuelve un contrato canónico estable.
Bulk identity resolution
Process API dedicada a procesos batch que resuelven miles de identidades por minuto sobre el mismo algoritmo.
Idempotent reads
Las consultas repetidas con la misma clave devuelven la misma respuesta dentro del TTL configurado.
Cómo lo implementamos
Cinco fases del assessment al Center of Excellence operando con autonomía.
Inventario de fuentes y reglas
Mapeo de sistemas que tienen al cliente, identificadores disponibles por país, definición de reglas de match y supervivencia con los data owners. Entregables: assessment, matriz de fuentes, mock del golden record.
Contratos API y modelo canónico
Diseño API-Led: System APIs por fuente, Process API customer-golden-pa, Experience API por canal. Modelo de datos canónico, plan de gobernanza, política de seguridad y consentimiento.
Construcción de las APIs
Implementación de las System APIs sobre cada fuente, lógica de matching y supervivencia en la Process API, primer Experience API para el canal piloto. Tests MUnit, CI/CD a sandbox.
Hardening y go-live controlado
Hardening, security review, load testing, observabilidad. Go-live por canal: primero contact center, luego app, luego portales. Hypercare con el equipo del cliente.
Expansión y CoE
Activación opcional de Data Cloud para persistencia analítica, integración con Marketing Cloud, expansión a nuevos canales, capacitación del equipo del cliente para gobernar el golden record con autonomía.
Requisitos del proyecto
Lo que tiene que estar disponible del lado del cliente para arrancar.
Datos mínimos
Identificadores razonablemente limpios en cada sistema fuente: documento fiscal del país, email y teléfono. Reglas de supervivencia acordadas con los data owners.
Licencias y capacidades
Anypoint Platform, conectores Salesforce, SAP, Oracle, NetSuite, Dynamics o el e-commerce que aplique. Data Cloud opcional cuando se busca persistencia analítica.
Integraciones típicas
CRM, ERP, e-commerce, loyalty y data warehouse como mínimo. Marketing Cloud y contact center suelen sumarse en la fase de expansión.
Pre-requisitos organizacionales
Sponsor del programa de cliente único, IT lead disponible, data owners comprometidos, política de privacidad y consentimiento alineada con LGPD, Habeas Data y normativas locales.
KPIs operativos
Las métricas que típicamente mejoran tras la implementación. Sin números de mercado: cada cliente fija su baseline.
| KPI | Qué mide | Por qué importa |
|---|---|---|
| Golden record resolution time | Latencia P95 de la consulta consolidada. | Define la experiencia del agente en contact center y de cada canal en vivo. |
| Partial response rate | Porcentaje de respuestas que vienen incompletas porque alguna fuente falló. | Indica disponibilidad real del servicio de golden record. |
| Match accuracy | Calidad del matching entre sistemas, exacto y fuzzy. | Evita falsos positivos (clientes distintos colapsados en uno) y falsos negativos. |
| Cache hit rate | Eficiencia del cache de la Experience API. | Reduce la carga sobre los sistemas fuente y mejora la latencia percibida. |
| Asset reuse rate | Porcentaje de proyectos nuevos que reusan las System APIs ya construidas. | Es el indicador más honesto de la madurez del programa MuleSoft. |
| Data quality complaint rate | Reclamos del negocio sobre inconsistencias de datos del cliente. | Cierra el loop con la experiencia real, no solo con la métrica técnica. |
Time-to-value: primeras métricas observables tras 4 a 8 semanas en producción del canal piloto.
Cómo se mide: dashboard entregado por Solu sobre Anypoint Monitoring, complementado con Splunk, Datadog o Tableau cuando el cliente ya los usa.
Preguntas frecuentes
No siempre. Customer 360 con MuleSoft puede entregar una vista federada en tiempo real sin persistir un master único, manteniendo a cada sistema como autoridad sobre su porción de la verdad. Cuando el caso justifica persistencia y analytics dedicados (volumen alto, modelos de IA, segmentación masiva), conviene activar Data Cloud o un store dedicado por encima del golden record.
El documento fiscal por país (CUIT en Argentina, CPF en Brasil, RUC en Perú, RUT en Chile, RFC en México), el email y el teléfono móvil. La normalización es clave porque el mismo documento aparece con distintos formatos en cada sistema. Una Process API o System API debe normalizar a un formato canónico antes de comparar.
Un primer canal en producción suele tomar entre 12 y 16 semanas desde el kickoff. El factor que más mueve la aguja no es MuleSoft, es la calidad del dato heredado y la disponibilidad de los data owners de cada sistema fuente. La fase de Discover suele revelar deuda histórica que conviene resolver antes de cablear todo.
El proyecto no se detiene a esperar datos perfectos. Las reglas de matching se diseñan tolerantes (matching exacto primero, fuzzy con umbral conservador después) y la respuesta del golden record incluye un score de confianza. Los casos ambiguos se canalizan a un flujo de revisión humana o se exponen al canal con flag de incerteza para que el agente confirme.
Data Cloud es un consumer natural del golden record. MuleSoft alimenta a Data Cloud en streaming con los eventos customer.updated.v1 y los datos consolidados. Data Cloud se vuelve la persistencia analítica, mientras la Experience API sigue sirviendo consultas en vivo. Las dos cosas conviven, no compiten.
Una sola vista de tu cliente, donde sea que viva el dato.
Hablemos del estado de tus sistemas y diseñamos juntos el roadmap de Customer 360.