## TL;DR
Engineers joining a live customer call need a 60-second brief: who the customer is and their impact, what you have already ruled out, and the exact thing you need from them. Lead with impact, not chronology. "Enterprise customer, checkout down, we ruled out their network, I need you to check the payment service logs" gets action. A five-minute story gets a glazed engineer.

## The query

```text
how to brief engineering on a live customer call
```

## Use this when

- Pulling an engineer into a live customer call
- Escalations where engineering joins the thread
- Training support on engineering handoffs
- Engineers complain briefs are useless

## Not for

- Async bug reports (different format)
- Postmortems
- Paging engineers (the page is separate)
- Customer-facing explanations

## Steps

### 1. Lead with customer and impact

"Enterprise customer [Name], 200 seats, checkout fully down for 40 minutes." Impact first. Everything else is context for that sentence.

Expected output: a one-line impact statement.

### 2. State what you have ruled out

"Their network is fine, other customers on the same plan are fine, it reproduces on our test account." Ruled-out items stop the engineer from re-running your diagnostics and get them to the new information faster.

Expected output: a ruled-out list.

### 3. Make the exact ask

"I need you to check the payment service logs for [account] in the last hour." Not "can you take a look." The ask names the system, the scope, and the time window.

Expected output: a specific, scoped request.

### 4. Give them the customer-safe framing

Tell the engineer what the customer has been told and what not to promise. "They know we are investigating; do not mention the deploy." Engineers ad-libbing on live calls cause follow-up tickets.

Expected output: two lines of framing before they speak.

### 5. Debrief in two minutes after

What did engineering find, what is the next step, who owns the customer update. Write it in the ticket before everyone disperses.

Expected output: the ticket updated with findings and owner.

## Template: the 60-second brief

```text
ENGINEERING BRIEF (read verbatim, 60 seconds)
Customer: [Name], [tier], [seats/users]
Impact: [what is broken] for [scope] since [time]
Ruled out: [their network] / [other customers] / [repro on test account]
Ask: [check X logs for Y in window Z] / [confirm whether deploy N is related]
Customer knows: [what they were told]
Do not: [mention the deploy / promise ETA / speculate on cause]

Then: engineer speaks. Debrief after.
```

## Variant phrasings

### escalate to engineering live

Steps 1 through 3. Impact, ruled out, the ask.

### how to loop in engineering on a call

Full sequence. Step 4 is the one teams skip.

### engineering handoff on live incident

Steps 1, 3, and 5. Brief fast, ask precisely, debrief after.

## Why it works

Engineers triage on impact and act on specific asks. Chronological storytelling buries both. The ruled-out list is the highest-value part: it converts the engineer from "let me start from zero" to "let me start from step four." The customer-safe framing prevents the second incident, which is the engineer accidentally promising something on a live call.

## Edge cases

- The engineer disagrees with the severity: they own the technical call, you own the customer. State both.
- No engineer available: brief the on-call async with the same format and tell the customer the truth about timing.
- The customer is on the call while you brief: brief in plain language. No jargon the customer cannot follow.
- It turns out not to be an engineering issue: say so immediately and release the engineer. Do not keep them as an audience.

## Provenance

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