Customer Comms

Communicate with customers during outages via a status page, email, and in-app banners with honesty and cadence.

Why

Customers don't expect perfection; they expect to be informed. A status page that says "all systems operational" while checkout is down destroys trust instantly, while a page that says "we're investigating elevated errors on checkout, next update in 30m" builds it — even though the outage is the same. The research is clear: customers rate an outage with good comms higher than a smaller outage with no comms. Good customer comms acknowledge fast (within 5m), update on a cadence (every 30m), are honest about impact ("some checkouts are failing" not "experiencing degraded performance"), and close with a postmortem link. This converts an outage from a trust-destroying event into a trust-building one, which is why mature teams invest in comms as much as in reliability.

When

For every customer-visible incident (SEV1, user-facing SEV2). The status page updates at declaration, not at resolution.

How

1. Acknowledge within 5m on the status page
   - "Investigating: elevated errors on checkout. Next update in 30m."
   - Don't wait for root cause to acknowledge — silence is the trust-killer

2. Update on a cadence, even if there's no new info
   - Every 30m: "Still investigating. Error rate 100%, rollback in progress."
   - A "no new info" update is better than silence — it proves we're still on it

3. Be honest about impact
   - "Some checkouts are failing" (honest) not "degraded performance" (euphemism)
   - Include scope: "affecting ~5% of checkout attempts in the EU region"
   - Customers respect honesty; euphemism reads as cover-up

4. Close with a postmortem commitment
   - "Resolved: checkout is operating normally. We'll publish a postmortem within 5 business days."
   - Then actually publish it — the postmortem is the trust-restoring artifact

5. Use the right channel per audience
   - Status page (status.example.com): all customers, all incidents
   - Email to affected customers: SEV1 with data impact (e.g., data loss)
   - In-app banner: active users during the incident, so they don't open a support ticket

Example

# status.example.com — incident updates
14:08  🟡 Investigating — "We're investigating elevated error rates on checkout.
       Next update in 30m."
14:30  🟡 Update — "Still investigating. Error rate 100%, rollback in progress.
       Next update in 30m."
14:45  🟢 Resolved — "Checkout is operating normally. A postmortem will be
       published within 5 business days at /blog/postmortem-2026-03-15."

# In-app banner (shown to active users during the incident):
#   "We're experiencing issues with checkout. Status: status.example.com"
#   (dismissable, but visible — prevents 200 support tickets)

# Email to affected customers (only if data impact, e.g., orders lost):
#   Subject: Incident on 2026-03-15 — checkout errors
#   "We experienced an issue with checkout from 14:05-14:15 UTC that may have
#    affected your orders. We're sorry. A postmortem is at /blog/..."

# Postmortem (published 5 business days later, linked from status page):
#   What happened, why, what we changed. Honest, technical, no spin.

Common Problems

⚠Status page says "all systems operational" during an outage — instant trust destruction; acknowledge within 5m even without root cause.
⚠Euphemistic language ("degraded performance", "suboptimal experience") — customers read it as cover-up; say "checkouts are failing" plainly.
⚠No update cadence — the page says "investigating" and goes silent for 45m; a "still investigating" update every 30m proves we're on it.
⚠No postmortem published after promising it — the commitment builds trust, but breaking it destroys more than the outage did.

Best Practices

✓Acknowledge on the status page within 5m of declaration, before root cause — silence during an outage destroys trust faster than the outage itself.
✓Update every 30m even with "no new info"; state the impact honestly ("checkouts failing" not "degraded") and include scope.
✓Commit to a postmortem in the resolution message and actually publish it within 5 business days — the follow-through is what restores trust.
✓Use in-app banners for active users during the incident to prevent a flood of support tickets; the banner links to the status page.