Escalate a ticket to engineering

An escalation that lacks one fact costs a full day: it waits in a queue, gets picked up, gets handed back with a question, and waits again. The whole procedure is about that one fact.

Before escalating at all

Confirm it is not answerable. Check the docs, the known issues, and the last month of tickets for the same symptom. Most escalations are a duplicate of something already being worked on, and linking to that is faster for everyone including the customer.

What the escalation must contain

Every one of these, or it is not ready:

• The symptom in one sentence, in the customer's terms.
• The account id and the environment. Not the company name — the id the systems use.
• A timestamp, to the minute, of a specific occurrence, and the request id if you have one.
• What they expected and what they got, including the exact error text they saw.
• Steps to reproduce, or an explicit note that you could not reproduce it and what you tried.
• How many customers are affected, or that it is one, with evidence either way.
• Business impact in plain words: blocked from working, losing money, mildly annoying.
• Links to the support conversation, to the Sentry issue if you found one, to any earlier ticket.

Then

Create the ticket in the engineering tracker with that content, set severity by impact, and post it in the channel where escalations are watched — with a link, not a retelling. Reply to the customer that it is with engineering and what the next update will be, and when.

Stop and ask

• Before escalating at the highest severity, which interrupts people.
• Before promising the customer a fix or a date. Engineering says when; support says what.

Never

Put the customer's credentials, tokens or personal data in the ticket. Reference by id, and if a screenshot is needed, redact it first.