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
Top comments (2)
복구 시각 대신 다음 업데이트 시각을 약속하고, 변화가 없어도 정시에 알린다는 구분이 특히 중요하네요. 공지 템플릿에 다음 업데이트 담당자와 대체 담당자도 내부 필드로 두면, 장애 대응 중 담당자가 바뀌어도 고객 안내가 끊기지 않을 것 같습니다.
좋은 제안 감사합니다. 업데이트 시각은 지키기 쉬운데, 교대 중에 담당자가 흐려지면 다음 안내가 조용히 빠지곤 합니다. 다음 업데이트 시각 옆 내부 헤더에 담당자와 대체 담당자를 같이 적어 두면, 인계받은 사람이 바로 자기 몫이라는 걸 알 수 있겠네요.