Escalation to Engineering
Engineering ticket filed with full repro context. Customer ticket updated with eng reference number and SLA expectation. Slack notification posted in escalation channel. Escalation log updated: ticket ID, severity, customer tier, date filed, current status. Customer receives update every 24h (S1) or 48h (S2) until resolved.
Before you start
- Engineering escalation channel defined (Slack channel, Linear project, or Jira board)
- Bug report template agreed with engineering team
- Severity definitions documented and agreed with eng lead
- Customer support ticket describing a technical issue
- Any attached screenshots, error messages, or console logs from customer
- Account details: plan tier, environment (browser, OS, app version if applicable)
The steps
- Attempt first-line resolution — Check the knowledge base for a workaround, the status page for an open incident, and the last five similar tickets. If a workaround unblocks the customer, apply it and write it on the ticket. Escalate only what support genuinely cannot resolve.
- Collect full reproduction information — Numbered steps, expected behaviour, actual behaviour, the error message verbatim rather than paraphrased, browser and OS and version, account ID, when it started, and whether it is consistent or intermittent. Engineering rejects underspecified bugs, so do not send one.
- Attempt to reproduce internally — Follow the customer's exact steps on a test account. If it reproduces, screenshot and record it. If it does not, note the environment differences and escalate anyway when impact is confirmed. Tell the customer you are investigating — never that you cannot reproduce it.
- Classify severity and assign SLA — S1: core function broken, several customers, or data at risk — one hour to respond, four to fix. S2: broken feature with a workaround — four hours to respond, twenty-four to fix. S3: cosmetic or edge case — a day to respond, one sprint to fix. S4 is a feature request; route it to product, not the bug tracker.
- File engineering ticket with full context — Title it as severity, brief description, and the feature affected. Then customer impact in two sentences, numbered repro steps, expected versus actual, environment, the support ticket link, your reproduction result, and severity with your reasoning. Attach screenshots and logs. Describe the behaviour, not the customer's mood.
- Notify engineering via Slack — In the escalation channel: severity, ticket link, one-sentence summary, customer tier, impact, and whether repro is confirmed. Tag the on-call engineer for S1 and S2 only — S3 and S4 are picked up from the queue, and tagging everyone teaches people to mute the channel.
- Update customer and set expectations — Confirm it is logged, give them the tracker reference, and state the response time their severity buys. Do not name a fix date unless engineering has given you one. Update every 24 hours on S1 and every 48 on S2 until it closes.
If it goes wrong
Engineering rejects ticket as underspecified
Establish a pre-escalation checklist that mirrors engineering's triage requirements. Run checklist before filing — if any field is empty, go back to the customer for the missing info.
Customer escalation loop: customer contacts support again while bug is open
Set up a tracking thread on the customer's original ticket. Every inbound contact from that customer while the bug is open should auto-merge to the tracking thread with a status update note.
S1 bug filed in eng queue but not noticed for hours
S1 bugs must trigger a PagerDuty or Slack DM to on-call engineer, not just a channel post. Verify the S1 notification path quarterly with a test alert.
All OpenLabor playbooks