Tu cliente tiene cinco identidades distintas y tu empresa no lo sabe
- Equipo Digital eXp

- hace 7 días
- 5 min de lectura
Por qué la fragmentación de IDs entre sistemas no es un problema de datos, sino de arquitectura de negocio, y qué hacer al respecto sin comprar una herramienta más.
Un mismo cliente entra al SAP con un número, al CRM con otro, a la tienda online con un tercero y a la mesa de ayuda con un cuarto. Ninguno de esos sistemas sabe que los otros existen. Cada uno cree tener "el" registro correcto, y en rigor todos tienen razón. El problema no es que los datos estén mal. Es que nadie los está leyendo juntos.
En nuestros proyectos hemos visto lo que esto le cuesta a la operación, y no es un costo abstracto.
Un cliente que llama a soporte y tiene que repetir todo lo que ya le contó a ventas se traduce en más minutos de llamada facturados y en una venta cruzada que nunca se ofrece.
Un equipo de datos que arranca cada proyecto emparejando a mano, en una planilla, las distintas versiones de un mismo cliente está gastando horas de gente calificada en ordenar información en vez de analizarla.
Un presupuesto de integración que se duplica porque conectar dos sistemas obliga a mapear los registros de cada uno desde cero es plata que se paga de nuevo cada vez que se conecta una plataforma más.
El cliente no vale menos por estar fragmentado. Vale lo mismo, pero cuesta más atenderlo, más integrarlo y más reportarlo.
Este artículo explica por qué pasa esto, cómo lo está resolviendo la industria (con el enfoque de Salesforce como referencia concreta), y qué pasos concretos puedes tomar para ordenar la identidad de tu cliente sin embarcarte en un proyecto de dos años.
¿Por qué esto importa justo ahora?
Las empresas medianas y grandes en Latam llevan años acumulando sistemas. El ERP llegó con una fusión hace varios años. El CRM se implementó para ventas y nunca conversó con el de soporte. La plataforma de e-commerce se integró rápido para no perder un trimestre. Cada sistema resolvió un problema puntual en su momento. Nadie se sentó a diseñar cómo iban a reconocerse entre sí.
El resultado es una empresa que factura, vende y atiende a la misma persona como si fueran personas distintas. Y esto ya no es un tema cosmético. Con la Ley 21.719 de Protección de Datos avanzando en su implementación, saber exactamente qué información tiene tu empresa sobre ti, en qué sistemas vive y bajo qué identificador, dejó de ser una buena práctica y pasó a ser un requisito. No se puede responder a una solicitud ARCOP (acceso, rectificación, cancelación, oposición, portabilidad) si tu empresa ni siquiera sabe cuántas versiones del mismo cliente tiene guardadas.
A esto se suma la presión de negocio: cada vez más compañías quieren usar IA y automatización sobre sus datos de cliente, y ningún modelo, por bueno que sea, puede compensar una base fragmentada. Se puede automatizar sobre datos ordenados. Sobre datos fragmentados, solo se automatiza el error, más rápido.
¿Reconoces alguno de estos síntomas?
El síntoma más común es la campaña de marketing que le llega tres veces a la misma persona, con mensajes distintos, porque el sistema la contó como tres contactos diferentes. Es molesto para el cliente y, peor, hace que las métricas de la campaña mientan: se reporta un alcance que no es real.
Otro síntoma clásico aparece en atención al cliente: alguien llama, el agente busca por RUT o por teléfono y encuentra un historial incompleto, porque parte de la interacción quedó registrada bajo otro identificador en otro sistema. El agente termina pidiéndole al cliente que repita información que tu empresa ya tiene, solo que en otro lugar.
También está el caso, más silencioso pero más caro, de las áreas comerciales y financieras que no logran calcular el valor real de un cliente porque su facturación en SAP y su actividad en el CRM nunca se cruzan del todo. Se toman decisiones de pricing, de retención o de upsell con una fotografía parcial, y nadie se da cuenta hasta que un cliente grande se va y, al revisar el historial completo, se descubre que las señales de alerta estaban ahí, solo que repartidas en tres sistemas distintos.
El punto en común de todos estos síntomas es que ninguno aparece como línea en el presupuesto. Nadie tiene una partida llamada "sobrecosto por identidad fragmentada". Está repartido en horas hombre que se van en cuadrar planillas, en proyectos de integración que se cotizan más caros de lo que deberían, en campañas que pagan tres impactos donde se necesitaba uno, y en oportunidades de venta que no se detectan porque nadie ve al cliente completo. Es dinero real, solo que contabilizado en otra parte.
Si alguno de estos escenarios suena familiar, no es un problema de que "los datos estén sucios". Es un problema de que no existe una capa que conecte los sistemas entre sí.
¿Por dónde empiezas a ordenar esto?
Lo primero que hay que descartar es la solución obvia: comprar una herramienta más no arregla esto, y fusionar todo en un solo registro tampoco. Cada sistema guarda contexto que se pierde si se aplasta todo en una única versión del cliente.
Acá conviene entender cómo aborda el problema una plataforma como Salesforce, porque el enfoque cambia el paradigma habitual. La tentación natural es pensar en un "golden record": un registro maestro que reemplace a todos los demás. Salesforce, a través de su capacidad de Identity Resolution en Data Cloud, propone algo distinto y, en la práctica, más realista: en vez de reemplazar los identificadores existentes, construye un Unified Profile que los referencia a todos. Lo describen como un llavero, donde cada sistema conserva su propio identificador, y el perfil unificado es la referencia que los conecta (Salesforce, About Identity Resolution, help.salesforce.com).
La resolución se hace combinando reglas determinísticas (mismo email, mismo RUT, mismo teléfono) con reglas difusas, para casos donde el nombre está mal escrito o la dirección varía levemente entre sistemas (Salesforce, Identity Resolution Rulesets, help.salesforce.com). Tu empresa define el nivel de precisión según el riesgo del caso de uso: no es lo mismo unificar identidades para una campaña de marketing que para un proceso donde hay implicancias regulatorias.
Antes de llegar a una herramienta, sin embargo, hay un ejercicio previo que es puramente de negocio: mapear qué sistemas existen, qué identificador usa cada uno, y quién dentro de la organización es dueño de decidir qué reglas determinan que dos registros son la misma persona. Esa conversación no la resuelve ningún software; la resuelve un diagnóstico de arquitectura. En Digital eXp partimos por ahí con auditoría inicial, que deja claro dónde están las fuentes de fragmentación antes de proponer cualquier solución técnica. Cuando tienes Salesforce pero la adopción quedó a medio camino y los datos siguen sin conversar entre sistemas, el trabajo se hace desde la limpieza de datos, ajustado a la arquitectura real de tu empresa y no a una plantilla genérica.
¿Necesitas un diagnóstico? Revisa esto
Antes de pensar en una herramienta nueva, vale la pena hacerte algunas preguntas simples. ¿Sabe tu empresa, con certeza, cuántos sistemas distintos almacenan información de un mismo cliente? ¿Existe una regla de negocio explícita, no solo técnica, que determine cuándo dos registros corresponden a la misma persona? ¿Podrías hoy responder a una solicitud ARCOP con una vista completa de un cliente, o tomaría días de búsqueda manual entre sistemas?
Si alguna de estas preguntas no tiene una respuesta clara e inmediata, probablemente el problema de fragmentación ya existe en tu organización. Solo que todavía nadie lo ha medido.
Lo que viene
La fragmentación de identidad de cliente no se resuelve comprando una plataforma más. Se resuelve entendiendo primero cómo están conectados (o desconectados) los sistemas que ya existen, y definiendo con claridad quién es dueño de esa decisión dentro de tu empresa. Ese es un ejercicio de arquitectura de negocio antes que de tecnología, y es el terreno en el que trabajamos.
Si quieres entender dónde está fragmentada la identidad de tus clientes dentro de tu propia arquitectura, conversemos:




