Un correo de notificación de incidencias puede ser totalmente riguroso al redactarse y resultar engañoso en el momento del envío. Un «estamos investigando» puede haber quedado desfasado; un «resuelto» puede prometer más de lo que el responsable técnico está dispuesto a confirmar. La verificación final de los datos es tan determinante como el primer borrador.
Con Migma puedes estructurar una comunicación de servicio clara a partir de información validada, para que después los responsables de la incidencia y de Loops revisen el estado operativo y el flujo de envío. Esta guía, publicada por Migma, plantea ejercicios prácticos de redacción y pautas para el traspaso editorial; no determina qué mensajes de servicio deben enviarse a cada destinatario concreto.
Empieza por el comunicado del responsable de la incidencia
Solicita al equipo operativo el servicio afectado, el impacto confirmado en los usuarios, el estado actual, la hora de observación, la previsión de la próxima actualización y el enlace a la página de estado pública. Deja fuera del briefing creativo cualquier causa no confirmada o estimación de resolución sin validar.
En la guía de buenas prácticas para correos transaccionales de Loops se aborda la gestión de avisos sobre el estado del servicio y la importancia de transmitir información crítica con claridad. Con todo, el responsable operativo debe clasificar el mensaje real y definir la audiencia y el canal adecuados: una notificación de servicio, un análisis post mórtem posterior y un anuncio de producto cumplen funciones muy distintas.
No deduzcas el alcance a partir de un titular genérico como «la plataforma está caída». Si solo se ha confirmado la afectación de una función o región concreta, el correo debe ceñirse con precisión a ese límite. Una frase más corta no aporta valor si distorsiona quién se ve realmente afectado.
Diferencia con claridad los tres estados del borrador
Tomemos como ejemplo una aplicación ficticia de informes con retrasos en la exportación. Los textos siguientes son ejercicios de redacción hipotéticos: sustituye sus datos únicamente por información validada para la incidencia en curso y revisa la frase completa tras hacer el cambio.
En investigación
«La exportación de algunos informes está tardando más de lo habitual. Nuestro equipo está investigando el retraso. Los informes guardados siguen disponibles. Publicaremos la próxima actualización en la página de estado».
Utiliza este enfoque solo si se han verificado el alcance, la disponibilidad de los informes guardados y el canal de actualización. Si no se tiene certeza sobre el acceso a los datos, elimina esa afirmación. No añadas un plazo estimado de resolución simplemente para que el mensaje parezca más cerrado.
En monitorización
«Hemos aplicado una corrección para solucionar el retraso en la exportación de informes. Estamos supervisando la recuperación del servicio y actualizaremos la página de estado conforme confirmemos los resultados».
Esta redacción refleja un cambio en fase de evaluación; no debe acompañarse de un asunto que dé por resuelto el problema. Confirma qué corrige exactamente la intervención y si las nuevas exportaciones responden igual que las que quedaron en cola.
Resuelto
«Se ha resuelto la incidencia con la exportación de informes. En la página de estado encontrarás los detalles sobre el periodo afectado y las acciones necesarias para los usuarios».
Recurre a este texto únicamente cuando el responsable confirme el estado resuelto y la explicación vinculada esté publicada. Si algunos usuarios aún deben reintentar la acción o dar algún paso adicional, indícalo de forma explícita en lugar de dar a entender que no queda nada pendiente.
Diseña en Migma para facilitar una lectura rápida
Facilita a Migma la declaración de estado validada, la duda prioritaria del usuario y el enlace único a la información actualizada. Solicita un diseño sobrio, con tipografía legible y una jerarquía visual nítida. Prescinde de recursos gráficos festivos, banners promocionales o anuncios de producto que distraigan de la información de servicio.
La guía de introducción de Migma detalla cómo preparar el contenido de un correo antes de pasar a revisión. Examina el resultado con atención: una reformulación bienintencionada puede transformar por error un impacto parcial en una afirmación categórica, o convertir una estimación en un compromiso.
Mantén los datos críticos en texto real, nunca dentro de imágenes. Si incluyes una marca de tiempo, especifica la zona horaria correspondiente. Revisa el asunto, el preencabezado, el titular, el cuerpo y el botón como un conjunto indivisible: todos los elementos deben reflejar exactamente el mismo estado validado.
Verifica los datos justo antes del envío
Designa a una persona encargada de validar la redacción del estado operativo y a otra responsable del envío final. Si ambos roles recaen en el mismo perfil, diferencia ambos pasos de forma explícita. Quien revise debe contar con un registro de datos actualizado al minuto, no solo con una captura del borrador previo.
Si la situación cambia tras la aprobación, detén el mensaje en cola y evalúa si sigue teniendo sentido enviarlo. No ajustes sobre la marcha la primera línea sin revisar el asunto o las llamadas a la acción previas. Una notificación de «en investigación» programada puede requerir su sustitución por otra versión aprobada mediante el procedimiento establecido por el responsable.
Migma permite exportar HTML ya revisado, mientras que el responsable de Loops comprueba la compatibilidad técnica y las variables definitivas. No se asume una integración nativa directa. Comprueba la visualización final del mensaje renderizado y valida el enlace a la página de estado antes de que el responsable autorice el lanzamiento.
Comprueba la visualización sin lanzar un envío real
Ejecuta Email Preflight para resolver incidencias de redacción, enlaces, maquetación o previsualización en clientes de correo. Estas comprobaciones no validan la veracidad operativa ni garantizan la entregabilidad. Apóyate en el entorno de pruebas controlado de tu equipo de envíos y mantén las notificaciones a usuarios reales totalmente al margen de las revisiones de diseño.
Presta atención a nombres de servicio extensos, pantallas móviles estrechas, datos secundarios que puedan faltar y la URL completa de la página de estado. El botón debe dirigir a información que respalde lo afirmado en el correo, no a una página de inicio genérica ni al informe de una incidencia anterior.
Registra la redacción validada, la hora de observación, la persona responsable de la revisión, la segmentación elegida y el identificador del mensaje final. Cuando la incidencia quede cerrada, conserva el histórico para documentar qué se comunicó a los usuarios en cada fase. Diseña la creatividad en Migma y asegúrate de que sean los hechos operativos reales los que dicten el mensaje final.
Preguntas frecuentes
¿Es lo mismo «en monitorización» que «resuelto»?
No. La monitorización describe la fase de comprobación tras aplicar una medida correctiva. Utiliza el término «resuelto» únicamente cuando el responsable de la incidencia haya confirmado ese estado y no queden dudas sobre las acciones pendientes para el usuario.
¿Debe incluirse una estimación de resolución en el correo de incidencia?
Inclúyela solo si el responsable operativo la ha aprobado explícitamente y la redacción deja claro su carácter orientativo. Nunca inventes un plazo límite para dar la sensación de que el mensaje está completo.
¿Puede una comprobación con Preflight confirmar si una caída está resuelta?
No. Preflight analiza la maquetación, los enlaces, el contenido y los posibles riesgos en la bandeja de entrada. La verificación de los datos técnicos y del estado del servicio corresponde exclusivamente al responsable de la incidencia.
¿Qué ocurre si el estado de la incidencia cambia tras aprobar el correo?
Pausa el envío pendiente y revisa de forma conjunta el asunto, el preencabezado, el cuerpo, la llamada a la acción, la audiencia y los tiempos. El responsable debe determinar si el aviso sigue siendo útil o si debe sustituirse por otra versión aprobada.