## TL;DR
Waiting for perfect repro steps before escalating lets real bugs rot. Escalate with what you have: the solid facts up front, the gaps labeled as gaps, and your best hypothesis marked as a hypothesis. An honest partial escalation beats a perfect one that never gets written. Engineering would rather have 70 percent now than 100 percent never.

## The query

```text
how to escalate with incomplete reproduction steps
```

## Use this when

- The bug is real but you cant make it happen on demand
- "Need repro steps" has stalled an escalation for weeks
- The customer cant reproduce it reliably either
- You have strong evidence but a partial story

## Not for

- Bugs with clean, complete repro steps (just write those up)
- Outage or incident escalation
- Customer-facing updates about investigation status
- Asking engineering to debug live with a customer

## Steps

### 1. Separate known facts from gaps

Two lists: what you can prove happened, and what you dont know yet. "We know it failed at [time] for [account]" versus "we dont know the exact click path." Labeled gaps build trust; hidden gaps get the escalation bounced.

Expected output: the escalation shows its own blind spots.

### 2. Lead with the strongest evidence

The best timestamp, the clearest log line, the most detailed customer description. Put the single most convincing fact in the first two lines.

Expected output: engineering keeps reading past the first paragraph.

### 3. Offer your best hypothesis, labeled

"My guess: it happens when [condition], because [reason]. Confidence: low/medium." A labeled guess gives engineering a starting thread to pull.

Expected output: one hypothesis with an explicit confidence level.

### 4. Say what you need, specifically

"Can you check server logs for [account] around [time]" beats "please investigate." Specific asks get specific answers.

Expected output: the escalation ends with a concrete request, not a vague plea.

### 5. Keep digging in parallel

The escalation going up doesnt stop your investigation. Update the ticket as you learn more; partial escalations get stronger over time.

Expected output: the escalation thread accumulates evidence instead of going stale.

## Ready-to-use format

```text
PARTIAL ESCALATION: [one-line bug description]

STRONGEST EVIDENCE: [the one fact that proves this is real]

KNOWN:
- [fact]
- [fact]

GAPS:
- [what we dont know]
- [what we dont know]

HYPOTHESIS (confidence [low/medium]): [your best guess and why]

ASK: [the specific thing you need from engineering]
```

## Variant phrasings

### escalating bugs without full repro steps

Knowns versus gaps, strongest evidence first, specific ask. Honesty about the gaps is the technique.

### what to do when you cant reproduce a customer bug

Escalate the partial story now and keep investigating. The two tracks run in parallel.

### support escalation with missing reproduction

Label the hypothesis and bound the unknowns. Engineering bounces vague, not incomplete.

## Why it happens

Support teams treat repro steps as a gate: no repro, no escalation. But some real bugs are hard to reproduce, and the gate just delays them until the customer churns. Engineering doesnt actually need perfection; they need enough to start and honesty about the rest. The gate is a habit, not a requirement.

## Edge cases

- Zero evidence beyond "customer says it broke": that is not an escalation yet. Get one timestamp or one screenshot first.
- The hypothesis is wrong: fine. A wrong labeled guess still moves things faster than no guess, and you update it.
- Engineering bounces it anyway: ask what single piece of evidence would unblock them, then go get exactly that.
- Multiple agents sitting on partial stories about the same bug: merge them. Three partials often make one complete.

## Provenance

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