Volver al blog
Automation flows

Cómo gestionar varias solicitudes de clientes en un chat sin perder la segunda

Un modelo operativo práctico para identificar, priorizar y dar seguimiento a necesidades secundarias de los clientes mediante automatización, transferencias y cierre.

Operador de soporte revisando un chat de cliente con dos solicitudes distintas

Un chat puede incluir más de una obligación de servicio

Un cliente puede escribir: «¿Dónde está mi pedido y pueden cambiar el correo electrónico de mi cuenta?». Tratarlo como una sola intención genera un fallo silencioso: el equipo resuelve la pregunta visible sobre la entrega y después cierra la conversación mientras la solicitud sobre la cuenta desaparece.

La unidad operativa no siempre es el hilo de chat. Es cada tarea individual que necesita una respuesta, acción, responsable o seguimiento. Un solo hilo puede contener varias solicitudes, y una solicitud puede seguir sin resolverse aunque otra esté completada.

Esto importa especialmente en las transiciones: un flujo puede encaminar el hilo según una opción o respuesta estructurada inicial, una transferencia mueve el hilo a un especialista o un operador utiliza una plantilla de cierre tras resolver solo una parte. Diseña cada transición para conservar las solicitudes sin resolver en tu procedimiento operativo.

  • Las solicitudes relacionadas se refieren al mismo resultado, como cambiar una dirección de entrega y comprobar si el cambio se realizó correctamente.
  • Las solicitudes dependientes deben realizarse en un orden determinado, como verificar una cuenta antes de cambiar sus datos.
  • Las solicitudes separadas requieren trabajo, responsables o expectativas de servicio distintos, como investigar una entrega además de cambiar datos de una cuenta.
  • Una solicitud separada no debe descartarse silenciosamente solo porque llegó en segundo lugar.
Un chat puede incluir más de una obligación de servicio

Clasifica las solicitudes antes de elegir una intención principal

Empieza por resumir las solicitudes en los propios términos del cliente. Esto confirma la comprensión y crea un registro claro para el siguiente operador. Por ejemplo: «Puedo ayudarle con el estado de su entrega y con el cambio de su dirección de correo electrónico».

Después, decide si una solicitud bloquea realmente la otra. Si es así, explica claramente la dependencia y avanza paso a paso. Si las solicitudes son independientes, el equipo puede resolverlas en secuencia, dividir internamente la responsabilidad o preguntar al cliente qué asunto es más urgente cuando los plazos o la política lo hagan necesario.

No hagas que los clientes repitan una explicación extensa solo para ajustarse a un menú. La información ya proporcionada debe estar disponible para la persona que gestiona la solicitud activa siempre que el proceso lo permita. Pide únicamente los datos que falten y sean necesarios para la siguiente acción.

  • Usa una elección del cliente cuando ambas solicitudes sean independientes, ninguna sea urgente y las opciones disponibles sean breves y claramente distintas.
  • Usa el triaje de un operador o humano cuando el mensaje sea ambiguo, contenga más de dos necesidades, incluya una queja o una posible preocupación de seguridad, o pueda requerir equipos diferentes.
  • Prioriza la seguridad, la seguridad de la cuenta, los fallos de servicio urgentes y la urgencia explícita del cliente antes que el trabajo administrativo rutinario.
  • Registra por qué se ha secuenciado o aplazado el trabajo, especialmente cuando se aplique un objetivo de nivel de servicio.
Clasifica las solicitudes antes de elegir una intención principal

Utiliza un patrón seguro de recepción de múltiples intenciones

Una primera respuesta fiable tiene cuatro partes: reconocer, resumir, priorizar y conservar. Debe mostrar al cliente que se han entendido ambos asuntos, pedir como máximo una decisión a la vez e indicar qué ocurrirá con el otro asunto.

Ejemplo: «Veo dos solicitudes: comprobar su entrega y cambiar el correo electrónico de su cuenta. ¿Cuál quiere que atendamos primero? Mantendré la otra solicitud en esta conversación para darle seguimiento». Si la entrega es urgente, un operador puede indicar en su lugar el orden propuesto: «Primero comprobaré la entrega porque está prevista para hoy; después gestionaré el cambio de correo electrónico».

Evita pedir en una sola respuesta toda la información que falta para ambas tareas. Es posible que las personas respondan solo a una pregunta, lo que genera incertidumbre sobre el resto. Recopila la información necesaria para la tarea activa y después vuelve explícitamente al asunto aplazado.

  • Reconoce cada solicitud identificable antes de crear una rama o realizar una transferencia.
  • Resume con lenguaje breve y concreto; no reinterpretes una solicitud como una promesa que el equipo no puede cumplir.
  • Formula una pregunta o pide una decisión por mensaje cuando sea práctico.
  • Documenta la solicitud secundaria en la conversación o en el proceso establecido de seguimiento del equipo antes de abordar la tarea principal.
  • Tras la tarea principal, retoma explícitamente el asunto secundario: «Su pregunta sobre la entrega ya está respondida. ¿Continuamos ahora con el cambio de correo electrónico?»

Usa la automatización para elecciones acotadas, no para interpretaciones forzadas

Los flujos automatizados de webchat.vip pueden enviar mensajes y archivos, recopilar respuestas validadas, crear ramas, transferir y derivar a personas. Estas capacidades son útiles para una elección acotada y bien comprendida, como preguntar si un cliente desea empezar por el estado de la entrega o por los datos de la cuenta.

La automatización debe dirigir directamente al triaje humano en lugar de forzar una elección cuando no pueda conservar con confianza el mensaje completo, cuando el cliente dé una explicación en texto libre o cuando la propia elección pueda afectar al acceso, la privacidad, la seguridad o el resultado de una queja. La automatización puede organizar el siguiente paso; no debe ocultar la incertidumbre.

En una bandeja de entrada compartida, configura el enrutamiento en función del trabajo necesario, no simplemente de la primera palabra clave detectada o del departamento seleccionado al inicio. Una palabra clave de entrega no convierte una solicitud de cambio de cuenta en responsabilidad del equipo de entregas. La configuración de enrutamiento y flujos automatizados de webchat.vip son las reglas operativas de tu equipo; no controlan cómo un proveedor de canal externo entrega los mensajes.

  • No ofrezcas más opciones de las que el cliente pueda revisar rápidamente e incluye una ruta clara para recibir ayuda humana.
  • Haz que «Otra cosa» o «Necesito ayuda con ambos» sean resultados de escalamiento, no callejones sin salida.
  • Antes de implementar una transferencia, comprueba que el equipo receptor cuenta con los detalles de la conversación y el resumen necesarios para continuar sin repeticiones innecesarias.
  • Prueba las interrupciones: un cliente puede introducir una segunda solicitud, hacer una pregunta a mitad de la recepción o cancelar la ruta actual.
  • Revisa las ramas después de los cambios con casos de prueba representativos de múltiples intenciones.

Haz que la validación sea recuperable y accesible

Las respuestas validadas pueden mejorar la calidad de los datos, pero un bucle de respuesta no válida es una forma habitual de perder la segunda solicitud original. Si un cliente responde con una explicación en lugar del formato esperado, conserva el mensaje, explica por texto qué no se ha aceptado y ofrece un siguiente paso práctico.

Para las experiencias web, las WCAG 2.2 requieren que los errores detectados automáticamente identifiquen el elemento erróneo y describan el error en texto. Cuando se conozca una corrección, proporciónala salvo que hacerlo perjudique la seguridad o la finalidad del contenido. Acepta formatos de entrada legítimos cuando sea posible, en lugar de tratar variaciones inocuas como un fallo.

Nunca utilices la validación para recopilar información sin un propósito definido. Explica por qué se necesita un dato cuando no sea evidente y proporciona una vía humana si el cliente no puede o no debe facilitarlo por chat.

  • Mal: «Respuesta no válida. Inténtelo de nuevo».
  • Mejor: «Elija “entrega” o “cuenta” para que sepa por dónde empezar. Si necesita ayuda con ambos, responda “ambos” y derivaré el caso a un compañero de soporte».
  • Mantén límites de reintentos; después de varios fallos, deriva el caso con el texto original del cliente y las respuestas que intentó proporcionar.
  • No solicites datos sensibles mediante una rama genérica solo para clasificar una solicitud.
  • Prueba el widget de WebChat para comprobar que ofrece texto de error claro, funcionamiento con teclado, lenguaje comprensible y acceso con lectores de pantalla.

Mantén visible el trabajo secundario sin crear propiedad duplicada

El control clave es un proceso de seguimiento documentado con un responsable asignado o una cola de seguimiento definida. En webchat.vip, los equipos pueden organizar operadores, departamentos, enrutamiento, horarios, niveles de servicio, plantillas y etiquetas. Utiliza la configuración disponible y el proceso documentado de tu equipo para que las solicitudes sin resolver sean visibles para la persona o cola responsable de la siguiente acción.

Una etiqueta puede señalar una solicitud secundaria, pero una etiqueta por sí sola no demuestra que haya un responsable. Define qué significa cada etiqueta, quién la supervisa, cuándo debe atenderse y cómo se elimina. Si el trabajo debe pasar a otro equipo, utiliza un resumen conciso y verifica que el equipo receptor tenga suficiente contexto para evitar que el cliente vuelva a explicar el caso.

Evita crear dos conversaciones de cliente independientes a partir de un solo mensaje, salvo que tu modelo operativo pueda conservar el contexto, la responsabilidad y la comunicación con el cliente en ambas. Dividir el trabajo puede ser adecuado internamente; hacer que el cliente persiga dos hilos normalmente no lo es.

  • Registro mínimo de seguimiento: resumen de la solicitud, estado actual, siguiente responsable o cola, siguiente acción, momento límite y detalles relevantes de la conversación.
  • Utiliza un proceso documentado que diferencie «aplazado», «a la espera del cliente», «transferido» y «resuelto»; no trates el cierre de una conversación como prueba de que todas las solicitudes están resueltas.
  • Si una transferencia falla, la cola receptora no está disponible o la responsabilidad no está clara, escala el caso a un responsable de soporte designado o supervisor de cola.
  • Cuando haya datos personales o de cuenta implicados, aplica tus procedimientos de control de acceso y verificación antes de realizar cambios.

Cierra solo después de comprobar la resolución de los dos asuntos

Antes de cerrar, el operador debe comprobar cada solicitud identificada durante la recepción, incluidas las solicitudes introducidas durante transferencias o interrupciones. Un mensaje de cierre debe distinguir lo que está completado de lo que sigue pendiente e indicar al cliente qué sucederá después.

Un patrón de cierre útil es: «Se ha comprobado el estado de su entrega. El cambio de su dirección de correo electrónico se ha enviado al equipo de cuentas y sigue pendiente. Le informaremos aquí cuando ese trabajo esté completado». Utiliza lenguaje sobre plazos solo si tu equipo realmente puede cumplirlo.

Si la solicitud del cliente no está clara, puede ser perjudicial, afecta a la seguridad, tiene importancia legal o excede la autoridad del operador, no adivines. Escala el caso al equipo humano capacitado adecuado, proporciona el resumen completo y el contexto disponible, e informa al cliente de que un compañero revisará el asunto.

  • Lista de comprobación de cierre: ¿Se han enumerado todas las solicitudes distintas?
  • Lista de comprobación de cierre: ¿Cada solicitud está marcada como resuelta, pendiente, transferida o a la espera del cliente en el proceso del equipo?
  • Lista de comprobación de cierre: ¿Cada solicitud pendiente tiene un responsable, una siguiente acción y una vía de seguimiento?
  • Lista de comprobación de cierre: ¿El cliente ha recibido un estado en lenguaje claro para cada solicitud?
  • Lista de comprobación de cierre: ¿El registro de la conversación ha recogido la transferencia y la justificación de la decisión cuando sea necesario?

Mide el fallo que intentas evitar

La calidad de la gestión de múltiples intenciones no puede evaluarse solo por la velocidad de la primera respuesta o el volumen general de conversaciones. Revisa los registros de conversaciones y la analítica operativa para comprobar que una segunda solicitud se reconoció, se asignó mediante el proceso del equipo y se completó. webchat.vip registra analítica operativa, registros de conversaciones, valoraciones e informes exportables, que pueden servir de apoyo para esta revisión.

Las muestras de chats de ramas automatizadas, transferencias y conversaciones cerradas son especialmente valiosas. Busca conversaciones en las que el cliente repita una segunda solicitud, responda «¿y qué pasa con...?», sea transferido más de una vez o reabra un chat cerrado recientemente. Son señales de que se perdió el contexto o la responsabilidad.

Utiliza los hallazgos para perfeccionar la redacción de las intenciones, las reglas de enrutamiento, las plantillas y las rutas de escalamiento. Las entradas inesperadas son normales en producción; trátalas como comentarios para el diseño y no como un error del cliente.

  • Mide la proporción de chats auditados con múltiples intenciones en los que cada solicitud identificada tiene un estado final registrado.
  • Mide los patrones de reapertura o contacto repetido después de chats que implicaron una transferencia o rama de automatización.
  • Mide los bucles de respuesta no válida, las derivaciones al triaje humano y las excepciones de solicitudes secundarias sin responsable.
  • Revisa si los informes de nivel de servicio reflejan la gestión del equipo de cada solicitud, no solo la primera respuesta de la conversación.
  • Exporta únicamente la información necesaria para la revisión y sigue los requisitos de privacidad, retención y control de acceso de tu organización.

Preguntas frecuentes

¿Los clientes siempre deben elegir un asunto principal?

No. Pide una elección solo cuando las solicitudes sean independientes, fáciles de distinguir y seguras de secuenciar. Envía los casos ambiguos, urgentes, sensibles para la seguridad o complejos al triaje humano, incluyendo ambas solicitudes en el resumen de la transferencia.

¿Cómo evitamos que una solicitud secundaria se pierda después de una transferencia?

Documenta la solicitud antes de la transferencia, incluye un resumen breve de las dos solicitudes y la siguiente acción, y asigna la solicitud sin resolver a un responsable identificado o a una cola supervisada dentro de tu proceso operativo. Durante la implementación, verifica que el equipo receptor tenga los detalles necesarios para continuar.

¿Puede un flujo automatizado gestionar dos solicitudes de clientes a la vez?

Puede presentar una elección de prioridad sencilla y, cuando el diseño del flujo recoge explícitamente ambas solicitudes, registrarlas para crear una rama, transferir o derivar a personas. No fuerces al flujo a interpretar mensajes ambiguos o explicaciones complejas en texto libre: conserva el mensaje original y envía esos casos al triaje humano.

¿Qué debe ocurrir cuando el cliente da una respuesta que no supera la validación?

Explica por texto qué necesita corregirse, ofrece un ejemplo u opción válidos cuando corresponda, mantén disponible la solicitud original y escala el caso tras varios fallos. Evita los mensajes de error genéricos y no trates una respuesta inesperada como prueba de que el cliente ha abandonado el segundo asunto.

¿Quién debe responsabilizarse de una solicitud que abarca varios departamentos?

Asigna un responsable o una cola con responsabilidad final para coordinar el resultado de cara al cliente, aunque equipos especialistas realicen acciones separadas. El coordinador debe mantener informado al cliente y confirmar el estado de cada solicitud antes del cierre.

Fuentes y lecturas adicionales

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

  1. Dialogflow CX: General agent design best practices — Google Cloud Documentation
  2. Handle user interruptions — Microsoft Learn
  3. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative
  4. Validating Input — W3C Web Accessibility Initiative
  5. Structuring forms — GOV.UK Service Manual
  6. Omnichannel customer communication — webchat.vip