Un cliente inicia un chat en vivo preguntando si puede modificar un pedido. Es seguro responder sin conocer su identidad. Después pide cambiar la dirección de entrega. El equipo necesita una identidad fiable, pero el cliente no debería empezar de nuevo.
La autenticación funciona cuando la persona correcta queda verificada dentro de la misma conversación, el trabajo privado permanece cerrado y un fallo tiene una salida segura.
Prueba el límite antes del botón
Microsoft indica que la autenticación mejorada de Dynamics 365 Contact Center alcanza disponibilidad general en septiembre de 2026. Añade OAuth 2.0 junto a JWT, se alinea con Copilot Studio y permite autenticar a un cliente anónimo durante un chat síncrono. Los plazos pueden cambiar, así que confirma la función en el entorno previsto (detalles de la versión de Microsoft).
- 1Empieza con seguridadPermite una pregunta general sin demostrar la identidad.
- 2Pide verificación en el límiteSolicita autenticación antes del trabajo privado de la cuenta.
- 3Vincula el registro correctoConfirma únicamente el cliente activo previsto.
- 4Conserva la conversaciónMantén el texto, el propietario y la explicación tras iniciar sesión.
- 5Recupera sin exponerMantén cerrados los datos privados si la autenticación falla o caduca.
Define el límite de autoridad. Un representante puede explicar horarios o devoluciones sin identificar al visitante. Consultar un pedido, cambiar una dirección o mostrar el historial debe esperar una identidad verificada y el permiso para la acción. Autenticar no autoriza automáticamente cualquier operación.
Escribe dos recorridos antes de configurar
Escribe dos recorridos. En el primero, un cliente anónimo se autentica y continúa. En el segundo, el token falta, caduca, llega tarde o apunta al registro equivocado. Así evitas que un atajo exponga información privada.
| Situación | Estado de identidad esperado | Qué puede hacer el equipo | Evidencia que debe conservarse |
|---|---|---|---|
| Pregunta general | Anónimo | Dar orientación pública | La conversación empieza sin una cuenta |
| Solicitud privada | Autenticación necesaria | Explicar por qué se verifica | La petición aparece en el límite definido |
| Identidad válida | Verificado | Continuar dentro de los permisos | Se vincula el registro activo correcto |
| Token inválido o caducado | Anónimo | Reintentar o ayudar de forma segura | Los campos privados siguen cerrados |
| Registro ambiguo | Sin resolver | Escalar a revisión controlada | No se adivina ni fusiona un registro |
La guía de Microsoft dice que Dynamics 365 distingue clientes anónimos y autenticados y usa variables de contexto en reglas. El representante ve Sí o No en el resumen. Para un portal propio, Microsoft documenta JWT firmado, validación con clave pública y una función que devuelve el token en diez segundos. Un token inválido o caducado genera un error (configuración de autenticación de Microsoft).
Conserva la conversación cuando cambia la autoridad
El cliente no debería repetir el problema original después de iniciar sesión. Prueba que se mantienen la transcripción, el propietario actual, el historial de la cola y el motivo del contacto. Después confirma que se vincula el contacto o la cuenta activa prevista. Un token técnicamente válido unido al registro equivocado es un fallo.
La continuidad importa en el chat web y después de transferir. Si la conversación entra en una bandeja compartida, la siguiente persona debe ver el estado verificado y el contexto útil sin acceder a un token reutilizable ni a datos de identidad innecesarios. Cuando un asistente de IA pide autenticación, comprueba que la automatización se detiene si no se prueba la identidad y que una persona asume la propiedad con claridad.
Prueba el fallo antes del recorrido feliz
Prueba tokens caducados, mal formados y retrasados. Desactiva el proveedor de identidad, usa un registro inactivo y abre dos pestañas para descartar fugas entre sesiones. Deja caducar un token durante una conversación y observa qué trabajo queda bloqueado.
No recompenses el fallo con un atajo más débil. El representante puede explicar el siguiente paso, conservar la parte pública de la conversación, ofrecer un nuevo intento o pasar a un proceso manual cuyos controles ya estén aprobados. No debe adivinar al cliente por su nombre, teléfono o la descripción de un pedido reciente.
Separa identidad acceso y enrutamiento
Las variables de contexto pueden ayudar a dirigir a un cliente verificado, pero prueba cada decisión por separado. Primero confirma si el vínculo de identidad es correcto. Después decide si esa persona puede ver o cambiar los datos solicitados. Finalmente decide si la conversación debe ir a otra cola. Un único resultado positivo no debería aprobar las tres cosas en silencio.
Revisa el acceso basado en funciones de las personas que gestionan conversaciones verificadas. Confirma que los controles de seguridad mantienen el token y los campos de identidad innecesarios fuera de transcripciones, exportaciones y vistas rutinarias. Prueba también el recorrido anónimo para que una pregunta pública sencilla no encuentre una barrera de acceso.
Decide qué evidencia permite publicar
El registro de lanzamiento debe indicar entorno, canal, proveedor, cuentas de prueba, vida del token, coincidencia esperada, acciones permitidas, enrutamiento, fallo y propietario. No guardes secretos ni tokens completos. Incluye una prueba hecha por alguien que no configuró la función.
Define una regla de parada. Pausa si puede vincularse el registro equivocado, un fallo deja ver datos privados, se pierde la transcripción, la propiedad queda confusa o la recuperación depende de una excepción improvisada.
DripTell no sustituye al proveedor de identidad ni a la autorización de Dynamics. Su papel útil viene después, cuando una conversación verificada necesita propiedad clara, visibilidad limitada y una transferencia segura. El equipo de implantación puede ayudarte a definir esa evidencia antes de añadir más automatización.
Preguntas frecuentes
Sustituye la autenticación durante la conversación a la autorización
No. Demuestra quién es el cliente. La aplicación y la política de servicio siguen decidiendo qué registros y acciones puede utilizar esa identidad.
Debe exigir autenticación cada chat en vivo
No. Permite preguntas públicas seguras de forma anónima. Solicita autenticación cuando el trabajo alcanza datos privados o una acción protegida.
Cuál es la prueba de fallo más importante
Usa una identidad aparentemente válida que se vincule al registro equivocado o inactivo. El sistema no debe adivinar, fusionar ni exponer datos mientras la coincidencia no esté resuelta.
Qué debe ocurrir cuando falla la autenticación
Mantén cerrada la información privada, conserva la parte segura del chat, explica el reintento o la vía manual y deja el trabajo con un propietario conocido.
¿Te ayudamos a aplicar esta guía?Pregunta al equipo de DripTell
De la lectura a la acción
¿Quieres aplicar estas ideas en tu negocio?
Déjanos tus datos. Tendremos en cuenta el artículo que estás leyendo y empezaremos con una respuesta útil para tu equipo.
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
