En la mayoría de las empresas con las que trabajamos, el mismo cliente existe cinco veces.
Está como correo en la plataforma de email. Como teléfono en WhatsApp. Como número de documento en la caja del local. Como identificador anónimo en el ecommerce hasta que se registra. Y como fila en una planilla que alguien exportó en marzo y sigue usando.
Ninguno de los cinco sabe de los otros cuatro. Eso es un silo de datos, y su costo no figura en ninguna factura.
El costo no es técnico, es de criterio
Cada sistema toma decisiones con el pedazo de historia que le tocó. El de email no sabe que compró en el local ayer, así que le manda la promo de reactivación. El de anuncios no sabe que ya es cliente, así que sigue pagando por traerlo. El vendedor no sabe que abrió el mismo presupuesto cuatro veces esta semana, así que no lo llama justo cuando la señal era más fuerte.
El cliente sí sabe todo eso. Y lo que ve es una empresa que no lo reconoce.
La contradicción que el cliente nota
El síntoma más visible es el mensaje de bienvenida a alguien que te compra desde hace dos años, o el descuento de primera compra a quien pagó precio completo la semana pasada. No es un error de redacción ni un descuido del equipo de contenidos. Es el resultado inevitable de tener la identidad partida: cada sistema hace bien su trabajo con la información que tiene, y la información que tiene es un tercio de la verdad.
La plata que se va sin que nadie la registre
Hay un costo más silencioso que la contradicción: presupuesto de adquisición gastado en gente que ya es cliente, promociones enviadas a quien iba a comprar igual, y leads calientes que se enfrían porque la señal quedó en un sistema que el vendedor no mira. Nada de eso aparece como línea de gasto. Aparece como un costo de adquisición que subió y una conversión que bajó, y se discute como si fuera un problema de campañas cuando es un problema de identidad.
Unificar empieza por la llave, no por la herramienta
El error habitual es arrancar comprando una plataforma y conectarle todo. Sin definir antes cómo se reconoce a una persona, lo que se logra es replicar el desorden más rápido y con perfiles duplicados.
El orden que funciona:
- Elegir la llave. Un identificador que exista o pueda existir en todos los sistemas. En LATAM el teléfono suele ganar, porque el correo falta en el punto de venta y el documento falta en el ecommerce, pero el teléfono aparece en casi todos lados.
- Normalizar antes de cruzar. Los formatos de teléfono varían tanto entre sistemas (con código de país, sin él, con cero adelante, con guiones) que la comparación literal falla. Comparar por los últimos dígitos resuelve la mayoría de los cruces.
- Definir los eventos que importan. No todos: los diez o quince que efectivamente cambian lo que le vas a decir a alguien. Compró, abandonó un carrito, visitó el local, pidió presupuesto, dejó de abrir mensajes.
- Conectar de a un sistema. Empezando por el que tiene la data más limpia, para tener una base contra la que comparar. Cada sistema nuevo se valida contra esa base antes de sumar el siguiente.
En Grupo Garden, por ejemplo, la llave es el teléfono: la venta es conversacional por WhatsApp, y sobre esa identidad unificada el 94% de los leads se clasifica de forma automática antes de que un vendedor los toque. Sin la llave definida, esa clasificación sería imposible, porque el mismo interesado entraría tres veces como tres personas distintas.
Reportar y reaccionar no son lo mismo
Una advertencia sobre la frecuencia, porque acá se define buena parte del presupuesto del proyecto.
Un export nocturno sirve para reportar: al día siguiente sabes qué pasó, puedes armar cohortes, alimentar un tablero, auditar una campaña. Para eso la data de ayer alcanza y sobra.
Un evento en el momento sirve para reaccionar: el carrito abandonado que se atiende doce horas después ya no es un carrito abandonado, es una oportunidad vencida. El lead que pidió presupuesto y espera dos días una respuesta ya está hablando con otro. Si el objetivo es que el sistema haga algo mientras la señal está caliente, el evento tiene que llegar mientras la señal está caliente.
La trampa es pagar arquitectura de tiempo real para necesidades de reporte, o al revés, esperar reacciones inmediatas de un stack que sincroniza una vez por día. Definir qué eventos necesitan cada velocidad, antes de cotizar herramientas, evita las dos.
Qué cambia cuando el perfil es uno solo
Con la identidad unificada, las decisiones que antes eran imposibles se vuelven triviales. El sistema de email deja de saludar a clientes de dos años. Las audiencias de anuncios excluyen a quienes ya compraron. El vendedor ve el historial completo antes de responder. Y los números del negocio (cuántos clientes hay, cuántos vuelven, cuánto vale cada uno) dejan de tener cinco respuestas según a qué sistema le preguntes.
La buena noticia es que el plazo no es el que la mayoría imagina. En Bigbox la unificación sobre Customer.io estuvo en producción en 15 días y después se replicó en cinco países con la misma arquitectura. La parte lenta nunca es la técnica: es decidir la llave, los eventos y quién es el dueño de cada dato. Ese diseño es el corazón de nuestros proyectos de transformación digital.
Una pregunta para medir cuán partida está tu identidad hoy: si un cliente compra en el local esta tarde, ¿cuánto tarda tu plataforma de comunicación en enterarse?