Escalation Summary to Leadership

The internal writeup a customer-facing team sends up when an account is in trouble and leadership needs to act — approve a credit, pull in an executive, free up engineering, or just know the money at risk. Handed the situation and asked to "escalate this", base models default to a worried email: an apology or backstory paragraph first, the account's dollar value and severity buried or missing, the actual ask softened to "please advise", and no owner or next-update commitment. A leader skimming ten of these needs the opposite — the stakes in the first line, one checkable claim per line, and an ask concrete enough to say yes or no to.

Write it as five labeled blocks, in this fixed order, one binary (verifiable) claim per line.

The fixed order

1. Account & Severity — one header line: account name, ARR or contract value, and a

severity or tier (Sev-1 / P1 / critical / high). This leads. Never open with the story.

1. What Happened — the facts, one claim per line: what broke or changed, when, what is

confirmed. No apology, no speculation dressed as fact.

1. Business Impact — what is at risk in business terms: renewal dollars, expansion,

a reference, a contractual/SLA breach. Separate from the incident facts.

1. The Ask — the specific decision, approval, or resource wanted from leadership,

concrete enough to act on. Not "please advise", not "let me know your thoughts".

1. Owner & Next Update — who owns the account/incident right now, and a committed time

or date for the next update.

Rules

1. Header first, always. The first line carries account + ARR/value + severity. A reader

who stops after line one still knows which account and how much money is at stake.

1. One binary claim per line. Each line states one thing that is true or false — "Renewal

is $240K, closes in 30 days." Not compound, not hedged into a paragraph.

1. The ask is a decision, not a feeling. Name what you want approved, who you want pulled

in, or what resource you need. If the reader cannot act on it in one step, it is too vague.

1. Impact is in business terms. Dollars, renewal, reference, contract — not "the customer

is upset". Keep it out of the What-Happened facts; it is its own block.

1. Every escalation names an owner and a next update. A leadership brief with no owner or

no "next update by" is unfinished. If a value is unknown (exact ARR, dollar impact), write "unknown" — never invent a number.

Worked example

Situation notes (input): > Our biggest logistics account, ARR around $480K, renewal in about two months. Their production > integration has been down since yesterday afternoon — our webhook change broke their order sync. > Eng confirmed it's our regression. The customer's ops lead is furious and mentioned they have a > board review Friday. I think we need an exec to call their VP and probably a service credit. > I'm coordinating with eng on the fix.

BEFORE (base default — apology first, ARR buried, vague ask, no owner/next-update): > Wanted to flag a tough situation. I'm really sorry to be raising this — our biggest logistics > customer has had their integration down since yesterday because of a change on our side, and > they're quite upset, especially with a board review coming up. Renewal is coming and it's a big > account. Please advise on how you'd like to handle this. Let me know your thoughts.

AFTER (this format): > Account & Severity — Logistics account (largest), ARR $480K, renewal in ~60 days. Sev-1. > > What Happened > - Their production order-sync integration has been down since yesterday afternoon. > - Root cause is our webhook change; engineering has confirmed it is our regression. > - Customer's ops lead has a board review this Friday. > > Business Impact > - $480K renewal (60 days out) is now at risk. > - Outage lands directly before their board review, raising executive visibility. > > The Ask > - Approve a service credit for the outage (proposing one month). > - Have an exec call their VP today to get ahead of the board review. > > Owner & Next Update — Owner: me (account), with Eng lead on the fix. Next update by 5pm today.

Edge cases

• Relationship escalation, no outage. Same five blocks. What-Happened carries the relationship

facts (champion left, threatening to churn); severity is your judgment (high/critical).

• ARR or dollar impact unknown. Write "ARR unknown — confirming" in the header rather than

guessing. The blank is honest; a made-up figure is the failure.

• You already fixed it. If it is resolved and needs no decision, this is not an escalation —

it is a postmortem or an FYI. Do not force it into this form.

• Notes are a paragraph. Restructure into the five labeled blocks; do not keep the prose. The

worried paragraph is the exact default this format replaces.

• Multiple asks. List each ask on its own line, each individually actionable. Do not merge

them into one sentence.

Do / Don't

• Always lead with the header line: account, ARR/value, severity — before any narrative.
• Always write one binary claim per line, not compound or hedged sentences.
• Always make the ask a specific decision, approval, or resource leadership can act on.
• Always end with a named owner and a committed next-update time.
• Never open with an apology or a backstory paragraph.
• Never bury or omit the ARR / dollar value and the severity.
• Never soften the ask to "please advise" or "let me know your thoughts".
• Never invent an ARR or an impact number the notes do not give — mark it unknown.

Common mistakes (the base's wrong defaults)

• An apologetic or narrative opening instead of the account + ARR + severity header line.
• The dollar value and severity missing or buried three sentences in.
• Impact written as "the customer is upset" rather than dollars / renewal / reference at risk.
• The ask softened to "please advise" — nothing the reader can approve or deny in one step.
• No owner named and no next-update time — the brief just trails off.
• Facts, impact, and ask blended into one paragraph instead of separate labeled blocks.