¿Te ayudamos a aplicar esta guía?Pregunta al equipo de DripTell
Un cliente pide por chat cambiar el correo electrónico de su cuenta. Conoce el nombre, el número de pedido y el código postal. Esos datos ayudan a encontrar el registro, pero no demuestran que la persona tenga permiso para modificarlo.
No recopiles más secretos en la misma conversación. Empieza por la acción, valora el daño de una aprobación errónea y usa una ruta autorizada. El chat no debe almacenar contraseñas, códigos de un solo uso, documentos de identidad ni respuestas de recuperación.
Empieza por la acción solicitada
La verificación protege una acción concreta, no justifica el mismo interrogatorio para todos. Explicar una política, revelar un pedido, cambiar un factor de recuperación y liberar dinero tienen riesgos diferentes.
- 1Nombra la acciónDefine exactamente qué quiere revelar, cambiar o liberar el cliente.
- 2Valora el dañoEvalúa la consecuencia de aprobar para la persona equivocada.
- 3Elige la rutaUsa la verificación o recuperación aprobada para ese riesgo.
- 4Separa la pruebaNo pidas contraseñas, códigos o documentos dentro del chat.
- 5Registra el resultadoGuarda resultado, responsable y siguiente paso, no secretos sin procesar.
Documenta qué acciones no requieren acceso a la cuenta, cuáles exigen una sesión autenticada y cuáles necesitan recuperación reforzada o una aprobación adicional. Esa política debe estar visible en la bandeja de equipo, no depender de la memoria del agente.
Las Directrices de Identidad Digital de NIST explican requisitos para prueba de identidad, autenticación y federación, incluida la experiencia del cliente. No son un guion de soporte. Diseña el camino antes de una conversación bajo presión.
Ajusta la comprobación al posible daño
Pregunta qué permitiría una aprobación a la persona equivocada. La respuesta determina la comprobación y quién autoriza una excepción.
| Acción solicitada | Posible daño si hay un error | Respuesta de verificación más segura | Qué conservar en el chat |
|---|---|---|---|
| Explicar una política pública de devoluciones | Poco o ningún daño de cuenta | Normalmente no hace falta verificar identidad | Pregunta y respuesta |
| Revelar datos de pedido o cuenta | Información privada llega a otra persona | Cuenta autenticada o factor aprobado | Resultado y hora de la verificación |
| Cambiar correo o factor de recuperación | El acceso futuro puede desviarse | Recuperación documentada y revisión reforzada | Resultado, revisor y siguiente paso |
| Liberar dinero, acceso u objeto valioso | Pérdida directa o acceso no autorizado | Control aprobado de alto riesgo y segunda autorización cuando corresponda | Decisión y referencia de autorización |
No añadas preguntas por el tono o el origen del cliente. La acción y la evidencia deben dirigir una decisión coherente.
Saca la prueba del chat abierto
Un chat solo demuestra que alguien puede escribir. Un número de WhatsApp puede ser compartido, reasignado o comprometido. El historial aporta contexto, no autenticación.
Para una operación sensible, usa una ruta controlada: cuenta autenticada, enlace aprobado, devolución de llamada verificada o recuperación formal. No pidas contraseñas, códigos, números de pago completos ni documentos en una conversación normal.
Este límite pertenece al modelo de seguridad y al manual del canal. Un flujo de soporte por WhatsApp debe decir qué puede hacer el canal, qué no demuestra y cómo trasladar una solicitud sensible sin abandonar al cliente.
Registra el resultado no el secreto
Soporte necesita una pista de auditoría. El registro útil suele ser breve: acción solicitada, ruta aprobada, resultado, responsable de la excepción y siguiente paso. La evidencia sin procesar a menudo añade riesgo sin ayudar al próximo agente.
NIST SP 800-63A-4 define la prueba de identidad como un proceso en el que la evidencia respalda una identidad con un nivel útil de garantía. Soporte debe mantener clara la misma frontera. Encontrar una cuenta no equivale a autenticar al solicitante, y ninguna tarea exige conservar la evidencia sin procesar en el chat. Guarda solo el resultado que exige la política.
Cuando proceda, conserva el estado de verificación junto al registro del cliente en el CRM. Limita quién puede verlo y fija un plazo de conservación. No premies la recopilación de más evidencia de la necesaria.
Ofrece una salida honesta cuando falle
Un cliente legítimo puede perder su teléfono, correo o autenticador. Hacer preguntas más fáciles no resuelve el problema: la insistencia no prueba identidad.
Define una recuperación con responsable, evidencia permitida y actualizaciones claras. Una excepción de alto riesgo puede requerir otro revisor. Si no hay verificación segura, detén la acción sin cerrar el caso como resuelto.
Unas buenas operaciones de soporte hacen útil esa negativa. Explica qué no puede hacerse todavía, qué opción aprobada queda, quién posee el siguiente paso y cuándo habrá noticias.
Crea un proceso que el equipo pueda seguir
Elige diez solicitudes sensibles. Define daño, ruta, dueño de la excepción, datos prohibidos, auditoría y mensaje al cliente. Prueba el proceso con agentes nuevos y personas que no puedan usar el método habitual.
Usa la automatización para enrutar y recordar, no para declarar una identidad a partir de señales débiles. Una regla puede pausar un cambio de cuenta y asignar un revisor. Un nombre coincidente o un número conocido no se convierte por ello en una prueba.
Revisa controles aprobados, fallidos y abandonados. Busca preguntas improvisadas, excepciones sin dueño y secretos guardados. La mejor verificación es la comprobación aprobada más pequeña que protege la acción y deja un siguiente paso claro.
Preguntas frecuentes
Basta un número de pedido para verificar al cliente
Normalmente no para una acción sensible. Ayuda a encontrar el registro, pero puede aparecer en un correo, un paquete o un documento compartido. Usa la ruta aprobada para esa acción.
Debe un agente pedir un código de un solo uso por chat
No. El cliente debe introducirlo únicamente en el flujo de autenticación aprobado. Pegarlo en el chat crea un secreto activo en el historial y enseña un hábito inseguro.
Demuestra identidad un número de teléfono conocido
No. Ofrece contexto, pero el teléfono o la cuenta pueden ser compartidos, reasignados o comprometidos. Ajusta la comprobación a las consecuencias de la acción.
Qué ocurre cuando falla la verificación
Detén la acción sensible, conserva la propiedad de la conversación y ofrece la ruta documentada de recuperación o excepción. Registra el resultado y el siguiente paso sin guardar evidencia innecesaria.
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