escalation-brief

---
name: escalation-brief
description: Prepare structured escalation packages for engineering, product, security, or leadership with reproduction steps, business impact, and full context. Activate when a support issue needs to go beyond the support team, when writing an escalation document, when evaluating whether a problem warrants escalation, or when tracking follow-through after handing off an issue.
---

## Deciding: Escalate or Resolve In-House?

### Keep It in Support When:

- A documented fix or known workaround addresses the problem
- The root cause is a configuration or setup error you can correct
- The customer needs coaching or training, not a product change
- The limitation is documented and an alternative path exists
- Historical tickets with the same profile were resolved at the support tier

### Escalate When:

- **Technical barrier**: A confirmed defect needs a code-level fix, infrastructure-level investigation is required, or data has been lost or corrupted
- **Diagnostic ceiling**: The issue exceeds support tooling or access, involves a custom deployment, or demands database-level inspection
- **Widespread harm**: Multiple customers are reporting the same problem, production is down, data integrity is compromised, or a security threat exists
- **Business stakes**: A high-value account is at risk, an SLA has been breached or is about to be, or the customer is requesting leadership involvement
- **Stalled progress**: The issue has sat open past SLA, the customer has waited an unreasonable duration, or standard troubleshooting is not advancing
- **Recurring pattern**: Three or more independent reports of the same symptom, a previously-patched issue has resurfaced, or severity is trending upward over time

## Escalation Destinations

### Support L1 to Support L2

**Sender:** Frontline support agent
**Receiver:** Senior support / technical specialists
**Trigger:** Deeper investigation, specialized product expertise, or advanced debugging is needed
**Package contents:** Issue summary, troubleshooting already performed, customer context

### Support L2 to Engineering

**Sender:** Senior support
**Receiver:** Owning engineering squad
**Trigger:** Confirmed defect, infrastructure fault, code change required, system-level inspection needed
**Package contents:** Complete reproduction procedure, environment specifics, relevant logs and error output, business impact statement, customer-facing timeline commitments

### Support L2 to Product

**Sender:** Senior support
**Receiver:** Product management
**Trigger:** Capability gap causing pain, design-level decision needed, workflow mismatch, competing priorities across customers
**Package contents:** Customer use case narrative, business impact, request frequency, competitive context if available

### Any Tier to Security

**Sender:** Any support agent
**Receiver:** Security team
**Trigger:** Possible data exposure, unauthorized access report, vulnerability disclosure, compliance risk
**Package contents:** Observations, affected parties/systems, containment measures already taken, urgency rating
**Rule:** Security escalations skip tier progression entirely -- route immediately regardless of your level.

### Any Tier to Leadership

**Sender:** Typically L2 or a support manager
**Receiver:** Support leadership or executive staff
**Trigger:** High-ARR customer signaling churn, SLA breach on a strategic account, cross-functional decision required, policy exception needed, legal or reputational risk
**Package contents:** Complete business context, revenue exposure, actions taken to date, the specific decision or intervention needed, hard deadline

## Escalation Document Structure

Assemble every escalation using this framework:

```
ESCALATION: [Concise one-line summary]
Severity: [Critical / High / Medium]
Routed to: [Engineering / Product / Security / Leadership]

BUSINESS IMPACT
- Affected customers: [Count and names where relevant]
- Operational effect: [What is broken for them]
- Revenue exposure: [Dollar figure if applicable]
- SLA position: [Compliant / At risk / Breached]

PROBLEM NARRATIVE
[3-5 sentences covering: what is happening, when it began,
how it presents, and how wide the blast radius is]

REPRODUCTION PROCEDURE (for defects)
1. [Step]
2. [Step]
3. [Step]
Expected outcome: [X]
Observed outcome: [Y]
Environment: [Browser, OS, plan tier, feature flags, etc.]

ACTIONS ALREADY TAKEN
1. [What was tried] -> [Outcome]
2. [What was tried] -> [Outcome]
3. [What was tried] -> [Outcome]

CUSTOMER COMMUNICATION STATUS
- Most recent update: [Date and summary]
- Customer expectation: [What they believe will happen and by when]
- Further escalation risk: [Likelihood customer escalates beyond you]

REQUEST
- [Precise ask: investigate / ship a fix / make a decision / approve an exception]
- Hard deadline: [Date/time]

ATTACHMENTS AND REFERENCES
- [Ticket URLs]
- [Internal discussion threads]
- [Log files, screenshots, recordings]
```

## Quantifying Business Impact

Vague escalations get deprioritized. Anchor every escalation with measurable impact across these dimensions:

| Dimension | Key Questions |
|-----------|--------------|
| **Breadth** | How many customers or end users are affected? Is the number growing? |
| **Depth** | Are they fully blocked or merely inconvenienced? |
| **Duration** | How long has this persisted? When does it become critical? |
| **Revenue** | What ARR is exposed? Are pipeline deals at risk? |
| **Reputation** | Could this reach social media or press? Is a reference account involved? |
| **Contractual** | Are SLA terms being violated? Do contractual penalties apply? |

### Quick Severity Definitions

- **Critical**: Service down, data at risk, active security incident, or multiple high-value accounts impacted. Demands immediate action.
- **High**: Core functionality broken, key customer blocked, SLA threshold approaching. Requires same-day engagement.
- **Medium**: Significant issue but a viable workaround exists; business impact is real but not time-critical. Needs resolution within the current week.

## Crafting Effective Reproduction Steps

Precise reproduction instructions are the highest-value component of any defect escalation.

1. **Establish the baseline state**: Describe account type, configuration, permissions, and any prerequisites.
2. **Use exact actions**: "Select the Export CSV button in the upper-right corner of the Reports view" not "try exporting."
3. **Specify literal inputs**: Provide the actual data values, IDs, or strings used -- not "enter a value."
4. **Record the environment**: Browser and version, operating system, account plan tier, active feature flags.
5. **State the frequency**: Reproducible every time? Intermittent? Only under specific conditions?
6. **Attach evidence**: Screenshots, exact error text, network traces, browser console output.
7. **Document eliminations**: "Reproduced in both Chrome 122 and Safari 17" / "Occurs on both staging and production."

## Post-Escalation Follow-Through

Escalation without follow-up is abandonment. Stay engaged:

| Severity | Check-in with Receiving Team | Customer-Facing Update |
|----------|------------------------------|------------------------|
| **Critical** | Every 2 hours | Every 2-4 hours (or per SLA) |
| **High** | Every 4 hours | Every 4-8 hours |
| **Medium** | Once daily | Every 1-2 business days |

### Ongoing Responsibilities

- Proactively contact the receiving team for progress; do not wait to be told.
- Update the customer even when there is nothing new: "Investigation is ongoing -- here is what has been confirmed so far."
- Re-assess severity if circumstances shift in either direction.
- Maintain a running log of all updates in the ticket for auditability.
- When resolved: confirm with the customer, close internal tracking, and capture lessons learned.

## Knowing When to De-escalate

Escalation is not permanent. Pull an issue back when:

- Investigation reveals a cause that support can address directly
- A workaround is discovered that fully unblocks the customer
- The problem self-resolves (but still document the root cause)
- Updated information changes the severity calculus

### De-escalation Procedure

- Notify the team that received the escalation
- Record the resolution or new status in the ticket
- Communicate the outcome to the customer
- Document findings so future agents benefit from the knowledge

## Operating Principles

1. Quantify impact with numbers, not adjectives -- measurable escalations get faster attention.
2. For defects, reproduction steps are non-negotiable -- they are what engineering needs most.
3. Distinguish your ask: "investigate," "fix," and "decide" are different requests with different owners.
4. Attach a deadline to every escalation -- urgency without a timeline is ambiguous.
5. You own the customer relationship throughout; escalating the technical work does not transfer that responsibility.
6. Follow up before being asked -- proactive updates build trust with both the customer and the receiving team.
7. Log everything -- the escalation record is a resource for pattern detection and process improvement.