During an incident, customers want three things: to know you know, to know what it means for them, and to know when they'll hear from you next.

Most bad incident emails fail on the third. They promise a fix time nobody committed to, or they go quiet for three hours while everyone's heads-down.

Rules for every message

  • Describe what customers see, not what broke inside. "Reports won't load" beats the name of the service that fell over.
  • Promise the next update time, not a fix time, unless the people fixing it have committed to one.
  • No theories about the cause until someone has confirmed it. Theories change, and a wrong one has to be taken back in public.
  • No credits unless someone with authority approved them.
  • One source of truth. Status page, email and account team say the same thing at the same time.
  • Time zone on every time.

First notice 

Subject: We're looking into [what customers see] We're aware that [what customers see, like "some reports won't load"] since about [time and time zone]. Our team is working on it now. We'll send the next update by [time and time zone], or sooner if anything changes. [Status page link, if you have one]

Ongoing update

Send it on time even when nothing changed. Silence reads as "they forgot about us".

Subject: Update: [what customers see] Where things stand: [Investigating / Fix in progress / Monitoring] What you may notice: [current impact, and what's changed since the last update] What we're doing: [one plain sentence] Next update by: [time and time zone]

Workaround available 

Subject: A workaround for [what customers see] While we work on a fix, you can [workaround in one or two short steps]. This avoids [the problem] for now. We're still working on the fix and will update you by [time and time zone].

All clear 

Subject: Resolved: [what customers see] [What customers saw] is working normally again as of [time and time zone]. It began at about [time]. If you still see a problem, reply to this email and we'll look at your account directly. We're sorry for the disruption.

Only promise a written summary afterwards if someone actually owns writing it.

Things never to say mid-incident

  • "This only affects a small number of customers." It doesn't feel small to them, and you may not know the number yet.
  • "It should be fixed in an hour." Unless someone committed to it.
  • "A third-party provider caused this." Even when true, it reads as blame.
  • Internal service names, or anything quoted from the internal channel.

Let an LLM draft the update, from the facts only

When you're running the incident, turning a fast-moving internal thread into a clean customer update is exactly the kind of work to hand off. The trick is strict limits, because a model will happily turn "Leo thinks it might be the config change" into "this was caused by a configuration change".

Using only the facts in [the incident thread or brief], draft a short update to customers. Include: what customers are seeing, what we're doing now, and when they'll hear from us next ([next update time and time zone]). Don't share internal names, theories about the cause, or anything marked Hypothesis or [CONFIRM]. Never promise a fix, a date or a credit. Under 120 words. This is a draft for me to edit and send.

A person reads it and sends it. Every time.

Full guide, including a personal note for key accounts and FAQs on update cadence and fix times: Incident communication templates for customers.

Want the full Escalation Brief routine, with its customer update follow-up and a sample result? Get the free play at https://draftfirstcs.com/free