The Incident Comms Template Customers Trust

Customer-facing incident comms are a craft. The template that builds trust, the rhythm of updates, and the words that erode credibility.

The template

The template is four lines, every line in plain customer terms, specific rather than vague, with a committed time for the next update. Hitting the four lines on every update is the difference between trust-building comms and the kind of corporate update that gets screenshotted and mocked.

• What is happening. One-sentence customer-terms summary. Plain language; no internal jargon, no service names customers do not know.
• Who is affected. Specific named segment, region, or use case. Vague scope kills trust faster than the original problem.
• What we are doing. Current action in plain language. "Rolling back the deploy" beats "investigating broadly."
• When the next update. Explicit time, committed and met. Customers stop refreshing and you stop being asked.

Update rhythm

The rhythm is fixed across incidents so customers learn what to expect. First update inside 15 minutes (even if it just acknowledges the problem), steady 30-minute cadence during investigation, close-out with cause and prevention. Named author per update keeps continuity through long incidents.

• First update within 15 minutes. Early acknowledge target. "We are investigating" is enough; the gap before the first post is what damages trust.
• Every 30 minutes during investigation. Steady-state cadence. Set the expectation and hit it.
• Resolution with cause and prevention. Close-out post explains what broke and what changes prevent recurrence. Customers want non-recurrence more than they want apology.
• Named author per update. Responsible writer for continuity. Long incidents especially need one consistent voice.

Words to avoid

Three phrases erode trust faster than anything else customers see. "Working as designed" when something is broken; "a small subset of users" without naming the segment; "should be resolved" as hedging. Document the avoid list per team so new comms writers do not learn it by burning customer trust.

• "Working as designed" when broken. No-spin rule. If something is broken from the customer's perspective, design intent is irrelevant.
• "A small subset of users" without naming. No-vague-scope rule. Be specific or do not quantify; vague reads as evasion.
• "Should be resolved" hedging. Commit-or-do-not-claim rule. Hedging on resolution status reads as uncertainty about whether it actually is resolved.
• Documented avoid list per team. Published phrase guide for incident comms. New writers do not learn the list by accidentally burning trust.