Usa este Prompt de IA para convertir notas caóticas de un outage en una actualización para stakeholders
Why this prompt matters
Bad incident communication creates secondary damage. It confuses support teams, frustrates customers, spooks executives, and can lock a company into statements that turn out to be wrong an hour later. A good Prompt helps teams communicate quickly without overstating certainty, which reduces noise while the technical team is still trying to fix the real problem.
What we use it for
Your engineering team is in the middle of an outage, the incident channel is full of partial updates, and leadership wants a clean status message in the next ten minutes. You need something more reliable than copying Slack fragments into an email, especially when customer-facing teams and executives need different levels of detail from the same underlying facts.
Prompt
Role: Act as a senior incident communications lead who writes calm, accurate, executive-ready updates during outages and security incidents. Context: I need to turn messy incident notes, internal Slack fragments, engineering findings, and partial timelines into a stakeholder update that is credible, clear, and safe to send. The audience may include executives, customer-facing teams, internal staff, or affected clients. The goal is not to dramatize the incident or over-reassure. The goal is to explain what happened, what is being done, what is still unknown, and what the next update cadence will be. Task: Review the raw incident notes I provide. Extract the facts, identify what is confirmed versus still under investigation, and write a stakeholder update that is concise, calm, and operationally useful. If the notes are messy or contradictory, resolve the timeline as best you can and clearly label remaining uncertainty. Then produce an executive-ready version, a customer-safe version, and a short internal version for cross-functional teams. Constraints: - Do not invent root cause, customer impact, or recovery times that are not supported by the notes. - Separate confirmed facts from assumptions and open questions. - Avoid engineering jargon unless it is necessary for accuracy, and explain it briefly if used. - Do not sound defensive, legalistic, or overly polished. - Never use empty reassurance like "everything is under control" unless the evidence clearly supports it. - Preserve important operational terms such as API, database, failover, rollback, latency, authentication, region, and SLA when relevant. - If the notes suggest a serious issue but key facts are missing, write the safest credible version instead of guessing. Output Format: 1. Situation summary in 2 to 4 bullet points 2. Confirmed facts 3. Unknowns and active investigation items 4. Executive-ready stakeholder update 5. Customer-safe update 6. Internal cross-functional update 7. Recommended next-update timing 8. Red flags or wording risks to avoid sending Inputs: - Incident type: [OUTAGE / SECURITY INCIDENT / DEGRADED PERFORMANCE / DATA ISSUE] - Audience: [EXECUTIVES / CUSTOMERS / INTERNAL TEAMS / MIXED] - Raw notes: [PASTE NOTES, TIMELINE, LOG EXCERPTS, SLACK MESSAGES] - Known impact: [WHAT USERS OR SYSTEMS ARE AFFECTED] - What has been done already: [MITIGATION STEPS] - What is still unclear: [OPEN QUESTIONS] - Desired tone: [DIRECT / REASSURING / FORMAL / NEUTRAL] - Next update target: [TIME OR CADENCE]
Result
1. Situation summary - Users in the EU region began seeing elevated login failures at approximately 08:42 UTC after a configuration change affecting the authentication service. - The issue appears limited to sign-in and token refresh flows; core data storage and billing systems remain operational. - The incident response team has already rolled back the suspected change and is monitoring recovery, but full root cause validation is still in progress. - A broader customer impact estimate is not yet confirmed, so external messaging should stay precise and avoid user-count claims for now.
2. Confirmed facts Authentication error rates rose sharply in the EU production region shortly after a planned infrastructure change. Engineering has linked the timing to a configuration update in the identity stack, though root cause is still being validated. The team initiated rollback at 08:57 UTC and saw partial recovery within twelve minutes. Internal monitoring shows login success rates improving, but some sessions are still failing during token refresh. No evidence currently suggests a database breach, payment disruption, or data loss.
3. Unknowns and active investigation items The team is still confirming whether the failed refresh behavior is residual cache impact or a second misconfiguration. It is also not yet clear whether a subset of non-EU users routed through the same service path experienced intermittent failures. Support ticket sampling is underway, but a precise count of affected customers is not yet available.
4. Executive-ready stakeholder update We are investigating an authentication incident that began at approximately 08:42 UTC and primarily affected login flows in the EU region. The current working theory is that the incident was triggered by a configuration change to the identity service. The suspected change has been rolled back, and platform metrics are improving, though recovery is not yet complete. At this stage we have no evidence of data loss or broader platform instability outside authentication-related flows. We will provide the next update in 30 minutes or sooner if the impact assessment changes materially.
5. Customer-safe update We are currently investigating an issue affecting sign-in for some users and have already taken mitigation steps to restore normal service. System performance is improving, but some customers may still experience intermittent login or session refresh problems while recovery continues. We do not currently have evidence of data loss related to this incident. Our next update will be shared within 30 minutes.
6. Internal cross-functional update Auth incident remains active but trending in the right direction after rollback. Please avoid quoting customer counts or naming root cause as confirmed until engineering closes validation. Support should tell customers we are seeing improving recovery in login flows, with no current evidence of data loss. Comms and account teams should use the customer-safe update only, not raw incident channel notes.
7. Recommended next-update timing 30 minutes, unless recovery stalls or impact widens.
8. Red flags or wording risks to avoid sending Do not say the issue is fully resolved yet. Do not describe the configuration change as the confirmed root cause. Do not claim that only EU users were affected until routing checks are complete. Do not promise a final ETA for full recovery.
La mayoría de los problemas de comunicación durante un incident se producen por una razón simple: el equipo técnico todavía está descubriendo los hechos mientras todos los demás quieren una respuesta clara de inmediato. Justo ahí es cuando aparece una mala redacción. Las actualizaciones se vuelven demasiado vagas, demasiado confiadas o demasiado técnicas, y cada versión genera más confusión que el propio outage.
Este Prompt está diseñado exactamente para ese momento. Le indica al modelo que actúe como un incident communications lead, no como un asistente de redacción genérico. En lugar de pulir el caos y convertirlo en relleno corporativo, separa los hechos confirmados de las preguntas abiertas, ordena el timeline cuando es posible y produce tres versiones diferentes del mismo mensaje para executives, customers e internal teams.
La estructura es lo que hace que funcione. La sección Role establece el estándar de una comunicación calmada y creíble. El Context deja claro que el material de origen será incompleto y desordenado. La Task obliga al modelo a extraer hechos y reescribirlos para varias audiences. Las Constraints importan aún más: bloquean explícitamente que el modelo invente un root cause, prometa tiempos de recovery o use tranquilidad falsa. Eso es lo que vuelve a este Prompt práctico para operaciones reales y no solo impresionante en una primera lectura.
El ejemplo de output muestra por qué esto importa. No se detiene en un párrafo polished. Produce un resumen de hechos, una lista de unknowns, una versión executive-ready, una versión customer-safe, una actualización interna e incluso una sección sobre riesgos de redacción que conviene evitar. Esa última parte es especialmente útil porque muchos equipos no fallan en el diagnóstico técnico. Fallan al enviar una frase que hoy suena segura y dentro de una hora parece imprudente.
Este Prompt es útil para incident managers, equipos de SRE, responsables de security, líderes de support y founders que de repente tienen que informar a personas fuera del canal de engineering. También es lo bastante flexible como para servir en outages, degraded performance, fallos de authentication e incluso algunos incident relacionados con el manejo de data, siempre que quien lo use aporte notas disciplinadas.
Si tu equipo alguna vez ha perdido tiempo reescribiendo la misma incident update tres veces para tres audiences, vale la pena guardar esto. Te ayuda a comunicarte más rápido sin fingir una certeza que no tienes, y ese es uno de los equilibrios más difíciles de lograr durante un incident en curso.