با این Prompt هوش مصنوعی یادداشتهای آشفته outage را به یک بهروزرسانی برای ذینفعان تبدیل کنید
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.
بیشتر شکستهای ارتباطی در incidentها به یک دلیل ساده رخ میدهد: تیم فنی هنوز در حال کشف واقعیتهاست، در حالی که بقیه فوراً یک پاسخ شفاف میخواهند. دقیقاً در همین لحظه است که wording بد وارد میشود. بهروزرسانیها بیش از حد مبهم، بیش از حد مطمئن، یا بیش از حد فنی میشوند، و هر نسخه از خود outage هم سردرگمی بیشتری ایجاد میکند.
این Prompt دقیقاً برای همان لحظه طراحی شده است. به مدل میگوید مثل یک incident communications lead عمل کند، نه یک دستیار نوشتاری عمومی. بهجای اینکه آشفتگی را به متن شرکتیِ بیخاصیت تبدیل کند، factهای تأییدشده را از پرسشهای باز جدا میکند، timeline را تا جای ممکن مرتب میکند، و سه نسخه متفاوت از یک پیام را برای executiveها، customerها، و internal teams میسازد.
ساختار همان چیزی است که آن را مؤثر میکند. بخش Role استاندارد ارتباطی آرام و قابل اتکا را تعیین میکند. بخش Context روشن میکند که منبع اطلاعات ناقص و آشفته خواهد بود. بخش Task مدل را وادار میکند factها را استخراج کرده و برای چند audience بازنویسی کند. Constraints حتی مهمتر هستند: آنها صریحاً مدل را از ساختن root cause، قول دادن درباره recovery time، یا استفاده از reassurance جعلی منع میکنند. همین باعث میشود Prompt در عملیات واقعی کاربردی باشد، نه فقط در نگاه اول چشمگیر.
نمونه output نشان میدهد چرا این موضوع مهم است. فقط به یک پاراگراف polished ختم نمیشود. یک خلاصه factها، فهرست unknownها، نسخه executive-ready، نسخه customer-safe، بهروزرسانی داخلی، و حتی بخشی درباره wordingهایی که نباید ارسال شوند تولید میکند. این بخش آخر بهویژه مفید است، چون بسیاری از تیمها در تشخیص فنی شکست نمیخورند. آنها با فرستادن جملهای شکست میخورند که الان مطمئن به نظر میرسد اما یک ساعت بعد بیاحتیاط جلوه میکند.
این Prompt برای incident managerها، تیمهای SRE، پاسخدهندگان security، رهبران support، و founderهایی مفید است که ناگهان باید برای افرادی بیرون از کانال engineering توضیح بدهند. همچنین بهاندازه کافی منعطف هست که برای outageها، degraded performance، failureهای authentication، و حتی بعضی incidentهای مربوط به data handling کار کند، به شرطی که operator یادداشتهای منظم ارائه دهد.
اگر تیم شما تا به حال وقت از دست داده چون مجبور بوده یک incident update یکسان را سه بار برای سه audience بازنویسی کند، این مورد ارزش ذخیره کردن دارد. کمک میکند سریعتر ارتباط برقرار کنید، بدون اینکه قطعیتی را وانمود کنید که واقعاً وجود ندارد، و این یکی از سختترین توازنها در طول یک incident زنده است.