## TL;DR
Chase stuck escalations with new information, not with "any update?" Check the ticket first, add something useful (more reports, a pattern, customer impact growth), and frame the nudge around the customer, never around blame. Polite persistence works because it makes the engineer's next step easier, not because it applies pressure.

## The query

```text
how to chase engineering on a stuck escalation politely
```

## Use this when

- An escalation has gone quiet past its expected window
- Agents are afraid to nudge engineers
- Escalation SLAs keep slipping
- The customer is asking and you have nothing new

## Not for

- Writing the initial escalation
- What to tell the customer while you wait
- Re-prioritizing engineering's backlog
- Formal escalation-path disputes

## Steps

### 1. Check before you bump

Read the escalation thread first. There may be an update you missed, a linked fix in progress, or a comment from an engineer you didnt see. Bumping on a ticket that moved yesterday burns credibility.

Expected output: you never ask for an update that already exists.

### 2. Bring new information every time

A bump with fresh data is helpful; "any update?" is nagging. Add ticket counts, a new reproduction detail, a pattern you noticed, or growing customer impact. If you have nothing new, wait.

Expected output: every nudge adds something the engineer didnt have.

### 3. Frame it around the customer, not the clock

"Three more enterprise accounts hit this today" moves things; "this has been open 6 days" just states the obvious. Engineers respond to impact, not to elapsed time.

Expected output: the nudge reads as useful context, not a complaint.

### 4. Ask for the next step, not the fix

"Is there anything from our side that would help move this along?" beats "when will this be fixed?" The first invites collaboration; the second demands a date nobody can give.

Expected output: the conversation moves toward action instead of stalling on timelines.

### 5. Escalate the escalation when it is truly stuck

If polite nudges with new info go nowhere for two cycles, raise it through the chain: your lead talks to their lead. This is not going over someone's head; it is the process working as designed.

Expected output: stuck escalations have a defined next rung, not an infinite polite loop.

## Ready-to-use nudge

```text
Quick update on [escalation]: three more accounts hit this today,
including [Account], and the workaround stopped working for one of
them. Happy to get you a customer call or more logs if that helps.
Anything you need from our side?
```

## Variant phrasings

### how to follow up on an engineering escalation

Steps 1 through 3. Check, add info, frame on impact.

### polite ways to nudge developers on a bug

Step 4. Asking for the next step instead of a date is the whole technique.

### escalation stuck with engineering what to do

Steps 2 and 5. New information first, the chain second.

## Why it happens

Escalations stall because they compete with everything else engineering owns, and a support ticket with no new information is easy to defer. The nudge works when it changes the ticket's information state. "Any update" changes nothing, so nothing changes.

## Edge cases

- The engineer says it is deprioritized: get that in writing on the ticket, then tell the customer honestly. A clear no beats a silent maybe.
- You have genuinely nothing new: dont bump. Silence with nothing to add is fine; noise trains engineers to filter you.
- The customer is escalating to you: shield engineering from the customer's tone. Translate anger into impact data before you nudge.
- Multiple stuck escalations with one team: batch them into one conversation with the team lead instead of five separate nudges.
- The fix shipped but nobody told support: check release notes and the fix version before bumping. Close the loop yourself when you can.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lQEIHoPo_YZuxdTv8d2VMQ