Tickets
AuraScore 81/100

Critical Outage De-escalation Call Script

Generate a high-stakes phone and screen-share script for de-escalating VIP customers during critical SaaS service outages.

Use this template when an enterprise customer faces severe production downtime and demands an immediate live bridge call. It structures empathetic acknowledgment, technical status updates, and clear commitments without creating contractual liability.

Template

Role: Senior Technical Support Escalation Manager with over a decade of enterprise SaaS crisis mitigation experience.

Context

  • Impacted platform: {{software_platform}}
  • Nature of outage: {{incident_type}}
  • Customer tier and ARR: {{affected_customer_tier}}
  • Contractual SLA status: {{sla_breach_status}}
  • Preliminary technical diagnosis: {{root_cause_preliminary}}
  • Available temporary mitigation: {{workaround_status}}

Task

Produce an exhaustive, spoken dialogue script and accompanying contingency branching paths for a live voice escalation bridge with an enterprise account affected by a tier-one support incident.

Method

  1. Review {{software_platform}} telemetry alongside the customer profile in {{affected_customer_tier}} to gauge operational severity.
  2. Formulate an opening empathy statement that acknowledges the business disruption caused by {{incident_type}} without accepting premature financial or legal liability.
  3. Translate {{root_cause_preliminary}} into precise, transparent language suitable for executive stakeholders.
  4. Draft a step-by-step verbal guide explaining {{workaround_status}} to restore partial customer operations immediately.
  5. Address {{sla_breach_status}} by outlining standard audit timelines and commercial credit processes without making unauthorized verbal promises.
  6. Build three conversational branching modules handling customer anger, aggressive legal threats, and demands for unverified restoration times.
  7. Detail a concluding commitment framework specifying exact update cadence and named technical ownership.

Constraints

  • MUST include exact verbatim dialogue in double quotation marks for all spoken lines.
  • MUST NOT make definitive uptime guarantees or reveal internal engineer names.
  • All references to commercial credits MUST direct the stakeholder to standard post-incident SLA review procedures.
  • Spoken pacing cues and emotional tone markers must be enclosed in bracketed directives.

Output format

1. Escalation Call Parameters

Bullet points summarizing caller roles, incident severity, and target call duration.

2. Primary Verbal Script

Chronological spoken script organized into: Opening & De-escalation, Technical Situation Report, Workaround Walkthrough, and Cadence Commitment.

3. Objection and Crisis Branching Scripts

Three scenario-based dialogue blocks addressing extreme frustration, executive escalation demands, and legal/SLA challenges (120-180 words each).

4. Wrap-up and Post-Call Ticket Note

A standardized 80-word internal support ticket summary summarizing commitments made.

Self-review

  • Does the script avoid making binding financial commitments regarding {{sla_breach_status}}?
  • Are technical explanations of {{incident_type}} accurate yet comprehensible to non-engineers?
  • Is every spoken interaction clearly marked with bracketed delivery cues?
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.

support-success
support-tickets
technology-software
escalation
incident-management
de-escalation