Nutze diesen KI-Prompt, um chaotische outage-Notizen in ein Stakeholder-Update zu verwandeln
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.
Die meisten Kommunikationsprobleme während eines incident entstehen aus einem einfachen Grund: Das technische Team klärt die Fakten noch, während alle anderen sofort eine klare Antwort wollen. Genau in diesem Moment schleichen sich schlechte Formulierungen ein. Updates werden zu vage, zu selbstsicher oder zu technisch, und jede Version stiftet mehr Verwirrung als die outage selbst.
Dieser Prompt ist genau für diesen Moment gemacht. Er weist das Modell an, wie ein incident communications lead zu handeln und nicht wie ein allgemeiner Schreibassistent. Statt Chaos in leeres Corporate-Wording zu verwandeln, trennt er bestätigte Fakten von offenen Fragen, ordnet die Timeline soweit möglich und erstellt drei unterschiedliche Versionen derselben Nachricht für executives, customers und internal teams.
Die Struktur ist der Grund, warum das funktioniert. Der Abschnitt Role setzt den Standard für ruhige, glaubwürdige Kommunikation. Der Context macht klar, dass das Ausgangsmaterial unvollständig und unordentlich sein wird. Die Task zwingt das Modell, Fakten zu extrahieren und sie für mehrere audiences neu zu formulieren. Noch wichtiger sind die Constraints: Sie verhindern ausdrücklich, dass das Modell eine root cause erfindet, recovery-Zeiten verspricht oder falsche Beruhigung verwendet. Genau das macht den Prompt für echte Operations-Arbeit praktikabel und nicht nur beim ersten Lesen beeindruckend.
Das Beispiel-Output zeigt, warum das wichtig ist. Es bleibt nicht bei einem polished Absatz. Es liefert eine Faktenzusammenfassung, eine Liste von unknowns, eine executive-ready Version, eine customer-safe Version, ein internes Update und sogar einen Abschnitt mit Formulierungsrisiken, die man nicht versenden sollte. Gerade dieser letzte Teil ist besonders nützlich, weil viele Teams nicht an der technischen Diagnose scheitern. Sie scheitern daran, einen Satz zu verschicken, der jetzt souverän klingt und eine Stunde später leichtsinnig wirkt.
Dieser Prompt ist nützlich für Incident Manager, SRE-Teams, Security-Responder, Support-Leads und Gründer, die plötzlich Menschen außerhalb des Engineering-Kanals briefen müssen. Er ist außerdem flexibel genug für outages, degraded performance, authentication-Fehler und sogar einige incidents rund um Data-Handling, solange der Operator disziplinierte Notizen liefert.
Wenn dein Team schon einmal Zeit verloren hat, weil es dasselbe incident update dreimal für drei unterschiedliche audiences umschreiben musste, solltest du das speichern. Es hilft dir, schneller zu kommunizieren, ohne Sicherheit vorzutäuschen, die du nicht hast, und genau diese Balance ist während eines laufenden incident besonders schwer zu treffen.