Volver al blog
Customer context

Cómo usar números de referencia de casos en el chat de atención al cliente sin generar más esfuerzo al cliente

Una política práctica para usar referencias de pedidos, entregas, reclamaciones y contactos previos para localizar registros sin confundir búsqueda, autenticación y autorización.

Operador de soporte aplicando una política clara de referencias de caso en una bandeja de entrada compartida de conversaciones con clientes

Por qué las solicitudes de números de referencia generan esfuerzo evitable

Un número de referencia puede agilizar una conversación de soporte, pero solo cuando es la vía fiable más corta para llegar al registro. Genera esfuerzo cuando un operador lo solicita antes de revisar la conversación actual, los registros disponibles mediante los sistemas aprobados por la organización o los datos que el cliente ya ha proporcionado en el mismo proceso.

El fallo habitual es tratar cada solicitud como «Indique su número de referencia». Puede que los clientes no sepan qué número se les pide, que no puedan encontrarlo o que ya lo hayan proporcionado. Una solicitud imprecisa también aumenta la probabilidad de que envíen información personal no relacionada o excesiva.

Defina claramente el objetivo de la política: use una referencia como ayuda de contexto y búsqueda, no como una barrera que los clientes deban superar antes de recibir una ayuda razonable.

  • Busque primero en la conversación actual y en los registros relevantes disponibles mediante sistemas aprobados cuando sea operativo hacerlo.
  • Solicite únicamente el identificador necesario para la solicitud actual.
  • Ofrezca de inmediato una vía alternativa cuando el cliente no tenga el número.
  • No exija volver a introducir información ya proporcionada en el mismo proceso digital, salvo que sea esencial o necesaria por motivos de seguridad.
Por qué las solicitudes de números de referencia generan esfuerzo evitable

Mantenga separadas la búsqueda, la autenticación y la autorización

Un procedimiento operativo sólido separa tres decisiones. Encontrar un caso responde a «¿De qué registro estamos hablando?». La autenticación responde a «¿Ha demostrado esta persona el control del autenticador requerido?». La autorización responde a «¿Puede esta persona autenticada realizar esta acción?».

Una referencia de caso, pedido o reclamación puede ayudar a localizar un registro. No demuestra quién participa en el chat ni concede permiso para revelar datos protegidos, cambiar una dirección, cancelar un pedido, modificar la configuración de una cuenta o realizar otra acción sensible.

Defina procedimientos de verificación y aprobación específicos para cada acción fuera del flujo de trabajo de los números de referencia. Los operadores no deben improvisar solicitando más identificadores hasta sentirse seguros.

  • Búsqueda: use la referencia mínima necesaria para localizar un registro relevante.
  • Autenticación: use el método aprobado por la organización cuando sea necesario establecer la identidad.
  • Autorización: compruebe si la persona autenticada puede solicitar la acción concreta.
  • Nunca pida a los clientes que revelen contraseñas, contraseñas de un solo uso u otros factores de autenticación en un chat ordinario.
Mantenga separadas la búsqueda, la autenticación y la autorización

Cree un mapa de identificadores según el tipo de solicitud

Sustituya la expresión genérica «número de referencia» por un mapa de identificadores controlado. Cada tipo de solicitud debe indicar el identificador preferido, una alternativa aceptable, la finalidad de recopilarlo y las acciones que siguen exigiendo una verificación independiente.

Esto mejora la comprensión del cliente y hace que la gestión interna sea más coherente. También evita que una referencia de entrega se trate como si fuera intercambiable con un registro de reclamación o un identificador de cuenta.

  • Consulta de pedido: solicite la referencia del pedido; use el mensaje de confirmación del pedido como indicación de dónde encontrarla.
  • Problema de entrega: solicite la referencia de entrega o de seguimiento cuando el problema afecte a un envío.
  • Seguimiento de reclamación: solicite la referencia de la reclamación o la referencia de un caso de soporte previo.
  • Solicitud de cuenta: use la vía aprobada de búsqueda de cuenta; no dé a entender que una referencia de pedido verifica la titularidad de la cuenta.
  • Conversación anterior: use la referencia de soporte previo solo para localizar la interacción anterior, no para autorizar una nueva acción.

Decida cuándo debe preguntar un operador

Cree una secuencia breve de decisión que los operadores puedan seguir de forma coherente. Primero, identifique el objetivo del cliente. Después, revise la conversación activa y los registros relevantes disponibles mediante los sistemas aprobados por la organización para encontrar un identificador útil. Solicite una referencia solo si es necesaria para localizar o distinguir el registro relevante y no puede encontrarse razonablemente a partir de la información disponible.

Evite recopilar una referencia simplemente porque podría ser útil más adelante. Si la solicitud puede resolverse sin abrir un registro específico del cliente, no la pida. Si se solicita una acción sensible, pase al proceso aprobado de autenticación y autorización en lugar de basarse en la referencia.

En operaciones compartidas de WebChat y WhatsApp, proporcione la misma secuencia de decisión a todos los departamentos para que las transferencias no reinicien el proceso de recopilación de información.

  • Pregunte cuando varios registros puedan coincidir de forma plausible y la referencia sea el medio menos gravoso para diferenciarlos.
  • No pregunte cuando la referencia ya sea visible en la conversación actual o esté disponible mediante sistemas aprobados.
  • No pregunte cuando una ayuda genérica resuelva el problema.
  • Escale el caso en vez de adivinar cuando los registros entren en conflicto, una coincidencia sea ambigua o la acción solicitada sea sensible.

Utilice un mensaje claro y accesible para el cliente

Un buen mensaje indica qué se necesita, por qué se necesita, dónde encontrarlo y qué ocurre si el cliente no puede localizarlo. Nombre el identificador con precisión. Si un formato esperado resulta útil, proporcione un ejemplo breve sin dar a entender que el formato demuestra el derecho sobre el registro.

Evite abreviaturas sin explicar, listas largas de posibles números y mensajes que obliguen al cliente a buscar en todos sus correos. Las etiquetas e instrucciones claras reducen los errores de entrada; los mensajes de error útiles deben identificar el problema en texto en lugar de limitarse a indicar que una búsqueda ha fallado.

  • Mensaje preferido: «Para localizar la entrega, envíeme la referencia de entrega que aparece en su correo de envío. Suele figurar junto a “Referencia de entrega”. Si no puede encontrarla, dígamelo y le ayudaré por otra vía».
  • Plantilla de formato: sustituya [FORMATO DE SU ORGANIZACIÓN] por el formato real antes de usarla: «La referencia del pedido suele seguir este formato: [FORMATO DE SU ORGANIZACIÓN]. Envíe únicamente la referencia del pedido».
  • Plantilla de formato no válido: sustituya [INDICACIÓN DE FORMATO] por la indicación real antes de usarla: «Eso no parece una referencia de pedido. Revise el correo de confirmación para buscar [INDICACIÓN DE FORMATO]. Si no está disponible, responda “No puedo encontrarla” y lo derivaré para recibir ayuda».
  • Mensaje de búsqueda fallida: «No he podido encontrar un registro que coincida con esa referencia de entrega. Revise los caracteres y envíela de nuevo, o indíqueme si necesita que una persona la revise».

Minimice los datos en el chat de texto libre

El chat de texto libre anima a los clientes a enviar más información de la necesaria. La política debe indicarles exactamente qué identificador proporcionar y desaconsejar de forma explícita los datos no relacionados. Los operadores no deben pedir una recopilación de datos personales «por si acaso».

Use la recopilación de respuestas validadas cuando un formato predecible sea realmente útil, pero mantenga la proporcionalidad. La validación de formato puede mejorar la calidad de los datos; no puede establecer la identidad, demostrar la titularidad ni determinar si un cliente puede realizar una acción.

Revise periódicamente los datos almacenados relacionados con identificadores y elimine la información que ya no sea relevante para la finalidad de soporte definida.

  • Solicite un identificador cada vez siempre que sea posible.
  • No pida a los clientes que peguen secretos de autenticación en el chat.
  • No solicite varias referencias como sustituto de un proceso de verificación aprobado.
  • Use una vía de excepción revisada por una persona cuando una validación rígida excluiría a un cliente legítimo.
  • Limite los registros internos al identificador, su tipo, el resultado de la búsqueda y la siguiente acción, con arreglo a la política de privacidad y seguridad de la organización.

Registre los identificadores de forma coherente en la bandeja de entrada compartida

Una bandeja de entrada compartida necesita una convención de registro para que el siguiente operador pueda entender qué se proporcionó sin volver a preguntar. En webchat.vip, los equipos pueden usar una bandeja de entrada compartida con operadores, departamentos, enrutamiento, plantillas y etiquetas. Configure el flujo de trabajo en torno a un conjunto pequeño y documentado de etiquetas y plantillas aprobadas, en lugar de incluir identificadores no estructurados por todo el contenido de los mensajes de conversación.

Mantenga el registro operativo basado en hechos. Anote el tipo de referencia, el resultado de la búsqueda, si sigue siendo necesaria una verificación y el siguiente responsable en el sistema de registro permitido por la organización. No registre conclusiones de que la referencia autenticó por sí misma al cliente.

Todo registro de identificadores, controles de acceso y períodos de conservación debe seguir la política de privacidad y seguridad de la organización. Evite copiar un identificador en notas cuando ya exista en un registro estructurado permitido. Cuando la organización use notas internas de transferencia en un sistema permitido, úselas para conservar el contexto esencial entre departamentos y use etiquetas únicamente para estados operativos definidos.

  • Etiquetas recomendadas: referencia-solicitada, referencia-recibida, busqueda-coincidente, busqueda-sin-resultados, verificacion-necesaria, revision-humana-necesaria.
  • Ejemplo de registro de transferencia, cuando esté permitido: «Referencia de entrega recibida; la búsqueda encontró un registro; no se ha completado la verificación de identidad; el cliente solicita un cambio de dirección; derivar al proceso de verificación aprobado».
  • Evite registros imprecisos como «cliente verificado» cuando solo se haya proporcionado una referencia.
  • Proporcione a los operadores plantillas aprobadas para solicitudes, fallos y transferencias.

Diseñe alternativas seguras y una vía de escalado humano

La ausencia de una referencia o una referencia sin coincidencia no debe convertirse en un callejón sin salida. Los clientes pueden haber eliminado un mensaje, recibido un número incorrecto, no tener acceso a un dispositivo o cuenta de correo electrónico, o necesitar apoyo de accesibilidad. Proporcione a los operadores una vía alternativa documentada que sea adecuada para la solicitud y no fomente la recopilación innecesaria de datos.

La automatización puede recopilar una referencia, comprobar un formato definido, bifurcar el flujo según el resultado y transferir la conversación. En webchat.vip, los flujos automatizados pueden recopilar respuestas validadas, enviar mensajes o archivos, bifurcarse y transferir conversaciones a personas. Use estas capacidades para reducir la fricción rutinaria, no para tomar una decisión no revisable sobre identidad o derecho.

Establezca desencadenantes explícitos para la intervención de una persona. La transferencia debe indicar al cliente qué sucederá después, y el operador que la reciba debe usar la conversación actual y los registros permitidos para evitar solicitudes repetidas innecesarias.

  • Escale a una persona cuando el cliente no pueda encontrar el identificador tras recibir indicaciones claras.
  • Escale cuando una referencia no encuentre resultados después de una comprobación cuidadosa, o cuando parezcan posibles varios registros.
  • Escale de inmediato ante limitaciones de accesibilidad o tecnología, sospecha de compromiso de cuenta, inquietudes de privacidad, disputas, preocupaciones de protección o acciones sensibles que requieran verificación aprobada.
  • Indique al cliente: «Voy a transferir esto a un especialista de soporte que puede revisar las alternativas. Me aseguraré de que pueda ver la información que ya ha compartido cuando nuestro proceso lo permita».
  • Proporcione al operador receptor el tipo de solicitud, el resultado de la búsqueda, la información relevante de la conversación y el motivo de la escalada mediante el proceso permitido por la organización.

Preguntas frecuentes

¿Es un número de referencia de caso de atención al cliente una prueba de identidad?

No. Una referencia de caso ayuda a encontrar un registro. La autenticación de identidad y el permiso para realizar una acción requieren procesos independientes y aprobados.

¿Qué debe hacer un operador si el cliente no tiene su número de referencia?

Explique dónde puede encontrarlo y ofrezca después la vía alternativa documentada. Si el problema no puede resolverse de forma segura, transfiera la conversación a una persona o a un equipo de gestión de excepciones en vez de finalizar el chat.

¿Debe un chatbot rechazar toda referencia que no coincida con un formato?

No. Las comprobaciones de formato pueden identificar probables errores de introducción, pero un cliente puede tener un identificador válido en otro formato. Explique el error, ofrezca una sugerencia de corrección cuando sea seguro y proporcione una vía humana.

¿Qué debe registrarse después de buscar una referencia?

Registre el tipo de referencia, el resultado de la búsqueda, la siguiente acción y si sigue siendo necesaria una verificación independiente, con arreglo a la política de privacidad, seguridad y conservación de la organización. Use etiquetas definidas y registros operativos permitidos para que los clientes no tengan que repetir información innecesariamente.

¿Cómo pueden mejorar los equipos una política de referencias de caso con el tiempo?

Revise los registros de conversaciones, la analítica operativa y los informes exportables, y obtenga o supervise métricas registradas localmente, como búsquedas fallidas, solicitudes repetidas y patrones de transferencia, cuando la organización las registre. Actualice los mensajes, mapas de identificadores, plantillas y reglas de escalado cuando los patrones muestren esfuerzo evitable.

Fuentes y lecturas adicionales

Referencias primarias y autorizadas usadas para verificar la base factual de esta guía.

  1. NIST SP 800-63-4 — Digital Identity Guidelines — National Institute of Standards and Technology
  2. NIST SP 800-63A-4 — Identity Proofing and Enrollment — National Institute of Standards and Technology
  3. NIST SP 800-63B-4 — Authentication Assurance Levels — National Institute of Standards and Technology
  4. WCAG 2.2 — World Wide Web Consortium
  5. Understanding Success Criterion 3.3.2: Labels or Instructions — W3C Web Accessibility Initiative
  6. Understanding Success Criterion 3.3.1: Error Identification — W3C Web Accessibility Initiative
  7. Data minimisation guidance — Information Commissioner's Office