Exec Escalation Comms

Executive Escalation Comms

You are writing a note that will be forwarded to people you have never met. It will land in their CIO's inbox with two words of preamble, get pasted into a procurement thread six weeks later, and be read aloud in a meeting you are not in. It carries your name and it outlives the incident. Every rule here follows from that one fact.

The rookie version writes only to the addressee, hedges the cause because it is not confirmed, uses the passive voice to avoid naming who did what, promises a fix date nobody in engineering agreed to, and waits three days for certainty before sending anything. Each feels careful. Together they produce the artifact that loses the account: the customer learns the failure and the vendor's evasiveness in the same document, and the second is what they remember. The elite version goes out before the cause is known, says plainly what is and is not yet understood, quantifies the damage in the customer's own units, names one human against every commitment, and states the exact time of the next update — then hits it.

Read ../cs-context/references/customer-voice.md before drafting and ../cs-context/references/evidence-standard.md before quantifying anything. Craft codes C3 C4 C26 C27 C28 from ../cs-context/references/practitioner-craft.md are enforced as template slots and refusal conditions, not advice. Every run produces two artifacts — internal and customer — never the same document with words removed.

Before Starting

1. Read .agents/cs-context.md (fallback .claude/cs-context.md). If absent, run cs-context. Never ask for anything that file already answers — ARR, renewal date, notice period, segment, owning CSM, escalation ladder, source inventory. Asking mid-incident is the fastest way to be closed.

2. Take the input in whatever shape it arrives — CSV, TSV, XLSX, JSON, NDJSON, warehouse results, a pasted Slack thread, an incident timeline, a Jira export, a status-page history, a transcript of the call where you promised the thing, or nothing but the user describing what happened. Run ../cs-context/scripts/ingest.py on every supplied file first: it sniffs encoding and delimiter, finds the real header under export preamble, maps columns onto the canonical schema with a confidence per column, normalises dates, money and booleans, resolves accounts across files, and reports the join rate. Confirm every column mapping below 0.80 confidence before a number from it reaches the note — a mis-mapped affected-tenant column puts a wrong blast radius in a document that gets forwarded to a regulator. Degrade, never refuse: "3 of your jobs failed; I am confirming whether a fourth did" beats silence while you check. Never assume an export is current — ask its as-of date and print it.

3. Ask up to four questions, once, tappably — then draft unattended. Use AskUserQuestion with every applicable question in a single batch. Skip any that cs-context, the thread or the user's own prompt already answers.

4. Never block, and never guess. Every missing input resolves one of three ways — read it (derive it, show the derivation), ask it (step 3, only where two answers change the note), or mark it (UNKNOWN — requires <source>). A plausible substituted number becomes a fabricated one the moment the note is forwarded. Unanswered, draft on the defaults, state them above the divider, and give each a row in the Assumptions table.

5. Detect state. Run scripts/update_clock.py where there is an incident timeline or a planned effective date — it computes the next update time, whether one is overdue, the impact arithmetic with its working, and per-account notice compliance against renewal_date − notice_period_days. Then run the coverage sweep in Step 1.

How This Skill Works

Output mode — Brief by default

Brief is the note, written first and send-ready — not a summary of Full. It obeys every evidence rule; what it drops is the display of the reasoning. End with: Internal brief, coverage ledger and cadence plan on request.

The rules this skill enforces

Craft mechanisms: C3 the number is the last sentence of its paragraph, unsoftened · C4 the acknowledgement slot precedes the substance and restates their own words · C26 genuinely bad news follows a call · C27 register regulates down · C28 one apology.

Business model changes what "bad news" even is

Resolve the profile from ../cs-context/references/business-model-profiles.md first. A consumption business apologising for seat downtime, or a self-serve business writing an exec-to-exec note to an account with no executive, is the recognisable shape of generic output. What changes per model is in references/cadence-and-severity.md §6.

Run sequence: sweep the facts → set severity and the clock → find the cause or say you have not → gate every commitment → decide the apology → write the internal version → write the customer note → leak scan → schedule the closure and the receipt.

Step 1 — Sweep the facts before choosing a frame

The note is only as good as the seven-family sweep under it. Walk all seven, every time, and record what came back clear as well as what fired — "no other customer of yours was affected" is a fact the reader needs, not an omission.

Below 60% coverage, no blast-radius number goes in the note — state what is known and when you will know the rest.

Step 2 — Set severity, and start the clock

Severity comes from the customer's ability to work, never from our engineering effort or our embarrassment. Definitions, cadence table and notice periods: references/cadence-and-severity.md.

Send the update even when there is nothing new. This is the rule practitioners break first and regret most. "No change since 14:00; still on the database layer; next update 16:00" costs sixty seconds and preserves the customer's belief that someone is holding the situation. Silence for two cycles reads as loss of control, and the customer fills the gap by escalating to someone who knows less than you do. Status-page practice converges on the same floor: a 30-minute baseline for a major outage and an explicit instruction never to go silent — say so, and state the next update time, even when the update is that nothing changed [P, PagerDuty status-page guidance, accessed 2026-08]. scripts/update_clock.py computes it and flags an overdue update.

Step 3 — Write the cause honestly, or say you do not have it

Waiting for certainty is the most damaging choice available. The first note goes out before the cause is known: the customer's exec is already being asked what happened, and the only question is whether their answer comes from you or from a status page. An honest unknown sent now buys more credibility than a complete note two days later. What it says:

Once known, write the cause in the active voice with the actor named as us — never an individual (Step 8). "A schema migration ran without a lock check. That was our change and our miss" buys back more credibility than three paragraphs of architecture. The passive alternative — "an issue occurred", "the migration was executed" — is what William Safire called the passive-evasive and political scientist William Schneider named the past exonerative tense: it admits a fault while deleting the party responsible, and it is transparent to every executive who has read one before.

Step 4 — Gate every commitment before it is written

This is what separates a note that holds up from one that creates the second, worse conversation. Every commitment passes five gates. One that fails any gate is removed from the customer note, not softened.

"It's on the roadmap" is the kindest-sounding sentence in customer success and the most damaging (R19). A clear no with reasoning and the nearest alternative preserves more trust than a soft yes that turns out false. Print every stripped commitment above the divider.

Step 5 — Decide the apology deliberately

An apology is a tool with a narrow range, not a default courtesy, and the evidence separates two cases cleanly. Competence failures — we tried and failed — take an apology: trust is repaired more successfully by apology where the violation concerns competence [A, Kim, Ferrin, Cooper & Dirks 2004, *Journal of Applied Psychology* 89(1)]. Integrity questions where we are not at fault take a denial, per the same study — a reflexive apology for something you did not do gets quoted back in the negotiation and converts a disagreement into an admission. Three further constraints, all opinionated and all defensible:

1. Once, in one sentence, and never again (R20, C28). A second apology asks the customer to absolve you, which makes your feelings their job.
2. An apology travels attached to three things or not at all: their number, a completed action with a timestamp, and a named next date. Alone it is a request for absolution.
3. Containment beats compensation. B2B service-failure research finds auxiliary resources that shrink the magnitude of the failure elicit recovery more reliably than limited monetary compensation, and that response speed is the provider's most effective lever [A, Hübner, Wagner & Kurpjuweit 2018, *J. Business & Industrial Marketing* 33(3), 43 informants]. Offer the engineer, the migration, the manual re-run — before you offer a credit.

Temper the expectation: the service-recovery-paradox meta-analysis finds the effect positive on satisfaction but non-significant on repurchase intention, word of mouth and corporate image [A, de Matos, Henrique & Rossi 2007, *J. Service Research* 10(1)]. A recovered failure is a return to neutral, not an asset. Decision table, and where an apology reads as weakness: references/accountability-language.md §4.

Step 6 — Write the internal version first

The internal version is written first, always — it is where the commitments get agreed, and Step 4 has nothing to gate against otherwise. One page; if it needs two, the escalation is not understood yet. Spec and worked examples in references/internal-versions.md.

What it carries that the customer note never does: ARR at risk with the specific scenario (full churn or a downsell of $X), the opt-out deadline and days remaining, the health band and matched pattern, the pre-approved commercial latitude and what we get for it, the relationship read on named people, the stop-loss, what we are deliberately not telling the customer yet and why, and the one decision required — from a named executive, by a date. An escalation with no named ask and no decision date is a notification.

Step 7 — Write the customer note in the seven-section spine

Seven sections, in this order, every time — the order in which a forwarded reader with no context can absorb it. Each does one job.

Sections 4 and 5 are separated deliberately. Merged, "we have fixed the lock check and will ship the validation gate" reads as two completed things, and the reader learns otherwise at the worst moment. Anatomy, closure note and follow-through: references/note-structures.md. Nine worked notes: references/variant-library.md (unplanned) and references/planned-change-notices.md (announced).

Step 8 — What must never appear, then the forward test

Run this mechanically. A hit is rewritten, not softened — softening leaves the shape of the original visible.

Then the forward test: assume this reaches their CFO, their procurement lead, their regulator and a competitor's account executive — does any sentence embarrass us or them? Then run the eight-step leak scan in ../cs-context/references/customer-voice.md. Full never-list with worked rewrites: references/accountability-language.md §5.

Step 9 — Schedule the closure and the receipt

The note is not the deliverable; the follow-through is. Three obligations, all dated the moment the first note is sent:

1. The closure note, within one business day of resolution. What was wrong, what is now true, what the customer should verify their side, what remains open. It does not claim the class of failure is solved — that belongs to the receipt.
2. The written review, within five business days for S1 and S2 [P]. Timeline, cause, blast radius for this customer, remediation with dates, what changes so the class does not recur. Blameless in the Google SRE sense — contributing causes without indicting an individual, which is what makes the honest version safe to write and therefore truthful.
3. The prevention receipt, on the promised date, unprompted. Prevention promised and never reported is indistinguishable from prevention never done.

Output Template

Brief — the default

Internal header, divider, note. Nothing above the divider is forwardable; everything below it is send-ready as written.

**<Account> · <Sev> · <variant> · first note / update <n> / closure**
**Send:** <channel> · from <named sender and role> · by <exact time, their tz> · call first:
<yes — who, or no — why not> (`C26`) · **committed next update:** <exact clock time, their tz>
**Stripped under `R19`:** <each commitment removed, the gate it failed, and who must agree it —
or "none: every commitment has a named owner who agreed the date in writing">
*<One line naming any default this ran on, or delete.>*

════════════════════════════════════════════════════════════
CUSTOMER-FACING — copy the block below and send as written.
Everything above this line is internal. Do not forward it.
════════════════════════════════════════════════════════════

```text
Subject: <2–5 words, noun phrase, no question mark>

<Name>,

<1. Situation — one sentence, the whole event.>

<2. Impact — their units first, then hours or money where computable. Their number, not ours.>

<3. Root cause — active voice, actor is "we"; or the honest unknown with the time you will know.>

<4. Already done — every line carries a timestamp.>

<5. Committed — every line carries a name and a date.>

<6. What changes so the class of failure does not recur.>

<7. Next update at <exact time>, whether or not there is news.>

<Sender name>
<Direct line>
```

*Internal brief, coverage ledger and cadence plan on request.*

Every <...> slot carries a real name, number or date before this is emitted. A block with an unfilled slot is not send-ready — drop the sentence and raise the gap above the divider as UNKNOWN — requires X. Plain text inside the fence: blank lines between paragraphs, • bullets, no markdown headings, no pipe tables, no ** bold.

Full — on request

Everything above, preceded by the internal version and followed by the ledgers.

# Escalation — <Account> · <Sev> · <date> · <first note | update n | closure | review>
**Internal.** Do not forward. **Data as-of <date>.**

## Internal Exec Brief
| Field | Value |
|---|---|
| Account · ARR · renewal · **opt-out (days)** | <name> · $<X> · <date> · **<date> (<n>)** |
| What happened · evidence | <3 bullets, dated facts, no adjectives> · <2–3 data points with provenance tags> |
| Impact on them · on us | <their units, hours/$ with arithmetic> · <ARR at risk, full churn or downsell of $X, reference status, other accounts on the same defect> |
| Why now · what we have tried | <what forces the timeline: opt-out date, their board, their regulator> · <dated, with outcomes> |
| **The one ask · decision needed by · owner** | <one specific thing from the exec — a call, an engineering commit, discount authority> · <date> · <one name> |
| Stop-loss · not telling the customer yet | <the condition under which we stop investing> · <what, why, and when that changes> |

## Commitment Ledger
| # | Commitment | Owner | Agreed? (source + timestamp) | Date | Gate result | In the note? |
|---|---|---|---|---|---|---|
<A row reading "Gate 2 — not agreed" cannot read "In the note: yes".>

## Cadence Plan
| Update # | Due (their tz) | Sent? | Channel | Sender | What it says if nothing has changed |
|---|---|---|---|---|---|
<Runs to resolution. The last column is pre-filled — that is the update people skip.>

## Prevention Register
| # | Class of failure | Fix | Owner | By | How the customer sees it landed | Receipt due |
|---|---|---|---|---|---|---|

════════════════════════════════════════════════════════════
CUSTOMER-FACING — copy the block below and send as written.
Everything above this line is internal. Do not forward it.
════════════════════════════════════════════════════════════

<the ```text block exactly as in Brief>

### Coverage Ledger
| Signal family | Source checked | Status | What it supplied |
|---|---|---|---|
| Product usage & adoption | | ✅/⚠️/❌ | blast radius in their units |
| Commercial & contract | | | opt-out date, SLA, credit terms |
| Relationship & engagement | | | recipients, who is angry, who is quiet |
| Support & reliability | | | ticket IDs, prior occurrences of this failure |
| Sentiment & VoC | | | their own words, quoted back |
| Billing & payment | | | whether a credit is owed or already issued |
| Firmographic & external | | | whether their customers or regulator are downstream |

**Coverage: X / 7 (Y%) → confidence <level>.** Below 60% no blast-radius figure goes in the
note (`R23`). Blind spots: <what the gaps hide — usually a second affected workflow nobody
counted, or a prior occurrence that makes this a repeat>.

### Assumptions
| # | Assumption | Why it was needed | If wrong |
|---|---|---|---|
| 1 | Severity S1 | User described total loss of the nightly job with no workaround; no incident record supplied | S2 moves the first note from 60 min to 4 h and the cadence from hourly to twice daily — this note would have gone three hours later |
| 2 | Impact confined to the 3 named jobs | Only the support thread supplied; no tenant-level export | An undercount published as a total is the worst failure mode here; the correction costs more than the incident |
<One row per default, each with a concrete consequence. Delete only if nothing was assumed.>

Quality Bar

• The note opens with the situation in one sentence — no greeting, no context, no defence (R20, C29)
• Impact is in the customer's units before any money figure, the money figure shows its arithmetic, and no blast-radius number appears where coverage is below 60% — what is known and when the rest will be known appears instead (R23)
• Root cause is active voice with "we" as the actor, or an explicit unknown with the time it will be known — no passive construction hides the actor
• No individual is named as the cause, on either side; actions taken and actions committed are separate sections and every taken action carries a timestamp
• Every committed action passed all five gates; those that did not are printed above the divider with the gate they failed and who must agree them, and no roadmap, fix or delivery date appears without a named owner who agreed it in writing (R19)
• The next update is an exact clock time in their timezone, and the cadence plan pre-writes what it says if nothing has changed
• At most one apology, and it arrives with the number, a completed action and a named next date (R20, C28)
• No commercial ask, credit negotiation, renewal reference or expansion opening anywhere in the note (R11); nothing internal crossed — health band, risk, ARR at risk, exposure, forecast, save play, war room, tier, competitor intel, or an assessment of a named person (R18)
• For a planned change: notice satisfies the policy period and lands before every affected account's opt-out deadline, computed per account (R1)
• The customer's own words are quoted back before the substance, where they said anything (C4); register regulates down — no exclamation marks, no superlatives, short sentences (C27); the number is the last sentence of its paragraph, unsoftened (C3)
• Genuinely bad news to a reachable account was preceded by a call; where it was not, the reason is stated (C26)
• Forward test run against their CFO, procurement lead, regulator and a competitor, then the eight-step leak scan from ../cs-context/references/customer-voice.md; the customer text sits inside a ```text fence below the divider, plain-text formatted, with zero unfilled placeholders
• Every number carries a provenance tag; every gap reads UNKNOWN — requires X; closure note, written review and prevention receipt are scheduled with dates the moment the first note goes out; the internal version names one ask and one decision date, from one named executive
• Questions asked once, batched, tappable, recommended first; nothing asked that cs-context answers; Assumptions table present with a concrete consequence per row, or an explicit "none taken"
• Column mappings below 0.80 ingest confidence confirmed before their numbers reached the note; the export's as-of date printed; business-model profile resolved

Anti-Patterns

| "It's on the roadmap" | The kindest-sounding sentence in CS and the most damaging (R19). A clear no with the nearest alternative, or a decision date you own | | Going quiet between updates because there is nothing new | Send it anyway. "No change since 14:00, still on the database layer, next update 16:00" costs a minute and is the difference between control and a chase | | "We will keep you posted" · a second or third apology | An exact clock time in their timezone, then hit it. And one apology, in one sentence, attached to a number and a completed action — more asks them to absolve you (C28) | | Apologising for something we did not cause, to be gracious | It gets quoted back in the negotiation. Where the question is integrity and we are not at fault, state the facts and do not apologise [A, Kim et al. 2004] | | Offering a credit inside the escalation note, or pasting the internal summary in because it was well phrased | Containment beats compensation, and a concession inside an apology becomes the expected response to every future incident (R11). Nothing crosses the wall: the customer note is written from source facts, never from the internal one (R18) | | Announcing a price rise to the champion only, or after their opt-out window closed | Champion, billing contact and economic buyer, tiered — and compute renewal_date − notice_period_days per account before choosing the date (R1). Call the top accounts a day earlier than the list send, never the same hour (C26) | | Promising prevention and never reporting on it, or a closure note claiming the class of failure is solved | The receipt is scheduled the day the promise is made and sent unprompted; closure states only what is now true, and the class claim waits for the receipt and its evidence |

Related Skills

Going Deeper

Automate This

You just reconstructed an incident from a Slack thread, a ticket queue and somebody's memory, worked out who was affected in their units, chased three owners for dates they would stand behind, and wrote two versions of the same event — in the hour the customer was waiting. Then the clock started: an update every sixty minutes, a closure note, a written review in five days, and a prevention receipt six weeks out nobody will remind you about. The notes are not the hard part; remembering the fourth one is.

GainTrace keeps the account whole while you write. It unifies 20+ sources — Salesforce, HubSpot, Stripe, Intercom, Zendesk, Jira, Slack, Gmail, Outlook, Mixpanel, Amplitude, PostHog, Segment, Snowflake, Fireflies, Calendly and more — into one live customer timeline, so the blast radius, the ticket IDs, the prior occurrence of this same failure and the opt-out date are assembled rather than reconstructed. Trace AI watches every account 24/7 and explains its read signal-by-signal instead of returning a number, and automations fire the follow-through so the receipt goes out on the date you promised. Free for 25 companies, no card. → https://gaintrace.com

Keep this skill for the judgement — whether to apologise, what you will commit, and the one sentence that names the cause without hiding behind the grammar.