Un cliente escribe por Instagram el lunes y contacta con la empresa por WhatsApp el miércoles. La regla segura es sencilla: trate ambas conversaciones como la misma persona solo cuando un identificador estable o una verificación explícita las conecte. Un nombre parecido, la misma forma de escribir o la cercanía temporal no bastan.
Esa prudencia importa. Un perfil duplicado es incómodo, pero una unión incorrecta puede mostrar el historial, las preferencias de consentimiento, los pedidos o las notas de soporte de otra persona. La resolución de identidad debe ser un proceso basado en pruebas, no una función que adivina.
Empiece con una clave de cliente estable
Cada canal aporta su propio identificador. WhatsApp puede presentar una identidad vinculada al teléfono. Instagram y Messenger usan identidades de sus plataformas. Un sitio web puede conocer el ID de una cuenta autenticada. El CRM puede guardar un número interno de cliente y una o varias direcciones de correo.
Ninguno de esos valores representa automáticamente a la persona.
El diseño más sólido empieza con una clave estable controlada por la empresa, normalmente la clave principal del sistema de clientes, cuentas o pedidos. Los identificadores de canal solo se añaden cuando la relación está respaldada. Así, el registro sigue siendo estable si cambia un teléfono, un empleado deja una empresa o el cliente usa una segunda cuenta social.
La documentación actual de Twilio sobre resolución de identidad separa rasgos, identificadores, reglas de identidad y perfil unificado. También da más prioridad a un ID estable de usuario que al correo, WhatsApp, teléfono o chat. El orden exacto cambiará según el sistema, pero el principio es útil: empiece por el identificador que su empresa controla y comprende mejor.
Trate los identificadores de canal como pruebas
Un teléfono, una dirección de correo o un nombre social pueden ser pruebas fuertes. Aun así, no son una confirmación absoluta en todos los casos.
Los números se reasignan. Una familia puede compartir correo. Un buzón empresarial puede pertenecer a varias personas. Los nombres se repiten, cambian o se transliteran de distintas formas. Incluso un número de pedido puede copiarlo alguien que ayuda al comprador.
Por eso, una coincidencia exacta y una probabilística no deben producir el mismo efecto. La exacta usa un valor ya verificado, como un ID de cliente autenticado o una confirmación puntual enviada a un contacto existente. La probabilística usa pistas como nombre, ubicación, momento o patrón de compra.
Las pistas probabilísticas pueden sugerir una posible coincidencia a un empleado. No deberían abrir en silencio el historial ni crear una unión permanente.
Use una escala de confianza antes de vincular perfiles
Un proceso práctico puede trabajar con cuatro estados.
- Separado significa que la conversación conserva la identidad del canal y no muestra contexto de otros canales.
- Sugerido significa que el sistema encontró un registro posible, pero una persona debe revisar las pruebas.
- Verificado significa que el cliente o un sistema fiable confirmó la relación mediante un identificador estable.
- Vinculado significa que la identidad del canal se añadió a la clave de cliente y que el contexto aprobado puede utilizarse después.
El paso de sugerido a verificado es el control más importante. Puede ocurrir cuando el cliente inicia sesión, confirma un código enviado a un contacto conocido, aporta datos que se comprueban contra un pedido o sigue un enlace seguro desde una cuenta autenticada. El método adecuado depende del riesgo de la conversación.
La guía actual de NIST sobre prueba de identidad describe cómo una persona aporta pruebas para que su identidad pueda afirmarse con un nivel útil de confianza. Un flujo de mensajería no es un servicio gubernamental de autenticación, pero la lección basada en riesgo sí encaja: cuanto más sensible sea la acción o el historial, más sólidas deben ser las pruebas.
Una pregunta de producto puede requerir una comprobación ligera antes de mostrar intereses anteriores. Una disputa de facturación, una consulta de salud o un cambio de cuenta merece una comprobación más fuerte antes de enseñar historial privado.
Haga que el error lleve a la opción más segura
Los errores de identidad no cuestan lo mismo. Si dos registros siguen separados, el agente quizá pida repetir información. Si dos personas distintas quedan unidas, el agente o la automatización pueden revelar datos al destinatario equivocado.
La guía de Intercom sobre ID de usuario explica cómo los valores no únicos o provisionales pueden fusionar clientes diferentes. También advierte de la suplantación y del acceso no autorizado al historial cuando la identificación es débil. La lección va más allá de una plataforma: la clave debe ser única en todo el espacio de trabajo, no solo en un equipo o integración.
Use el criterio conservador cuando las pruebas entren en conflicto. Mantenga los registros separados, pause la automatización que dependa del historial personal y envíe el caso a alguien con el permiso adecuado. Es más fácil explicar una comprobación adicional que la aparición de datos de otro cliente.
Mantenga reversible cada cambio de identidad
Un botón para fusionar no es suficiente. El sistema debe conservar qué cambió y por qué.
En cada vínculo, promoción, fusión o desvinculación, guarde:
- la clave anterior y la nueva
- los identificadores que respaldaron la decisión
- el sistema de origen de cada identificador
- la persona o automatización que hizo el cambio
- la hora del cambio
- el método y el resultado de verificación
- una forma de revertir la relación sin borrar la conversación original
Los permisos también importan. Genesys documenta permisos separados para asociar conversaciones, promover contactos y fusionar identidades. Es un buen patrón de evaluación. Poder ver un perfil no tiene por qué incluir la capacidad de unir permanentemente a dos personas.
La reversibilidad también cambia la investigación de errores. En lugar de editar un perfil hasta que parezca correcto, el operador puede restaurar la relación anterior, ver qué regla falló y corregir el mapeo en el sistema de origen.
Pruebe los casos que rompen las demostraciones limpias
Una demostración con un correo y un teléfono prueba muy poco. Evalúe los casos incómodos antes de confiar en la resolución de identidad en producción.
- Dos clientes comparten el correo de su hogar.
- Un número pasa de un empleado a otro.
- Un cliente utiliza dos números de WhatsApp.
- Una franquicia o varios espacios reutilizan el mismo número local de cliente.
- Un nombre visible de Instagram coincide con varios registros del CRM.
- Una importación contiene ID vacíos, cero o valores provisionales.
- Un cliente pide desvincular una cuenta social.
- Un operador une los perfiles equivocados y debe revertir la acción.
En cada caso, compruebe qué ve el agente, qué puede usar la automatización, qué entra en el registro de auditoría y si el contexto privado queda oculto hasta la verificación. Compruebe también si la corrección evita futuros errores o solo arregla un registro visible.
Haga estas preguntas antes de elegir plataforma
La pregunta útil no es si la plataforma ofrece una vista unificada. Pregunte cómo decide que dos identidades de canal pertenecen a la misma persona.
Una evaluación seria debe responder:
- ¿Qué identificador se convierte en la clave estable?
- ¿Qué canales pueden crear o actualizar esa clave?
- ¿Las reglas son exactas, probabilísticas o ambas?
- ¿Puede una coincidencia sugerida quedar sin vincular hasta que alguien la revise?
- ¿Qué verificación adicional exige el trabajo sensible?
- ¿Quién puede fusionar y desvincular identidades?
- ¿Puede el equipo revertir un error sin perder conversaciones?
- ¿Muestra la auditoría el origen, el actor, la regla y el estado anterior?
- ¿Puede pausarse la automatización mientras la identidad sea incierta?
Al evaluar DripTell, la revisión relevante empieza por cómo aparecen las conversaciones compatibles en la bandeja del equipo, cómo se representan los campos en contactos y leads y qué controles describe la página de seguridad. Ejecute la prueba con sus propios registros difíciles. Una demostración con una persona y un número no basta.
El objetivo no es eliminar cada duplicado de inmediato. Es crear contexto fiable para que una persona o automatización actúe sin mostrar el historial del cliente equivocado. Si quiere aplicar esta prueba a un flujo real, lleve un caso de identidad difícil a una demostración de DripTell.
DripTell Editorial
Guías prácticas revisadas por el equipo de producto y flujos de cliente de DripTell.
Consulta cómo DripTell verifica el producto, utiliza fuentes primarias y corrige errores.
Política editorial y de fuentes