Customer Support · Intermediate
Outage or Incident Notice
Tell everyone what broke while it is still broken
When to use it
The first status update during an outage, and every update after it. Use it for a status page, an in-app banner or an email to affected customers while the cause is still unknown.
Write a status update for an ongoing incident. What is broken: {{issue}} Who is affected: {{audience}} What we know so far: {{context}} Next update: {{deadline}} Structure: 1. What is not working, in plain terms 2. Who it affects and what they should do meanwhile 3. What we know and what we do not 4. When the next update comes — a time, always Rules: - Publish before you have the cause. Uncertainty stated is better than silence. - No "degraded performance" when it means "down" - No blame, no vendor names, no speculation about cause - Under 120 words
Try it: fill the variables
Example
Inputs
- {{issue}} The problem in one line
- Online appointment booking is down; the booking page shows an error after choosing a time.
- {{audience}} Who will read this
- Practice staff using the booking system, mostly non-technical.
- {{context}} Background the model needs
- Started 09:12. Existing appointments and the calendar view work. The cause is not yet known; the team is investigating.
- {{deadline}} Relevant date or timeframe
- 10:30
Output
Online booking is down. Patients get an error after choosing a time and cannot complete a booking. This affects every practice using online booking. Your calendar and all existing appointments work normally. Until it's fixed, please take bookings by phone and enter them in the calendar as usual. What we know: the problem started at 09:12 and only affects new online bookings. What we don't know yet: the cause. Next update by 10:30, even if nothing has changed.
Why it works
Publishing before the cause is known is the rule most teams break; the prompt makes stated uncertainty the expected format. Banning 'degraded performance' for an outage keeps the update honest, and a fixed time for the next update is what readers check first.
More from this pack
- Reply to a TicketA straight answer to a support message, no service-desk theatre
- Say No Without Losing the CustomerRefuse a request clearly and offer the nearest real thing
- Apology for a Real FailureOwn a mistake without corporate fog
- Bug Report From a Vague TicketTurn a frustrated message into something engineering can act on
From the Global Prompt Library (TextDeck Community License 1.0), version 53723a8. GitHub
Three keys. Every prompt.
Copied to clipboard