## TL;DR
Write the escalation for an engineer who has never seen the ticket and has four minutes. One-line summary, how to reproduce it, what should happen vs what does, how many customers are hit, and what you already ruled out. Escalations get action when the engineer can start working without asking a single question.

## The query

```text
how to write an engineering escalation that gets action
```

## Use this when

- Escalations sit untouched or get bounced back
- Engineers ask for information you already had
- You are training agents on handoff quality
- The escalation queue feels like a black hole

## Not for

- Deciding whether a ticket should be escalated
- Severity or priority definitions
- What to tell the customer while you wait
- Chasing engineering on a stuck escalation

## Steps

### 1. Open with a one-line summary

The single most important sentence: what is broken, for whom. "CSV exports drop rows when a column is empty, affecting all Pro accounts." If the engineer reads nothing else, this has to be enough to triage.

Expected output: a summary line that works as a ticket title.

### 2. Give reproduction steps that actually work

Numbered, exact, starting from a clean state. Include the account type, the data shape, and the specific clicks. "Log in, go to exports, upload the attached file, click export" beats "export is broken."

Expected output: an engineer can reproduce the bug on the first try.

### 3. State expected vs actual

Two short lines: what should happen, what actually happens. This is the spec the engineer debugs against, and writing it forces you to confirm you understand the bug.

Expected output: no ambiguity about what "fixed" looks like.

### 4. Quantify the customer impact

How many customers, how many tickets, what is the business cost. "14 tickets this week, 3 enterprise accounts threatening to churn" moves faster than "customers are upset." Numbers are the escalation's fuel.

Expected output: impact stated in counts, not adjectives.

### 5. List what you ruled out

Configuration, permissions, browser state, known workarounds, the status page. This is the section that stops the bounce-back: it proves support did its job before handing off.

Expected output: the engineer never asks "did you try" about something you already tried.

### 6. Attach everything

Ticket links, screenshots, recordings, log timestamps, the exact error text. Put it in the escalation, not in a thread the engineer has to go find.

Expected output: all evidence one click away from the summary.

## Ready-to-use escalation format

```text
SUMMARY: [one line, what is broken for whom]

REPRO:
1. [exact step]
2. [exact step]
3. [exact step]

EXPECTED: [what should happen]
ACTUAL: [what happens instead]

IMPACT: [ticket count, accounts affected, business cost]

RULED OUT: [what support already checked]

EVIDENCE: [links, screenshots, timestamps]
```

## Variant phrasings

### engineering escalation template for support

The format block above. Copy it into your escalation tool as the default.

### how to escalate a bug to developers effectively

Steps 2 and 5. Working repro steps plus a ruled-out list are what separate effective escalations from noise.

### writing bug escalations engineers will read

Step 1. If the summary line cant carry the triage alone, nothing below it matters.

## Why it happens

Escalations get ignored because most of them are written as forwarded complaints: the customer's words pasted into a new ticket. Engineers cant act on complaints; they act on specifications. The escalation's job is to translate a customer problem into an engineering problem, and that translation is the whole skill.

## Edge cases

- You cant reproduce it: say so, and escalate with the pattern instead (frequency, conditions, affected accounts). Pattern escalations are legitimate.
- The bug is intermittent: include timestamps and frequency. "3 times today between 2 and 4pm" is actionable; "sometimes" is not.
- Urgent escalation: put the severity and the customer impact in the summary line itself. Dont make triage read to step 4.
- The engineer asks for a customer call: coordinate it, brief the customer first, and stay on the call. Never send an angry customer to engineering cold.
- Escalation for a third-party issue: name the vendor and link their status. Engineering needs to know it is not your code.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oPdze9-uOMrj6svWkpNNAw