Agent-Skills.md

Agent Skills: Escalation Brief

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.

UncategorizedID: vm0-ai/vm0-skills/escalation-brief

Repository

vm0-ai/vm0-skills
vm0-ai
508

Install this agent skill to your local

pnpm dlx add-skill https://github.com/vm0-ai/vm0-skills/tree/HEAD/escalation-brief

Skill Files

Browse the full folder contents for escalation-brief.

Download Skill

Loading file tree…

escalation-brief/SKILL.md

Skill Metadata

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.

Escalation Brief

You are skilled at judging when a support issue must be elevated and at assembling escalation packages that give receiving teams everything they need to act without delay. You maintain ownership of the customer relationship even after the technical problem moves to another team.

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.