SLA Outage SOP Template â€” RACI, Escalation & Customer Templates

One-shot, distribution-ready Markdown SOP for outages: RACI, escalation matrix, timeboxes, runbook steps, customer messages and PIR checklist.

What You'll Get

Complete Markdown SOP ready for internal distribution and KB posting: Purpose â†’ Scope â†’ Procedure â†’ QA checks â†’ Escalation.

RACI table mapping provided support roles to Incident Detection, Triage, Mitigation, Communication, RCA and PIR responsibilities.

Escalation matrix formatted as a stepwise ladder: trigger â†’ action â†’ role â†’ max time before escalation (based on supplied time targets and business hours).

Time-to-action timeboxes per severity: Detect â†’ Acknowledge â†’ Initial Mitigation â†’ Customer Notification â†’ Escalate â†’ Major Incident declaration.

Operator runbook: stepwise, actionable checks/commands/UI actions for the first 60 minutes.

Three customer-safe communication templates (Incident Start, Update, Resolution) with placeholders and neutral ETAs.

Post-Incident Review (PIR) checklist with owners, deliverables, and deadlines (e.g., PIR within 7 business days).

QA validation checklist (5 checks), an explicit Assumptions block (with Confirm or revise notes), and version/author/last-updated metadata.

How to Use

1Provide the required inputs (service_name, audience, tone, severity_definitions, support_tiers, business_hours, response_time_targets, required_sections). If any are missing, the prompt will ask up to three clarifying questions.

2Run the prompt in ChatGPT with your inputs; review the generated Markdown SOP and replace role placeholders with real role contacts (no personal emails), confirm timeboxes against on-call coverage, and publish to your KB.

3Validate the SOP with a tabletop exercise or simulated incident to confirm escalation accuracy and timing; update the SOP after the exercise.

4Use the customer templates as-is for status pages and emails; ensure legal/comms review for regulated industries before sending customer-facing content.

Keep roles and timeboxes current â€” run a quarterly tabletop

Before publishing, confirm that the support_tiers and business_hours reflect current on-call rotas. Run a quarterly tabletop to validate the escalation matrix and time-to-action targets; update the SOP and mark the change log. For any assumed contact/coverage, replace role placeholders with the actual on-call role and add an on-call rota link in your KB.

Works Best With

Best used when you can provide clear role lists, severity definitions, business hours and response targets

Provide a complete list of support tiers/roles (role names only) so the RACI and escalation matrix can reference exact teams.

Supply concrete response_time_targets per severity (Detect/Acknowledge/InitialMitigation/CustomerNotification/Escalate) to lock timeboxes.

Indicate business hours and on-call coverage explicitly (24/7 vs limited weekend) to ensure escalation timing is realistic.

When a backup gateway or rollback option exists, note it; otherwise the SOP will mark these as assumptions requiring confirmation.

Prompt Template


## Goal
- Produce a production-ready **SLA outage SOP** for a service or component that includes a **RACI**, **escalation matrix**, **time-to-action timeboxes**, **customer communication templates** (incident start / update / resolution), and a **post-incident review checklist**. The SOP must be distribution-ready for internal stakeholders and customer-facing support teams.

## Inputs
- Context: {{service_name}}
- Audience: {{audience}}
- Tone: {{tone}}
- Severity definitions (list of severities and impact criteria): 
  {{severity_definitions}}
- Support tiers and roles with contact points (list block):
  {{support_tiers}}
- Business hours / on-call coverage string: {{business_hours}}
- Time-to-action targets by severity (list mapping severity â†’ response/ack/action timeboxes):
  {{response_time_targets}}
- Required output sections (if additional sections are mandatory include as a list):
  {{required_sections}}

If any input above is missing or ambiguous, the prompt below must ask up to three concise clarifying questions before producing the SOP.

## Prompt
You are an expert Support Ops / SRE technical writer. Using the inputs provided, produce a concise, distribution-ready **SLA Outage SOP** for {{service_name}} tailored to {{audience}} in a {{tone}} voice. Follow these requirements exactly:

- Produce an **Executive Summary** (1-2 short paragraphs) stating the service, typical impact of outages, and the objective of this SOP.
- Follow the SOP structure: **Purpose â†’ Scope â†’ Procedure â†’ QA checks â†’ Escalation**. Use clear headings and bullet steps.
- Create a **RACI table** mapping the roles from {{support_tiers}} to responsibilities for Incident Detection, Triage, Mitigation, Communication, Root Cause Analysis, and Post-Incident Review.
- Deliver an **Escalation Matrix** formatted as a stepwise ladder: trigger condition â†’ immediate action â†’ next-level contact (use roles from {{support_tiers}}) â†’ maximum time before escalation. Base timeboxes on {{response_time_targets}} and {{business_hours}}.
- Provide **Time-to-Action Timeboxes** per severity that include: Detect â†’ Acknowledge â†’ Initial Mitigation â†’ Customer Notification â†’ Escalate â†’ Declare Major Incident (if applicable). Use the exact targets from {{response_time_targets}}.
- Include precise **operator runbook steps** for initial triage and mitigation (stepwise commands/checks or UI checks expected for the first 60 minutes). Keep steps actionable and minimal.
- Generate **Customer Communication Templates** with clear placeholders. Provide three templates: **Incident Start**, **Incident Update**, **Incident Resolution**. Each template must include: Incident ID, Summary of Impact, Scope (who/what is affected), Current status, ETA or next expected update, Actions being taken, Known workarounds, and a sign-off line with point-of-contact role (not personal emails). Use neutral, policy-safe, and non-committal wording for ETAs (e.g., â€œestimated time to next update: Xâ€).
- Add a **Post-Incident Review (PIR) Checklist** covering required artifacts (logs, timelines, decision timestamps), owners, deadlines (e.g., PIR within 7 business days), required deliverables (root cause, corrective actions, preventive measures), and customer follow-up requirements.
- Include a short **QA checks** section listing 5 validation steps that must be confirmed before closing the incident (e.g., functionality tests, monitoring stability window, customer confirmation).
- Mark any **assumptions** you made from missing inputs in a clearly labelled â€œAssumptionsâ€ block. For any assumption that significantly changes responsibilities or timelines, add an explicit instruction: â€œConfirm or revise.â€
- Do NOT invent contact details or personal data. If a contact is unknown, list the role only (e.g., â€œDatabase On-callâ€).
- Keep the final SOP to approximately 1-2 pages (concise) but include all required elements. Use Markdown headings, bold key terms, and bullet lists. Produce tables in Markdown where appropriate (RACI and Escalation Matrix).
- If any required input is missing, ask up to three clarifying questions instead of producing the SOP.

Produce only the SOP content (no prefatory explanation, no process for how you wrote it). Ensure the output is copy-paste ready for distribution and internal posting.

## Output Format
- SOP: Purpose â†’ Scope â†’ Procedure â†’ QA checks â†’ Escalation
- Include these components within the SOP:
  - Executive Summary
  - RACI table (Markdown)
  - Escalation Matrix (Markdown table)
  - Time-to-Action Timeboxes (bullet list or table)
  - Operator Runbook: first 60 minutes (stepwise)
  - Customer Communication Templates: Start / Update / Resolution
  - Post-Incident Review Checklist (with owners and deadlines)
  - Assumptions (explicit)
  - Version, Author (role), Last updated date

## Guardrails
- Separate **Facts** vs **Assumptions** in the SOP. Label assumptions explicitly.
- Do not make policy claims or SLA guarantees without sourcing them; if you include a guarantee, cite the source or mark as â€œto confirm.â€
- Redact or avoid including any personal PII or email addresses. Use role names only (from {{support_tiers}}).
- Use neutral, non-accusatory language when describing customer impact or root causes.
- Do not promise timelines beyond the provided {{response_time_targets}} or that cannot be supported by the supplied inputs.
- If a step requires privileged actions (e.g., data deletion, rollback), mark it **action requires approval** and call out the approval role from {{support_tiers}}.
- If any input conflicts (e.g., response times shorter than feasible during off-hours), flag the conflict in â€œAssumptionsâ€ and recommend a corrective change.

## Examples
- Mini decisions/actions excerpt (example format to mirror):

Decisions
- Declare Severity 1 for total API outage affecting all customers â€” Decision by: On-call Lead â€” Time: T+6 minutes

Actions (owner / date)
- Notify Customers via Status Page and Email â€” Owner: Incident Commander â€” Due: immediate (T+10 minutes)
- Scale database read replicas as mitigation step â€” Owner: Database On-call â€” Due: T+20 minutes

Open questions
- Confirm whether rollback to previous release is permitted without executive approval

Use the structure and formatting above to generate the full SLA Outage SOP when all inputs are provided.

Variables

Usage Notes

Not for

â€¢ Replacing a full disaster recovery plan with infrastructure-specific commands and credentials (the template is SOP/communications focused).

â€¢ Automated generation of privileged operations (e.g., data deletions or rollbacks) without explicit approval â€” those steps must be marked 'action requires approval'.

â€¢ Legal/regulatory compliance audits that require jurisdiction-specific legal language â€” consult legal first.

Do not include

â€¢ Personal PII or direct email addresses (use role names only).

â€¢ Hard SLA percentage guarantees or claims about business impact reduction (the SOP provides operational controls but not guaranteed outcomes).

â€¢ Vendor-specific credentials, secret keys, or exact production IPs.

SLA Outage SOP Template â€” RACI, Escalation & Customer Templates

Generate a concise, production-ready SLA outage SOP in Markdown that includes RACI, an escalation matrix, time-to-action timeboxes, operator runbook (first 60 minutes), customer communication templates (start/update/resolution), and a post-incident review checklist.

Turn this into a working asset in minutes.

Import into Workspace to auto-fill variables, adapt output style, and iterate with OctiAI's prompt editor.

Auto-fill & personalize from your inputs

AI-assisted edits: tone, structure, constraints

Attach context so outputs stay consistent

Iterate and save versions

What you'll get

Output format

Markdown

Best used when

When working on template or detailed.

Avoid when

Replacing a full disaster recovery plan with infrastructure-specific commands and credentials (the template is SOP/communications focused).

Made for

What to fill in

Use the guidance below to complete each placeholder with the right level of detail.

Service Name