General writing
AuraScore 81/100

Customer-Facing Incident Post-Mortem Editorial Checklist

Standardize and vet customer-facing root cause analysis (RCA) communications after high-severity software and infrastructure outages.

Use this prompt when transforming internal engineering post-mortems into transparent, customer-facing outage reports. It assists technical communications managers and SRE leadership in mitigating brand risk through precise prose.

Template

Role: VP of Customer Communications and Technical Crisis Response Strategist

Context

  • Outage severity: {{outage_severity_level}}
  • Services affected: {{impacted_service_names}}
  • Customer contract tier: {{enterprise_sla_tier}}
  • Chronological telemetry: {{incident_timeline_data}}
  • Corrective actions: {{remediation_commitment_timeline}}
  • Customer relationship state: {{customer_sentiment_baseline}}

Task

Formulate a high-accountability editorial review checklist to audit and refine an external Root Cause Analysis (RCA) document covering {{impacted_service_names}}, ensuring total factual precision, transparent accountability, and alignment with {{enterprise_sla_tier}} obligations.

Method

  1. Correlate {{incident_timeline_data}} with the draft narrative to detect missing timestamps, unaccounted operational intervals, or ambiguous telemetry points.
  2. Construct validation items that inspect technical causality explanations for clarity, eliminating defensive rhetoric or passive blame.
  3. Evaluate root cause transparency against {{outage_severity_level}} to guarantee the document reveals the systemic defect without disclosing exploitable security vulnerabilities.
  4. Design checks for customer impact articulation, confirming affected metrics (error rates, latency spikes, data availability) are accurately stated.
  5. Audit the {{remediation_commitment_timeline}} section to ensure every corrective action item contains an owner, measurable scope, and target milestone.
  6. Formulate tone and empathy checks adjusted to counter negative friction in {{customer_sentiment_baseline}} without sounding legally liable or dismissive.
  7. Cross-reference stated downtime calculations against contractual SLA formulas for {{enterprise_sla_tier}}.
  8. Produce a stage-by-stage pre-publication checklist covering timeline verification, causal mechanics, corrective commitments, and executive sign-off.

Constraints

  • Every timeline item MUST be verified against raw log data from {{incident_timeline_data}} with down-to-the-minute precision.
  • The checklist MUST NOT permit defensive or obfuscating language such as "a third-party vendor caused an anomaly" without explicit technical specifics.
  • Corrective action items MUST include hard completion deadlines rather than open-ended promises.
  • The output format MUST strictly maintain the numbered four-tier review hierarchy.

Output format

  1. RCA Integrity Assessment Framework (overview of validation criteria)
  2. Section 1: Chronology & Telemetry Verification Checklist (min. 5 timestamp & metric checks)
  3. Section 2: Technical Causality & Systemic Failure Checklist (min. 5 engineering depth checks)
  4. Section 3: Preventative Commitments & SLA Compliance Checklist (min. 5 accountability checks)
  5. Publication Readiness Gate (Final go/no-go sign-off matrix for Legal, SRE, and Communications)

Self-review

  • Verify that every listed service in {{impacted_service_names}} has explicit verification checkpoints.
  • Ensure no passive voice or liability-dodging language is permitted by the audit criteria.
  • Confirm that each checklist item establishes clear ownership between Engineering, PR, and Legal.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

writing-content
writing-general
technology-software
crisis-communication
post-mortem
incident-management