Enterprise Outage Root-Cause Resolution Notice
Draft an executive post-incident resolution email communicating root cause and remediation for SaaS ticket closures.
Use this template when closing high-priority outage tickets for enterprise software clients. It establishes technical accountability while outlining concrete preventative engineering steps.
Role: Principal Technical Account Support Lead specializing in enterprise SaaS incident communications.
Context
- Client Account Name: {{customer_name}}
- Associated Support Ticket: {{incident_id}}
- Affected Software Service: {{system_impacted}}
- Total Service Interruption: {{downtime_duration}}
- Technical Root Cause: {{root_cause_summary}}
- Engineering Fixes: {{preventative_actions}}
Task
Draft a formal post-incident resolution email addressed to the customer technical lead, detailing the resolved ticket, incident chronology, underlying technical trigger, and operational safeguards deployed to prevent recurrence.
Method
- Review the ticket identifier {{incident_id}} and confirm the impacted system {{system_impacted}} and downtime duration {{downtime_duration}}.
- Open with clear confirmation that service has returned to 100% operational baseline.
- Detail the operational impact experienced by {{customer_name}} during the incident window.
- Explain the technical root cause described in {{root_cause_summary}} without shifting blame to third parties.
- Detail the immediate hotfix implemented to resolve the active ticket.
- Itemize preventative engineering measures from {{preventative_actions}} with explicit release milestones.
- Reiterate support ticket SLAs and provide direct escalation channels for residual anomalies.
Constraints
- MUST maintain an objective, accountable, and transparent engineering tone.
- MUST clearly state the ticket ID {{incident_id}} in both subject line and opening section.
- MUST NOT use speculative language or unverified engineering timelines.
- Do not include internal diagnostic jargon that lacks customer context.
- Restrict total email body length to under 450 words.
Output format
- Subject Line: Formatted as [RESOLVED] {{incident_id}} - {{system_impacted}} Service Incident Report
- Section 1: Executive Status & Service Confirmation
- Section 2: Technical Incident Summary & Timeline
- Section 3: Root Cause Analysis
- Section 4: Remediation & Preventative Engineering Actions
- Section 5: Support Escalation & Ticket Closure Sign-off
Self-review
- Did I accurately incorporate {{downtime_duration}} and {{root_cause_summary}} without vagueness?
- Are all preventative actions from {{preventative_actions}} clearly structured with target completion markers?
- Does the email fulfill enterprise SLA notification standards without defensive wording?
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.