The Impact Statement Discipline During Incidents

Customers care about impact, not cause. The impact statement that customers actually need.

Template

The impact statement is four sentences during an active incident. Who is affected, what they cannot do, when it started, when resolution is expected. Nothing more. Customers care about user-visible impact, not internal architecture.

• Who is affected. Customer segment, region, or use case per incident. Specific, not “some customers.”
• What they cannot do. User-visible blocked action. “Cannot complete checkout” not “service degraded.”
• When it started. Explicit start time per incident. Anchors the impact window.
• When resolution is expected. Best-estimate ETA. Honest even if uncertain.

Avoid

Two failure modes destroy customer trust during an active incident. Technical jargon hides impact behind language customers do not care about; speculation that proves wrong damages trust faster than admitting uncertainty would.

• Technical jargon. No internals per update. Customers do not care about etcd quorum; they care about login.
• Speculation. Only confirmed facts per update. Speculation that proves wrong damages trust permanently.
• Named author per update. Responsible writer per update. Continuity through long incidents.
• Structured tag per update. “[CONFIRMED]” or “[INVESTIGATING]” prefix. Honest signal levels.

Update

Updates compound across the incident. Each new finding produces a new statement; old statements stay visible with timestamps so the journey is preserved. Superseded markers prevent the appearance of inconsistency.

• New finding equals new statement. Published update per finding. Drives the steady cadence customers expect.
• Old statements remain visible. Timestamped history per incident. The journey is part of the trust.
• Explicit superseded marker. “Previous estimate revised” note. Catches the appearance of inconsistency.
• Resolved-statement archive. Post-resolution summary view per incident. Supports postmortem reconstruction.