Cómo redactar mensajes de espera y transferencia en atención al cliente que establezcan expectativas claras
Los mensajes de espera, cola y transferencia son compromisos operativos, no texto de relleno. Aprende a definir estados de servicio, establecer plazos creíbles y mantener una vía clara hacia la ayuda humana.
Por qué el silencio aumenta el esfuerzo del cliente
Un cliente que ha enviado un mensaje pero no puede saber si se recibió, se puso en cola o se transfirió tiene que deducir cuál es el siguiente paso. Las reacciones habituales son enviar el mismo mensaje de nuevo, probar otro canal, pedir una actualización o abandonar la conversación. Estas acciones aumentan la demanda y, al mismo tiempo, dificultan la gestión del problema original.
Un acuse de recibo amable no es suficiente si no refleja el modelo operativo real. Los mensajes de estado deben indicar a los clientes qué se sabe en ese momento, qué ocurrirá después y qué pueden hacer si esa vía no es adecuada. Trátalos como parte de la gestión de reclamaciones y del diseño del servicio, y revísalos a medida que cambien las operaciones.
- No uses un mensaje de espera para ocultar una cola, una transferencia o una interrupción del servicio.
- No des a entender que un agente está trabajando activamente en un caso a menos que realmente se le haya asignado.
- No declares un problema como resuelto solo porque se haya reducido el impacto; la mitigación y una solución permanente son estados distintos.
- Usa el mismo vocabulario operativo en la automatización, los agentes, el contenido de ayuda y los procedimientos de escalado.
Primero, define los estados de servicio visibles para el cliente
Redacta mensajes solo después de acordar los estados que los clientes realmente pueden encontrar. La asignación interna puede ser compleja, pero los estados de cara al cliente deben ser pocos, distintos y accionables. Cada estado debe tener una condición de entrada, un responsable, una condición de salida y una regla de mensaje claros.
Evita mostrar etiquetas internas, como códigos de equipo o estados de ticket, sin explicarlas. Por ejemplo, un estado interno de pendiente puede significar que el equipo necesita información del cliente; un estado en espera puede significar que necesita información de otro equipo. Los clientes necesitan el significado práctico, no la etiqueta administrativa interna.
- Recibido: el mensaje ha llegado. Indica si se espera una respuesta y qué ocurrirá después.
- En cola: la solicitud está esperando a una persona adecuada para responder. Identifica la cola o el servicio cuando resulte útil, sin inventar un tiempo de respuesta.
- Asignado: una persona o equipo identificado es responsable de la siguiente respuesta. Úsalo solo cuando la asignación sea real.
- Transferido: otro equipo o especialista es ahora responsable de la siguiente acción.
- En espera del cliente: explica exactamente qué información o acción se necesita y por qué.
- Retrasado: explica el impacto conocido, el siguiente momento o desencadenante de actualización, y cualquier alternativa segura.
- Cerrado: confirma el resultado o el motivo del cierre y explica cómo reabrir o buscar más ayuda cuando exista esa vía.
Usa una estructura de cinco partes para los mensajes de estado
Los mensajes útiles de espera y transferencia en atención al cliente responden a las preguntas que, de otro modo, haría el cliente: ¿Qué ha ocurrido? ¿Quién es responsable de la siguiente acción? ¿Qué ocurrirá después? ¿Cuándo debo esperar otra actualización, si se sabe? ¿Qué puedo hacer ahora? Mantén un lenguaje claro y específico para la situación.
El elemento temporal es condicional. Si no puedes respaldar un tiempo estimado de respuesta fiable, indica en su lugar cuándo actualizarás al cliente o describe el evento que activará el siguiente mensaje. La ausencia honesta de un plazo estimado es más útil que una estimación aparentemente precisa que los equipos no pueden cumplir.
- Estado actual: “Hemos recibido tu mensaje y está esperando al equipo de facturación.”
- Siguiente acción: “Un especialista de facturación revisará los datos de cuenta que compartiste.”
- Responsabilidad: “El equipo de facturación es ahora responsable de la siguiente respuesta.”
- Plazo: proporciona un tiempo estimado de respuesta, una franja o una hora concreta de actualización solo cuando se base en datos actuales del servicio y en el horario, calendario y zona horaria aplicables.
- Vía alternativa: ofrece un paso de autoservicio relevante, otro método de contacto o una vía de escalado cuando corresponda.
Elige deliberadamente entre un tiempo estimado, una franja o ninguna estimación
Un tiempo estimado de respuesta es un compromiso, no una frase de cortesía. Úsalo solo cuando la demanda histórica, los datos de tiempo de gestión y el horario aplicable al canal o servicio lo respalden, y cuando el equipo pueda supervisar los compromisos incumplidos. Una franja de tiempo suele ser más segura cuando el trabajo depende de una clasificación inicial, un especialista o una dependencia externa.
No uses una estimación de respuesta cuando la duración sea realmente desconocida, la cola sea inestable o todavía se esté evaluando una incidencia. Sustitúyela por un compromiso de actualización creíble, como un punto de revisión indicado, o por una promesa basada en un evento como “Actualizaremos esta conversación cuando hayamos confirmado el alcance”. No prometas un plazo de resolución cuando solo puedes prometer otra comunicación.
- Usa un tiempo estimado específico cuando la capacidad y el horario laboral aplicable al canal o servicio hagan que sea fiable.
- Usa una franja cuando se prevea variación: “Esperamos responder durante el siguiente día laborable aplicable a este servicio.”
- Usa un punto de actualización cuando se desconozca la duración: “Publicaremos una actualización aquí antes de las 16:00, hora local aplicable a este servicio, aunque la investigación siga en curso.”
- Usa una actualización basada en un evento cuando una hora concreta no sea creíble: “Te actualizaremos cuando termine la revisión del especialista.”
- No digas nunca “en breve”, “lo antes posible” o “un representante te atenderá” a menos que la práctica operativa dé a esas frases un significado definido y supervisado.
Redacta mensajes de cola sin garantizar una respuesta
Un mensaje de cola debe confirmar la recepción y describir el siguiente paso de gestión sin exagerar la disponibilidad. “Un agente te atenderá pronto” puede interpretarse como una garantía, especialmente fuera del horario de atención o durante picos de demanda. También resulta engañoso si la conversación se transfiere después a otro equipo.
Indica claramente la condición del servicio. Si el equipo está cerrado, dilo. Si la conversación está en cola, indica que está en cola. Si solo hay respuesta disponible para determinados tipos de solicitud, no presentes el acuse de recibo como una cobertura de soporte universal.
- Patrón más seguro: “Hemos recibido tu mensaje. Nuestro equipo de soporte revisa los mensajes nuevos durante el horario publicado y aplicable a este servicio. Responderemos aquí cuando tu solicitud llegue a un agente disponible.”
- Patrón de alta demanda: “Hemos recibido tu solicitud. Hoy las respuestas están tardando más de lo habitual. No envíes los mismos datos otra vez; están adjuntos a esta conversación.”
- Patrón fuera de horario: “Nuestro equipo de soporte en directo no está disponible en este momento. Tu mensaje ha quedado registrado para revisarlo cuando comience el siguiente periodo de cobertura programado y aplicable a este servicio.”
- Modo de fallo: aparece un acuse de recibo genérico incluso cuando falla la asignación. Añade un procedimiento de supervisión y respaldo para que este mensaje no se confunda con la creación correcta de un caso.
Haz que los mensajes de transferencia conserven el contexto y la responsabilidad
Un mensaje de transferencia debe evitar que el cliente se pregunte si lo han transferido de un lado a otro o si tiene que empezar de nuevo. Explica por qué se realiza la transferencia en términos comprensibles para el cliente, identifica al nuevo responsable en un nivel adecuado y confirma de forma precisa qué información se ha transferido o qué acceso al historial tiene el equipo receptor.
No pidas al cliente que repita detalles que ya están presentes en la conversación si el equipo receptor tiene acceso al historial. Si no lo tiene, indica qué información se ha transferido y solicita solo los datos necesarios. Un nuevo equipo puede necesitar una aclaración, pero debe plantear una pregunta concreta. Si la transferencia no se ha completado, no digas todavía que otro equipo es responsable del caso.
- Plantilla de transferencia: “Voy a transferir esta conversación a nuestro equipo de [equipo] porque gestiona [tema]. Hemos transferido [información específica] al equipo. Su siguiente respuesta aparecerá en esta conversación.”
- Plantilla de revisión por especialista: “Tu solicitud necesita una revisión de un especialista. Hemos transferido al equipo de [equipo] la información que proporcionaste: [información específica]. Te actualizaremos aquí cuando termine su revisión.”
- Plantilla de aclaración: “El equipo de [equipo] necesita un dato para continuar: [pregunta específica].”
- Modo de fallo: se anuncia una transferencia, pero ningún destino la acepta. Define un responsable y una vía de alerta para las transferencias no aceptadas o que llevan demasiado tiempo pendientes.
Diferencia la automatización de la respuesta de una persona identificada
Los clientes deben poder distinguir un acuse de recibo automatizado de un mensaje escrito por un operador. Esto protege la confianza y les ayuda a decidir si responder de inmediato será útil. La automatización puede confirmar la recepción, recopilar información validada, proporcionar un siguiente paso conocido, ramificar un flujo, transferir conversaciones y entregarlas a personas; no debe fingir ser una persona.
Cuando se incorpore una persona, deja clara esa transición. Un operador identificado puede confirmar que ha revisado los mensajes previos e indicar la siguiente acción. Si un flujo automatizado recopila información, explica por qué se necesita cada dato solicitado y evita recopilar datos que no sean necesarios para la solicitud.
- Acuse de recibo automatizado: “Mensaje automatizado: hemos recibido tu solicitud y estamos comprobando cuál es la vía adecuada para ella.”
- Mensaje de incorporación de una persona: “Hola, soy Sam del equipo de Soporte. He revisado los datos que compartiste. Ahora comprobaré [siguiente acción específica].”
- No uses un nombre humano, un indicador de escritura ni expresiones en primera persona en la automatización si podrían dar a entender razonablemente que una persona ha leído la conversación.
- Proporciona una forma de detener u omitir un flujo cuando el cliente necesite ayuda que el flujo no pueda proporcionar de forma segura.
Planifica para fuera de horario, retrasos inesperados e incidencias
Los horarios, los festivos y las reglas de asignación deben coincidir con el lenguaje que ven los clientes. Revisa cada canal, departamento y periodo de cobertura. Un mensaje que promete una respuesta entre semana es inexacto si se aplica un festivo local, una zona horaria distinta o un horario diferente al equipo asignado.
Ante una incidencia, comunica el impacto conocido, el progreso actual hacia la mitigación, cualquier alternativa segura y el momento de la siguiente comunicación. Un aviso inicial puede ser breve cuando sea importante notificar con rapidez; actualízalo a medida que se confirmen los hechos. Indica que el servicio se ha restablecido solo cuando tengas evidencia de que el impacto ha terminado, no cuando una alternativa se limite a reducirlo.
- Fuera de horario: indica que la cobertura en directo no está disponible y señala el siguiente periodo de cobertura solo si es exacto para el canal o servicio, su calendario y su zona horaria aplicables.
- Retraso inesperado: explica el retraso sin culpar al cliente ni usar jerga técnica imprecisa; proporciona un punto de actualización o una vía alternativa.
- Interrupción del servicio: indica la función afectada, el impacto conocido para los clientes, una alternativa si está disponible y el compromiso para la siguiente actualización.
- Escala internamente cuando un mensaje operativo ya no coincida con la realidad, por ejemplo, ante una hora de actualización incumplida, una regla de asignación fallida o una cola prolongada.
Preguntas frecuentes
¿Cuánto debe durar un mensaje de espera para clientes?
Normalmente, entre una y tres frases cortas. Incluye el estado actual, la siguiente acción y solo una indicación de plazo que el servicio pueda respaldar. Añade una vía alternativa cuando el cliente pueda necesitar ayuda urgente o diferente.
¿Todos los mensajes de cola deben incluir un tiempo estimado de respuesta?
No. Usa un tiempo estimado solo cuando sea creíble para el canal, el equipo y el horario aplicables. Si se desconoce la duración, proporciona un punto específico para la próxima actualización o indica el evento que la desencadenará.
¿Qué debe decir un mensaje de transferencia?
Explica por qué es necesaria la transferencia, quién es responsable de la siguiente acción y qué información se ha transferido o si el equipo receptor tiene acceso al historial. Indica dónde aparecerá la siguiente respuesta. No pidas al cliente que repita información ya proporcionada salvo que sea necesaria y expliques qué dato falta.
¿Cuándo se debe ofrecer al cliente un escalado a una persona?
Ofrece o conserva una vía humana cuando la automatización no pueda gestionar la solicitud de forma segura, cuando el cliente esté bloqueado, cuando un error o retraso tenga consecuencias importantes, cuando los contactos repetidos demuestren que el problema sigue sin resolverse o cuando la política exija una revisión especializada. Deja clara la vía y la siguiente acción prevista.
¿Cómo pueden los equipos comprobar si estos mensajes funcionan?
Compara el texto de los mensajes con la asignación real, los horarios y los niveles de servicio antes del lanzamiento. Después, revisa los contactos repetidos, el abandono, las transferencias, los tiempos de primera respuesta y asignación, las valoraciones y los comentarios sobre las conversaciones. Examina muestras de estimaciones incumplidas, transferencias no aceptadas y escalados, y después revisa el mensaje o la operación que cause el desajuste.
¿Qué comprobaciones de accesibilidad se aplican a los mensajes de estado web?
Usa un lenguaje claro, asegúrate de que los mensajes tengan suficiente contexto cuando las tecnologías de asistencia los anuncien y prueba las actualizaciones dinámicas sin movimientos de foco no deseados. En interfaces web, role=status puede comunicar actualizaciones de estado de forma no intrusiva a las tecnologías de asistencia. Mantén los mecanismos repetidos de contacto humano, autoayuda y contacto automatizado en un orden relativo coherente donde aparezcan en las distintas páginas. WCAG 2.2 exige que el idioma humano predeterminado de cada página sea programáticamente determinable y, en el nivel AA, que también lo sea el idioma de los pasajes o frases en otro idioma.
Fuentes y lecturas adicionales
Referencias primarias y autorizadas usadas para verificar la base factual de esta guía.
- ISO 10002:2018 — Quality management: Customer satisfaction: Guidelines for complaints handling in organizations — International Organization for Standardization
- Lifecycle of an incident — Google Cloud Documentation
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative
- ARIA22: Using role=status to present status messages — W3C Web Accessibility Initiative
- Set up and manage user support — GOV.UK Service Manual
- Error message — GOV.UK Design System
- About open vs. pending and on-hold tickets — Zendesk Help
- Setting your schedule with business hours and holidays — Zendesk Help
- Analyzing your messaging tickets — Zendesk Help