Una bandeja unificada suena a problema de fontanería. Conectas los canales, normalizas los formatos, ordenas por fecha, listo.
Esa parte es trabajo de verdad, pero no es la que decide si la bandeja es buena. La que lo decide es si el software sabe que el número de WhatsApp que escribió el lunes y la dirección de correo que escribió el jueves son la misma persona.
Cada canal te da un nombre distinto para el mismo humano
Aquí está la raíz. Los canales no se ponen de acuerdo en qué es un cliente:
| Canal | Qué te da | Qué no te da |
|---|---|---|
| Un número de teléfono | Un nombre elegido, un correo | |
| Un identificador de cuenta acotado | Teléfono, correo, muchas veces el nombre real | |
| Chat web | Un identificador de navegador | Nada, hasta que te lo digan |
| Correo | Una dirección | Teléfono, cualquier canal anterior |
Ninguno es la persona. Son cuatro asas que resulta que apuntan a una, y ninguna plataforma te va a decir que están relacionadas, porque ninguna lo sabe.
Así que la bandeja tiene que decidir. Y decidir mal en cualquiera de los dos sentidos tiene un coste.
Fusionar mal es peor que no fusionar
La tentación es ser listo: cotejar nombres por parecido, deducir de un nombre de pila compartido y una ciudad, unir todo lo que se parezca.
No lo hagas. Si se fusionan dos fichas que eran personas distintas, un cliente está leyendo ahora el historial de otro dentro de tu respuesta. Eso no es un informe de error, es un incidente de protección de datos, y es de los pocos fallos de software capaces de terminar una relación comercial en un solo mensaje.
La regla que aguanta es fusionar solo con identificadores que la persona dio a propósito, y tratar todo lo demás como una sugerencia para que la confirme un humano:
- Un correo o teléfono verificado que coincide con una ficha existente es una señal fuerte. Lo escribió el cliente.
- Un nombre parecido no es una señal. Es una casualidad con buenos modales.
- El mismo dispositivo o navegador es una pista, y las pistas van a una cola de revisión, no a una fusión automática.
La asimetría importa. No fusionar te deja con dos fichas y algo menos de contexto, que es molesto. Fusionar mal le enseña a un desconocido la conversación de otro, y eso no se recupera.
El contexto solo sirve donde se escribe la respuesta
La segunda mitad del problema es la entrega. Muchas herramientas pueden técnicamente sacar el historial de un cliente; muy pocas lo ponen donde está escribiendo la persona.
Si responder a "¿este cliente ya había comprado?" cuesta dos clics y una pestaña nueva, en la práctica la respuesta no está disponible, porque a las once de la mañana con catorce conversaciones abiertas nadie da esos dos clics. El contexto tiene que llegar pegado a la conversación: qué compró, qué preguntó la última vez, en qué fase del pipeline está, qué se le prometió.
Ese es el objetivo de diseño entero. No "todos tus canales en un sitio", que es una captura de pantalla. "La respuesta que vas a escribir sabe qué pasó la última vez", que es otro producto.
Qué comprobar de verdad al evaluar una
Cuatro preguntas, todas contestables en una prueba:
- Escribe desde dos canales como la misma persona. ¿Se da cuenta la herramienta? ¿Qué hace cuando no está segura?
- ¿Se puede deshacer una fusión? Si dos fichas se unieron mal, separarlas debería poder hacerse y no debería perder mensajes.
- ¿Qué se ve al lado del cuadro de escribir? No qué está disponible en algún sitio. Qué hay en pantalla mientras escribes.
- ¿Qué pasa cuando un canal se cae? Un mensaje en cola que desaparece en silencio es peor que un error, porque nadie va a buscarlo.
Resumen
- Los canales son la parte fácil. La identidad es el producto.
- Cada canal da un identificador distinto y ninguno es la persona.
- Fusiona con lo que el cliente dio a propósito. Manda las señales débiles a un humano.
- Una fusión errónea es un incidente, no una molestia. La asimetría debería marcar el comportamiento por defecto.
- El contexto que no está junto al cuadro de escribir es contexto que nadie usa.
