Home / Guides / Escalations and support operations

Incident communication templates for customers: first notice to all clear

By Draft First. Updated October 2026

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 hours.

Rules for every message

• Describe what customers see, not what broke inside. "Reports won't load" beats an internal service name.
• 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.
• No credits unless someone with authority has approved them.
• One source of truth. Your status page, email and the account team should say the same thing at the same time.
• Write the time zone on every time you mention.

1. 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]

2. Ongoing update

Send it on time even when nothing has changed. Silence reads as "they've forgotten 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]

3. 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].

4. 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.
[If you'll share a summary: "We'll send a short summary of what
happened by [day]."]
We're sorry for the disruption.

Only promise a summary if someone owns writing it. When you do, the root cause summary template has a customer version.

5. Note to a key account

For accounts where the impact is bigger than average, the CSM or support lead should add a personal note on top of the general update.

Hi [first name],

I know [what they told you it affects, like "your month-end close
starts Friday"], so I wanted to reach out directly about [what
customers see].
Here's where it stands: [status, in one sentence].
I'll update you personally by [time and time zone].
If it's affecting something time-sensitive on your side, tell me and
I'll make sure the team knows.

[your name]

What 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 if true, it reads as blame.
• Internal names, ticket numbers from other systems, or quotes from internal chat.

Let AI draft the update, from the facts only

An AI agent can turn a fast-moving internal thread into a clean customer update, which saves real time when you're juggling the incident. Give it strict limits.

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.

Leadership needs a different page, with impact, owner and what you need from them. That's an escalation brief, and the escalation email templates cover the single-customer version.

Questions

How often should we update customers during an incident?

Pick a time for the next update and keep it, even if there's nothing new. Saying when they'll hear from you next matters more than how often.

Should we give an estimated fix time?

Only when the people fixing it have committed to one. Otherwise promise the next update time instead. A missed fix time costs more trust than no fix time.

Should we explain the cause during the incident?

Not until it's confirmed. Say what customers are seeing and what you're doing. Theories change, and a wrong one has to be taken back in public.

Who should write the updates?

One owner, from one source of truth. Support and CS can adapt the wording for key accounts, but the facts and times should match everywhere.