Plantillas de mensajes de mantenimiento que tranquilizan a los usuarios durante downtime programado, interrupciones parciales y rendimiento degradado, reduciendo el pánico y los tickets de soporte.
La mayoría de las notas de mantenimiento fracasan por una razón simple: crean incertidumbre. Un banner que dice “Estamos en mantenimiento” sin detalles obliga a los usuarios a adivinar qué está fallando, cuánto durará y si su trabajo está a salvo. Adivinar se convierte en miedo, y el miedo en tickets de soporte.
La comunicación vaga también genera desconfianza. Si los usuarios ven errores pero tu mensaje suena tranquilo y genérico, asumen que estás ocultando el problema real. Ese hueco entre lo que experimentan y lo que dices es lo que rompe la confianza.
La gente suele necesitar tres cosas de inmediato: impacto claro, horario claro y pasos siguientes claros.
Impacto significa nombrar lo que está afectado (inicio de sesión, exportaciones, pagos), no solo decir “interrupción del servicio”. Horario significa una ventana específica y cuándo será la próxima actualización, no “en breve”. Pasos siguientes significa indicar qué hacer mientras esperan, como “vuelve a intentarlo en 20 minutos” o “usa la app móvil en su lugar”.
Prometer en exceso es la forma más rápida de empeorar las cosas. “No se espera impacto” es arriesgado a menos que estés realmente seguro. Cuando aunque un solo usuario se ve afectado, esa línea se convierte en prueba de que no estás prestando atención. Las actualizaciones honestas funcionan mejor: di lo que sabes, lo que todavía no sabes y exactamente cuándo volverás a informar.
El objetivo no es “maquillar” la historia. Es reducir la incertidumbre. Cuando la gente entiende qué pasa, qué significa para ellos y qué deben hacer ahora, dejan de actualizar la página, dejan de asumir lo peor y dejan de abrir tickets solo para recuperar el control.
Los usuarios se tranquilizan cuando nombras la situación con palabras sencillas. Si llamas todo “mantenimiento” o “problemas”, la gente asume lo peor y comienza a reintentar, actualizar y abrir tickets.
Comienza con la etiqueta correcta:
“Degradado” nunca debe ser vago. Di lo que el usuario notará. Por ejemplo: “Las exportaciones pueden tardar entre 10 y 20 minutos más de lo habitual” es más claro que “Se está experimentando rendimiento degradado”.
Sé específico sobre lo que está afectado, aunque la lista sea corta. Menciona las áreas que más importan: inicio de sesión, pagos y facturación, sincronización, notificaciones, paneles, exportaciones, acceso a la API y subidas de archivos.
Evita palabras alarmantes, pero no ocultes la verdad. Sustituye “fallo crítico” por “algunos usuarios no pueden iniciar sesión” y “inestabilidad del sistema” por “puedes ver timeouts al guardar”. Un tono calmado nace de la precisión, no del optimismo.
Si no estás seguro, elige la etiqueta que coincida con el impacto al usuario, no con la causa interna. “Mantenimiento de la base de datos” dice poco a la mayoría. “La página de facturación puede no estar disponible hasta 15 minutos” les dice qué esperar y qué hacer.
Los usuarios confían en lo que ven en el momento exacto en que están bloqueados. Las buenas plantillas de mensaje tienen menos que ver con frases ingeniosas y más con elegir la superficie adecuada.
Usa un banner dentro de la app para la mayoría de los trabajos planificados. Se mantiene visible mientras la gente continúa lo que puede y no secuestra la pantalla.
Usa un modal solo cuando el usuario no pueda continuar de forma segura (acciones de facturación, ediciones de datos, registros). Si usas un modal, permite cerrarlo y deja un banner persistente después.
Los toasts son útiles para actualizaciones breves y de bajo riesgo (por ejemplo, “Las exportaciones pueden ser más lentas durante 10 minutos”). Son fáciles de pasar por alto, así que no los uses para un downtime real.
Una regla simple:
Si los usuarios pueden verse imposibilitados de iniciar sesión, coloca el mismo mensaje en la pantalla de inicio de sesión. Ahí es donde comienza el pánico, porque los usuarios asumen que su cuenta está rota. Una nota simple como “El inicio de sesión puede fallar entre 02:00-02:30 UTC” reduce tickets rápidamente.
Usa tu página de estado para actualizaciones continuas e historial (qué cambió, qué sigue afectado, qué se arregló). Usa el aviso dentro de la app para decirle al usuario qué debe hacer ahora (esperar, intentar más tarde, evitar exportaciones, etc.). No escondas detalles críticos solo en la página de estado, porque muchos usuarios nunca la consultarán.
El correo y las notificaciones push ayudan cuando el impacto es alto y los usuarios necesitan planificar. De lo contrario, resultan molestos. Si las envías, mantén el contenido consistente con el copy in-app.
Finalmente, alinea al soporte con la misma redacción. Tu respuesta automática debe coincidir con el texto del banner y las actualizaciones de estado para que los usuarios no reciban mensajes contradictorios.
La gente confía en los avisos de mantenimiento cuando son específicos, honestos y útiles. Eso no significa largos. Significa responder las preguntas que tiene un usuario estresado en los primeros 10 segundos, con tiempos claros y un plan.
Un aviso fiable incluye cinco básicos:
El tiempo es donde los mensajes suelen perder confianza. Usa una ventana que la gente entienda, como “16 ene, 01:00 a 02:30 UTC”. Si tienes una audiencia global amplia, considera añadir una segunda referencia horaria que muchos compartan (por ejemplo, “08:00 a 09:30 hora de Singapur”). Evita precisión falsa como “de vuelta a las 02:17”. Un rango como “30 a 60 minutos” suena más honesto y reduce ciclos de actualización enfadados.
Si no sabes algo aún, di qué estás comprobando a continuación. Por ejemplo: “Estamos investigando una carga elevada en la base de datos y revisando deploys recientes y consultas lentas. Próxima actualización a las 14:30 UTC.” Esa única frase convierte el silencio en un plan.
Incluye siempre una hora para la próxima actualización, aunque sea cercana y aunque no cambie nada. “Próxima actualización en 20 minutos” calma a la gente porque fija una promesa que puedes cumplir.
Ejemplo de detalle que genera confianza: “Las exportaciones de archivos pueden tardar entre 10 y 30 minutos más de lo habitual. Mientras tanto, puedes ver los informes dentro de la app. Publicaremos otra actualización a las 16:10 UTC.”
Los buenos avisos de mantenimiento parecen calmados porque son específicos y consistentes. Trátalos como listas de verificación, no como anuncios.
Escribe el primer borrador con marcadores claros. Empieza con: qué está afectado, cuándo empieza, cuánto puede durar y quién se ve impactado. Deja corchetes para detalles que puedas confirmar después (hora exacta de fin, regiones afectadas, nombre de la función). Eso te permite publicar temprano sin adivinar.
Elige una etiqueta de severidad que coincida con la realidad. Usa una única etiqueta y mantenla en el banner, la página de estado y el correo. Por ejemplo: Mantenimiento (programado), Interrupción parcial (algunos usuarios o funciones), Rendimiento degradado (lento o con retrasos). Si usas colores, mantenlos consistentes (verde = normal, amarillo = degradado, rojo = interrupción) para que los usuarios escaneen rápido.
Añade una frase que explique la etiqueta en lenguaje llano. “Degradado” debe significar siempre algo concreto como “las exportaciones pueden tardar 5-15 minutos”.
Ofrece una solución temporal cuando sea posible. Incluso una alternativa pequeña reduce tickets. Ejemplo: “Si necesitas el informe ahora, usa la descarga CSV desde el panel mientras las exportaciones programadas están retrasadas.” Si no hay solución temporal, dilo claramente una vez.
Planifica tus actualizaciones antes de publicar. Programa dos recordatorios: uno poco antes de la ventana y otro “comenzando ahora” en el momento exacto de inicio. Si el horario cambia, actualiza el aviso primero y luego envía el recordatorio.
Cierra el ciclo con una actualización final. Di qué cambió, cuándo se restauró y qué deben hacer los usuarios si algo sigue raro (refrescar, reintentar o contactar soporte con un dato específico como una marca de tiempo o ID de trabajo).
Usa estas plantillas como punto de partida y ajusta los detalles para que encajen con lo que tus usuarios hacen en tu producto. Mantén el tono calmado y claro. Da una acción concreta que puedan hacer.
Asunto/Título: Mantenimiento programado el [Día], [Fecha] a las [Hora de inicio] [TZ]
Mensaje: Hemos programado mantenimiento el [Día, Fecha] de [Hora de inicio] a [Hora de fin] [TZ].
Durante esta ventana, [qué no estará disponible]. [qué seguirá funcionando] permanecerá disponible.
Si necesitas prepararte: por favor [acción recomendada, p. ej., terminar exportaciones, guardar borradores] antes de [hora]. Publicaremos actualizaciones aquí durante la ventana.
Título: Mantenimiento en curso
Mensaje: El mantenimiento ha comenzado y se espera que dure hasta [Hora de fin] [TZ].
Ahora mismo, [qué no está disponible]. Si intentas [tarea común], puede que veas [error/comportamiento esperado].
Próxima actualización a las [hora] (o antes si cambia algo).
Título: El mantenimiento está tardando más de lo previsto
Mensaje: El mantenimiento está tardando más de lo esperado. El nuevo fin estimado es [Nueva hora de fin] [TZ].
Qué significa esto para ti: [impacto en una frase]. Qué puedes hacer ahora: [solución segura o “por favor intenta de nuevo después de X”].
Disculpas por la interrupción: compartiremos otra actualización a las [hora].
Título: Mantenimiento completado
Mensaje: El mantenimiento se completó a las [hora] [TZ].
Ahora puedes [las 2–3 acciones clave para verificar, p. ej., iniciar sesión, ejecutar una exportación, realizar un pago]. Si algo sigue mal, prueba [paso simple como refrescar/reiniciar sesión] y luego contacta soporte con [qué información incluir, p. ej., hora, cuenta, captura de pantalla].
Título: Monitorización después del mantenimiento
Mensaje: Los sistemas están de vuelta en línea y los estamos monitoreando de cerca durante las próximas [X horas].
Podrías notar [síntoma menor, p. ej., carga más lenta, correos retrasados] mientras las colas se ponen al día. Si encuentras errores, vuelve a intentarlo después de [tiempo].
Próxima actualización a las [hora] (o antes si detectamos algo).
Cuando la app no está completamente caída, los banners vagos crean el mayor pánico. Sé específico sobre lo que está afectado (función, región o paso), qué sigue funcionando y qué deben hacer los usuarios ahora.
Úsala cuando la mayor parte del producto funciona, pero una área no.
Plantilla
Título: Interrupción parcial: [función/servicio] no disponible en [región/tipo de cuenta]
Cuerpo: Estamos viendo un problema donde [función] no funciona para [quién está afectado]. Otras partes de la app, incluyendo [qué sigue funcionando], están operando con normalidad. Nuestro equipo está trabajando en una solución.
Impacto: Puede que veas [mensaje de error/síntoma] cuando intentes [acción].
Solución temporal: Hasta que se arregle, por favor [acción alternativa segura].
Próxima actualización: Para las [hora + zona horaria] (o antes si se resuelve).
Úsalo cuando las peticiones tienen éxito pero se sienten rotas por la lentitud.
Plantilla
Título: Rendimiento degradado: [área] más lento de lo normal
Cuerpo: Algunas acciones están tardando más de lo habitual, especialmente [acciones específicas]. Podrías ver timeouts o reintentos, pero los datos no deberían perderse.
Qué hacer: Si recibes un error, espera [X minutos] y vuelve a intentarlo. Evita repetir la misma acción muchas veces (puede crear duplicados).
Próxima actualización: Para [hora + zona horaria].
Úsalo cuando la parte más difícil es la incertidumbre.
Plantilla
Título: Problema intermitente: [función] puede fallar o tener éxito de forma impredecible
Cuerpo: Estamos investigando un problema donde [función] funciona en algunos intentos pero falla en otros. Si falla, es seguro reintentar después de [X minutos].
Cómo ayudar: Si contactas soporte, incluye [ID de solicitud / rango de tiempo / región afectada].
Úsalo cuando los usuarios no pueden entrar. Mantén el tono calmado y directo.
Plantilla
Título: Problemas de inicio de sesión: algunos usuarios pueden no poder acceder
Cuerpo: Estamos viendo fallos elevados en el inicio de sesión para [quién está afectado]. Si estás bloqueado, por favor no restablezcas tu contraseña repetidamente a menos que veas un error claro de contraseña.
Qué intentar: Refresca una vez, espera [X minutos] y vuelve a intentarlo. Si usas SSO, indica si el problema es solo SSO o todos los métodos de inicio de sesión.
Úsalo cuando los usuarios piensan que faltan datos.
Plantilla
Título: Retraso de datos: [informes/sincronización/analíticas] puede retrasarse [X minutos/horas]
Cuerpo: La actividad nueva puede tardar más en aparecer en [área]. Tus datos siguen recogiendo, pero el procesamiento está retrasado.
Qué significa: Las exportaciones/informes creados en este periodo pueden estar incompletos. Si es posible, espera hasta [hora] para ejecutar informes críticos.
Próxima actualización: Para [hora + zona horaria].
La mayoría de los picos de soporte durante el mantenimiento no se deben al propio mantenimiento. Vienen de un wording que obliga a la gente a adivinar qué pasa, cómo les afecta y cuándo terminará. Si los usuarios tienen que adivinar, abren tickets.
Patrones que crean pánico rápido:
Un pequeño ejemplo: tu herramienta de exportación está lenta, pero el resto de la app funciona. Si tu banner dice “Interrupción del servicio”, usuarios que no exportan dejarán de trabajar y llenarán soporte. Si pones “Las exportaciones pueden tardar 10–20 minutos; paneles y edición funcionan con normalidad. Próxima actualización a las 14:30 UTC”, muchos simplemente esperarán.
Si construyes plantillas de mensajes, apunta a un lenguaje claro que responda tres preguntas rápido: ¿Qué está afectado?, ¿qué debo hacer ahora? y ¿cuándo me actualizarán de nuevo?
Antes de publicar, lee tu mensaje como si fueras un cliente preocupado. El objetivo es simple: reducir la incertidumbre.
Asegúrate de que la redacción coincida entre tu banner, correo, macros de help desk y cualquier mensaje de estado. Si uno dice “degradado” y otro “caído”, la gente asume que ocultas algo.
Mantén el tono calmado y factual. Evita exageraciones, bromas o frases como “sin preocupaciones”. Una línea simple y constante como “Estamos investigando exportaciones lentas” funciona mejor que intentar sonar jovial.
Haz la prueba de claridad: ¿puede un usuario nuevo repetir el problema en una frase sin añadir conjeturas? Si no, reescribe.
Cuando termine, ciérralo explícitamente: confirma que se resolvió, da la hora de resolución y di qué hacer después (por ejemplo, “Reintenta tu exportación” o “Si sigues viendo errores, refresca y vuelve a intentar”).
Un momento común de “todo está roto” es cuando falla una función y el resto de la app parece normal. Imagina una herramienta financiera: la página de facturación carga, las facturas se ven y los pagos se realizan. Pero las exportaciones CSV empiezan a hacer timeout para algunos usuarios. La gente actualiza, vuelve a intentar y abre tickets porque asumen que faltan datos.
El primer mensaje debe decir qué funciona, qué no, quién está afectado y qué hacer ahora. Por ejemplo:
“Exportar facturas a CSV está fallando por timeout en algunas cuentas. Las páginas de facturación y los pagos funcionan con normalidad. Si necesitas los datos con urgencia, usa los filtros en pantalla y copia los resultados, o prueba a exportar un rango de fechas más pequeño. Estamos investigando y actualizaremos aquí en 15 minutos.”
Durante la siguiente hora, las actualizaciones deben evolucionar de “lo vemos” a “esto es lo que cambiamos”:
El mensaje final cierra el ciclo. Incluye la corrección, el alcance y una ruta clara de soporte:
“Resuelto: aumentamos la capacidad de los workers de exportación y ajustamos timeouts. Entre 10:05–11:05 UTC, algunas exportaciones CSV fallaron, pero facturación y pagos permanecieron disponibles. Si aún no puedes exportar, responde a tu ticket con la hora de la exportación y el rango de facturas.”
Los equipos que se comunican así suelen ver menos tickets porque los usuarios aprenden tres cosas rápido: sus datos están seguros, qué intentar ahora y cuándo llegará la próxima actualización.
Trata la mensajería de mantenimiento como una pequeña característica de producto, no como una disculpa puntual. El objetivo es consistencia: los usuarios deben reconocer el patrón, saber qué hacer y confiar en que los actualizarán según lo prometido.
Convierte tu mejor copy en bloques reutilizables con variables claras y guárdalos en un solo lugar para que cualquiera del equipo pueda publicar un aviso sin reescribir desde cero. Estandariza básicos como hora de inicio, fin estimado, funciones afectadas, regiones y quién está impactado (todos los usuarios vs un subconjunto).
Escribe la responsabilidad y un flujo de aprobación simple. Una persona redacta, otra aprueba y otra publica, aunque en equipos pequeños dos de esos roles puedan coincidir. Fija un ritmo de actualizaciones por adelantado (por ejemplo, cada 30 minutos durante un incidente) para que soporte no tenga que adivinar cuándo llegará el próximo mensaje.
Ten cuidado con el lenguaje de “snapshots” y “rollback”. Solo promete lo que puedas cumplir bajo presión. Si el rollback es posible pero no garantizado, dilo con claridad y céntrate en lo que los usuarios pueden contar.
Si quieres hacer esto repetible dentro del producto, ayuda construir los puntos de entrega una vez y reutilizarlos: un componente de banner in-app, una página de estado ligera y un flujo de “todo claro” post-mantenimiento. Si tu equipo crea productos con Koder.ai (koder.ai), puedes crear estas piezas de UI y flujos de actualización mediante un proceso de construcción guiado por chat, luego ajustar el copy y las variables sin reconstruir toda la app.
Termina realizando un ensayo durante una ventana de mantenimiento de bajo riesgo. Usa plantillas reales, publícalas en las superficies reales, cronometra tus actualizaciones y revisa lo ocurrido:
Una vez tengas ese ciclo, tus plantillas dejarán de ser documentos y se convertirán en hábito.
Empieza con qué está afectado, cuánto durará y qué debe hacer el usuario ahora. Una línea clara como “Las exportaciones pueden tardar 10–20 minutos más; los paneles funcionan con normalidad; próxima actualización a las 14:30 UTC” evita conjeturas y reduce tickets.
Usa Mantenimiento para trabajo programado con una ventana definida, Interrupción parcial cuando una función o región específica está caída, y Rendimiento degradado cuando las funciones funcionan pero con lentitud o errores. Elige la etiqueta que coincida con lo que los usuarios sienten, no con la causa interna.
Escribe en una frase lo que el usuario notará y cuantifícalo si puedes. Por ejemplo: “Las exportaciones pueden tardar entre 10–30 minutos y pueden fallar en rangos grandes” en lugar de “Estamos experimentando rendimiento degradado”.
Usa un banner en la aplicación para la mayoría de los casos, de modo que las personas puedan seguir trabajando. Usa un modal solo cuando continuar pueda causar errores o pérdida de datos (acciones de facturación o ediciones críticas), y deja un banner persistente después para que el aviso no desaparezca.
Coloca el mismo mensaje en la pantalla de inicio de sesión siempre que la autenticación pueda fallar, porque ahí empieza el pánico. Si solo publicas actualizaciones dentro de la app, los usuarios bloqueados asumirán que su cuenta está rota y colapsarán soporte.
Evita certezas falsas como “Sin impacto esperado” a menos que estés completamente seguro. Di lo que sabes, lo que aún no sabes y cuándo actualizarás; esa honestidad se percibe como competencia, no como debilidad.
Incluye siempre un tiempo específico para la próxima actualización, incluso si no cambia nada. “Próxima actualización en 20 minutos” establece una promesa en la que los usuarios pueden confiar y reduce el ciclo de refrescar y abrir tickets.
Sugiere una acción segura y que reduzca riesgos o duplicados. Por ejemplo: “Reintentar una vez después de 2 minutos”, “No repitas la misma exportación”, o “Usa un rango de fechas más pequeño”. Si no hay solución alternativa, dilo claramente una vez.
Indica qué está afectado, qué sigue funcionando y qué hacer si están bloqueados. Pide que no realicen acciones de alto riesgo repetidamente (como restablecer la contraseña) a menos que el mensaje lo aconseje explícitamente.
Cierra con una nota explícita de “resuelto” que incluya la hora, qué se restauró y qué probar si algo sigue fallando (refrescar, volver a iniciar sesión, reintentar una vez). Si aún pueden verse casos aislados, indica que estás monitorizando y cuándo publicarás la confirmación final.
