Utilisez ce Prompt IA pour transformer des notes d’outage désordonnées en mise à jour pour les parties prenantes
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 plupart des échecs de communication pendant un incident ont une cause simple : l’équipe technique est encore en train d’établir les faits pendant que tout le monde veut immédiatement une réponse claire. C’est précisément à ce moment-là que les mauvaises formulations apparaissent. Les mises à jour deviennent trop vagues, trop confiantes ou trop techniques, et chaque version crée plus de confusion que l’outage elle-même.
Ce Prompt est conçu exactement pour ce moment. Il indique au modèle d’agir comme un incident communications lead, et non comme un assistant de rédaction générique. Au lieu de lisser le chaos en le transformant en texte corporate vide, il sépare les faits confirmés des questions ouvertes, remet le timeline en ordre quand c’est possible et produit trois versions différentes du même message pour les executive, les customer et les internal teams.
Sa structure est ce qui le rend efficace. La section Role fixe le niveau attendu d’une communication calme et crédible. Le Context précise clairement que le matériau source sera incomplet et désordonné. La Task oblige le modèle à extraire les faits puis à les reformuler pour plusieurs audiences. Les Constraints comptent encore davantage : elles empêchent explicitement le modèle d’inventer un root cause, de promettre des délais de recovery ou d’utiliser une fausse réassurance. C’est ce qui rend ce Prompt réellement utile en operations, et pas seulement impressionnant à la première lecture.
L’exemple d’output montre bien pourquoi c’est important. Il ne s’arrête pas à un paragraphe polished. Il produit un résumé des faits, une liste d’unknowns, une version executive-ready, une version customer-safe, une mise à jour interne, et même une section consacrée aux formulations risquées à éviter. Cette dernière partie est particulièrement utile, car beaucoup d’équipes ne se trompent pas sur le diagnostic technique. Elles se trompent en envoyant une phrase qui semble sûre maintenant et paraîtra imprudente une heure plus tard.
Ce Prompt est utile pour les incident managers, les équipes SRE, les responders security, les responsables support et les founders qui doivent soudain informer des personnes en dehors du canal engineering. Il est aussi suffisamment souple pour fonctionner lors d’outages, de degraded performance, d’échecs d’authentication et même de certains incidents liés au traitement des data, à condition que l’opérateur fournisse des notes rigoureuses.
Si votre équipe a déjà perdu du temps à réécrire trois fois la même incident update pour trois audiences différentes, cela mérite d’être conservé. Ce Prompt vous aide à communiquer plus vite sans prétendre à une certitude que vous n’avez pas, et c’est l’un des équilibres les plus difficiles à tenir pendant un incident en cours.