Customer Incident Notice

Impact and recovery first, cause second

Write a customer notice from the incident details below. Structure: 1) when it happened, which functions were affected, and who was hit; 2) whether service is restored and what you did; 3) confirmed causes only — mark anything still under investigation as such; 4) the fixes you will ship in the next 72 hours and who owns each; 5) compensation and the next update time. No blame-shifting and no vague phrases like “a small number of users” or “system fluctuation”. Keep it under 400 words.

[Timeline]
[Impact]
[Confirmed cause]

How to use

Customers want to know “can I use it now, and is my data safe” before they want a cause. Impact can be precise; the root cause can wait for the next update.

Good for

Two hours after a P0 is restored, customer success is pushing for an external statement and sales is already fielding questions in the customer channel.
The incident hit only some customers but touched billing or data, so you need to tell them before they discover it themselves.

Not for

The cause is still unknown and impact is still growing — publishing a root cause now means retracting it later; send known facts and the next update time.
It involves a security attack or an active investigation — legal and security must approve the wording; business should not write it alone.

Example

Input

Timeline: 14:02 some customers cannot log in; 14:18 traced to an expired certificate; 14:35 restored. Impact: about 12% of enterprise customers, login and API auth failing; retries during the window may have double-billed. Confirmed cause: the certificate rotation script missed one domain.

What you get

Open with the window — 14:02 to 14:35, login and API auth failing for about 12% of enterprise customers, now restored. Keep the cause to what is confirmed, a rotation script that missed one domain, with no internal blame, and say that retries may have double-billed, which you will reconcile and refund within three business days. Close with the 72-hour actions — complete the domain list, add expiry alerts, run a drill, all owned by the infrastructure lead — and the next update time.

Common mistakes

Sending the internal postmortem to the customer — lines like “an engineer misconfigured” and “monitoring gap” become claim and PR material.
Apologizing repeatedly to sound sincere but omitting impact and compensation — the customer still cannot tell whether their data is safe.

Try tweaking it like this

Add “one version for affected customers and one for everyone else”; the unaffected get a short note and no unnecessary alarm.
Add “a three-sentence version we can post in the customer channel”, with the long notice going by email.