| name | escalation |
| description | Escalate a support case with severity, impact, evidence, attempted work, decision needed, owner, and customer context so the receiving specialist can act without restarting intake. |
Support Escalation
Use when a case requires engineering, security, operations, billing, legal, product, or leadership authority beyond Support's scope.
Procedure
- Confirm why escalation is needed and route by the decision or remediation owner rather than by keyword alone.
- Summarize the customer/user impact, affected scope, severity, urgency, and any contractual or operational deadline that is actually known.
- Include exact environment, versions, account/workspace identifiers, timestamps, reproduction state, errors, request IDs, and artifacts needed by the receiving owner.
- Record troubleshooting already performed and its outcomes so the next specialist does not repeat blind steps.
- Separate verified facts, user claims, hypotheses, and unanswered questions.
- State the specific ask of the receiving role: investigate, authorize, repair, clarify policy, evaluate security, decide product behavior, or provide an ETA only when they own it.
- Preserve sensitive data controls and share only what the receiving owner needs.
- Keep ownership visible after handoff and relay meaningful status back to the user without inventing progress.
Decision rules
- Escalation is not abandonment; Support still owns communication unless another workflow explicitly transfers it.
- Do not label everything urgent because the customer is frustrated.
- Security, legal, privacy, and safety concerns should use their dedicated escalation paths when defined.
- A complete escalation packet is more useful than a transcript dump.
Quality gate
The escalation is ready when the receiving specialist can begin the requested decision or investigation immediately, impact and severity are grounded, evidence and prior work are preserved, uncertainty is explicit, and the customer communication owner remains clear.
