The Escalation Note a Reviewer Can Act On in One Page

Every reviewer, whether a senior engineer, a finance lead or a product owner, runs the same opening sequence in under ten seconds:

1. What is broken? Not the background of the project, not the history. The one sentence that describes what should be happening and is not.
2. What have you already tried? If the reviewer cannot see evidence of effort, their first move is to ask you to try something you already tried, and the clock resets.
3. What do you want me to do? A decision, an approval, a piece of access, a second opinion. If the note ends without a specific ask, the reviewer either guesses or ignores it.

The escalation criteria research on in-app agents formalizes this. Escalation should carry the trigger, the attempted steps and the customer context, otherwise the human starts from zero Userflow's escalation criteria guide. The same guide notes that a handoff succeeds only when the transcript, attempted steps, context and trigger travel with the conversation. Swap "customer" for "request" and you have the human version.

Two failure modes account for most bad notes. The first is the diary: a chronological account of everything that happened, with the actual problem buried in paragraph five. The second is the plea: a detailed description of a problem with no ask at the end. Both cost the reviewer a full minute of reading to extract what could have been three lines.

Here is the fill-in structure. The word limits are not decoration; they force the writer to choose the load-bearing facts. Keep the whole note under 250 words, excluding code, logs and links.

**Status:** <ONE sentence: what should be happening, what is happening instead.
Include the impact in one number: users, dollars, hours or records affected.>
**Asked of you:** <ONE sentence: the specific decision, approval, access or action.
Name the artifact you need back, e.g. "a yes/no on the schema change">.

**Tried (most recent first):**
1. <Action> -> <Result, with evidence: error text, metric, link>
2. <Action> -> <Result>
3. <Action> -> <Result>
(Stop at 5. If you have tried more, list the 5 that would most change the reviewer's thinking.)

**My current theory:** <ONE sentence. Mark it as unconfirmed.>

**What I need from you, by when:** <Exact ask, exact deadline, exact format
of the answer (yes/no, approval in the ticket, 15 minutes on a call).>

**Links:** <ticket> | <dashboard or trace> | <the one doc that matters>

Three rules make the template work. First, every "tried" line ends in a result you could show someone, not an intention. "Retried the job" is not a result; "retried the job, it failed again at step 3 with HTTP 429" is. This mirrors the failure taxonomy for agents in production, where silent partial success (a step failed and the outcome never happened) is one of the recurring failure modes, and the fix is to verify outcomes externally rather than trust a self-report Winder's agent failure analysis. A human note has the same bug: "I checked the logs, looks fine" is a self-report.

Second, the status line carries a number. "Checkout is failing for about 500 sessions an hour" tells the reviewer whether to drop what they are doing. "Checkout has issues" does not.

Third, the ask names the format of the answer. "Approve or reject in ticket OPS-412" takes the reviewer ten seconds. "Let me know what you think" requires them to compose a reply, which means it waits until they have time.

Other escalation templates organize the same field set differently. Bit.ai's escalation template front-loads the incident description and contact details, and Docsie's customer escalation playbook groups the work into criteria, severity, roles and timeline sections. Both include an "immediate actions taken" element for the same reason: the receiving tier needs to know where the problem has already been probed. Neither replaces the ask, which is where most of these templates quietly fail.

Consider a realistic case: a nightly reconciliation job that has stopped producing output for the finance team.

The bad version, which is typical:

Hi, the reconciliation job is failing again. I looked at the logs and there seems to be an issue with the data coming from the upstream system. Can you take a look? It's blocking the finance close.

Why it fails: no impact number, no evidence, no ask, and a theory ("issue with the data") stated as fact without a check. The reviewer will ask three questions before doing anything.

The good version:

Status: Nightly reconciliation has produced no output since the last successful run; the finance close is waiting on 2 of 14 accounts. Last output file: recon_0912.csv, 00:40. Asked of you: Yes/no on whether I may re-run the job against the corrected feed with the duplicate rows dropped, so finance can close today.

Tried (most recent first):

1. Re-ran the job unchanged -> exits at stage 2 with "duplicate key in feed_rows" after 40 seconds.
2. Diffed the upstream feed against yesterday -> 1,204 duplicate rows on account 7 (link below).
3. Traced the duplicates to the vendor export, which now sends the previous day plus the current day -> confirmed in vendor changelog (link below).

My current theory (unconfirmed): the vendor export format changed and the de-dup step no longer matches on the new key. What I need from you, by when: yes/no in the ticket by 15:00 today, so the close can finish before the cutoff. Links: OPS-412 | recon run trace | vendor changelog

The second note is 160 words. It names the impact (2 of 14 accounts), shows three attempts each ending in evidence, marks the theory as unconfirmed, and asks for a binary decision with a deadline and a place to answer.

Notice what the good note does with numbers. It states them plainly and links the source. That is the same discipline recommended for verifying AI-generated calculations: check the inputs, confirm the formula, reproduce the operations independently, and check units before trusting the output Manuel Garcia's verification guide. When the escalation note itself was drafted with a model, the numbers in it get the same treatment. A count like "1,204 duplicate rows" should be reproducible from the linked file in one query, because confidently presented erroneous output is exactly the risk IBM's explainer on AI hallucinations warns about.

Before sending, simulate the reviewer. Read only the first four lines and answer these five questions. Each one is pass or fail; any fail sends the note back for a rewrite.

Run the check on your own note, out loud if possible. Reading aloud exposes the diary problem fast: if you are still explaining background at the 30-second mark, the reviewer has already stopped.

There is a second, cheaper test: hand the note to someone outside the project for 60 seconds, take it away, and ask them what is broken and what you want. If they cannot answer both, the note is not ready. This is the person-level version of the pre-action check that agent systems run before a tool call, where the requested action is compared against the declared purpose, the data involved and expected behavior before anything executes Token Security's intent verification guide. A note that fails the comparison never reaches the reviewer.

If you draft notes with a model's help, keep the model on the parts where it is strong: tightening the status line to one sentence, converting your notes into "action -> result" lines, and flagging claims that have no evidence attached. The five-step fact-checking workflow for AI drafts applies directly: separate claims from style, triage the risky ones, and verify each against a source that says the same thing TextSight's verification workflow. For a note going to a reviewer, the "source" is usually your own trace or dashboard, which is faster to check than any external reference.

The template is deliberately thin. Reviewers do not need, and will not read:

• The full history of the project. If the reviewer needs background, link one document. The note is a decision aid, not a status report.
• Blame. Naming a person or team as the cause invites a side conversation. Describe the mechanism instead.
• Speculation dressed as fact. Mark theories as theories. The handoff guidance is explicit that customer statements, verified facts, inferences and actions should be kept separate Salt's handoff guide.
• Secrets and credentials. Never paste tokens, passwords or unrestricted customer records into a note; use controlled references.

What does belong, beyond the template fields, is the evidence trail the reviewer can open in one click. For incidents in production systems, the observability literature is blunt about this: if your trace records only tool names and not arguments, you cannot tell whether the agent (or the person) picked the wrong thing or did the right thing wrongly Winder's failure analysis. The note's "tried" lines should carry the same argument-level detail. "Called the refund API" is a tool name. "Called the refund API with the wrong currency code" is an argument, and it tells the reviewer where to look.

A useful habit: keep a running scratch file during any investigation with one line per attempt, timestamped, in the action -> result format. When you escalate, the note is mostly copy and paste, and the "tried" list is already complete. The escalation rate itself is worth tracking as a signal, since a rising rate per hundred requests shows which kinds of work keep escaping Userflow's escalation guide.

Three patterns show up repeatedly once more than a handful of people are escalating.

The note goes to the wrong channel. An escalation that lands in a general channel has no owner. The handoff workflow needs a named destination and an acceptance step, where someone confirms they have picked it up Salt's handoff guide. A note that is technically excellent but posted where nobody owns it is stuck at "requested."

The same problem is escalated twice. Two people hit the same bug, write two notes, and the reviewer spends two minutes instead of one. A search for the error text before sending costs ten seconds. In agent systems this is the duplicate-action problem, and the fix is a stable identifier for the intended operation so retries map back to one record, not several Padiso's idempotency tutorial. For humans, the identifier is the ticket number: one ticket per problem, notes appended, not cloned.

The ask is a meeting instead of a decision. "Can we get 30 minutes to discuss?" is a legitimate escalation, but it should be the last resort, not the first. A well-formed yes/no question often resolves in one reply, and a call can follow if the answer is "no, and here is why." Reserve meetings for decisions that genuinely need discussion.

For teams that escalate a lot, or that want the note discipline applied consistently across a function, an expert who reads your context and hands back finished work can absorb the drafting load. Quanta Experts is built for that pattern, and the template above is the spec you would hand over.