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.

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.