Escalation Playbook

Three escalation lanes

Escalations aren't a single channel. They route to different people for different reasons. Knowing the right lane keeps escalations from feeling like "FDE flailing" and turns them into "FDE doing professional ops hygiene."

Platform escalation

For: "the platform doesn't do X and the customer needs it" or "extraction quality on this layout class is structurally bad" or "we found a bug."

Routes to

• Platform PM (for product-shaping requests).
• Engineering lead (for bugs / regressions).
• Sometimes a vertical owner (e.g., "owner of the SAP integration") for system-specific issues.

What to include in the write-up

1. Customer impact. Which customer, what use case, how visible to them.
2. Concrete evidence. Sample documents, failed extractions, accuracy metrics. Not "this seems wrong" — specific exhibits.
3. What you've tried. Workarounds attempted, why they didn't work or aren't sustainable.
4. What you need. A bug fix? A feature? A doc? A new model version? Be specific.
5. Timeline urgency. Customer expectation date and what slips if it's missed.
6. What you can do in the meantime. Workarounds, temporary HITL coverage, scope adjustment — so platform knows the deployment isn't entirely blocked.

The pattern

Platform escalations work best when they come with a customer-evidence narrative. "Customer X says feature Y is broken" is weak. "Customer X's 2018 supplier contracts (sample attached) all extract effective_date wrong because the layout is rotated 90° and the parser doesn't detect rotation — see screenshots" is strong. The second one becomes a JIRA ticket; the first becomes Slack noise.

Commercial escalation

For: scope changes, contract questions, customer-relationship friction, expansion opportunities, churn risks.

Routes to

• Account Executive (for scope, commercial questions, contract issues).
• Customer Success Manager (for relationship issues, advocacy, expansion).
• VP Sales (when the AE can't unblock).

What to include

1. The conversation. What was said, by whom, in what context.
2. Your read on intent. Is this a real request or a discovery question? Are they testing the waters or asking for action?
3. Commercial implications. Out-of-scope work? Different SLA? Premium tier?
4. Recommended response. What you'd say if you were the AE.
5. Your action while waiting. Are you stalling the customer or actively trying to figure it out?

The common case

"The customer asked for X." The AE needs to know:

• Is X in scope per working agreement? If yes, just do it.
• If not, is X small enough to absorb? Or does it warrant a scope-change conversation?
• If a scope-change conversation, what's the right framing — expansion, swap, deferral?

Don't decide unilaterally on scope changes. The AE owns the commercial frame; you own the technical inputs. Escalating to them isn't weakness — it's role discipline.

Leadership escalation

For: this deployment is at risk; this customer is becoming a reference risk; this account is structurally larger than the FDE function can support; we're learning something the platform direction should respond to.

Routes to

• FDE Lead / Manager (first stop).
• VP CX / VP Engineering (when the manager can't unblock).
• Executive sponsor on your side (when the customer-side escalation has to be matched in seniority).

What to include

Same as platform / commercial, plus:

• What's at stake strategically. Renewal value, reference value, segment learning, etc.
• The decision you're asking them to make. Be specific — "approve a temporary resource allocation" vs "give me air cover for a difficult conversation" vs "pause this deployment until X."
• What you've done already. Internal leadership doesn't want to be the first to hear about a problem; they want to be the last to hear about it after you've exhausted lower-altitude options.

The cadence

If a leadership escalation might be coming, foreshadow it. Mention the risk in your monthly internal report. Note it in 1:1s with your manager. By the time you actually escalate, leadership should already be aware of the shape — your escalation is then a request for action, not a surprise announcement.

The "escalate early" instinct

New FDEs hesitate to escalate because it feels like admitting failure. Senior FDEs escalate early and often, and treat it as professional hygiene.

Why early beats late

• Early is cheap. A 30-minute platform conversation in week 4 prevents a 3-week rework in week 8.
• Early preserves trust. When leadership hears about an issue from you proactively, they trust your judgment. When they hear from the customer, they question it.
• Early surfaces options. The earlier the conversation, the more options are still on the table — reshape, defer, swap resources, change architecture. Late conversations have fewer.
• Early models good behavior for the customer-side team. They see how you escalate professionally, and they do the same back.

The "I'm not surprised by what I'm telling you" rule

The signal a senior FDE sends in an escalation is: "I'm not surprised by what I'm telling you. I've been watching this. Here's where we are, here's what I've tried, here's what I'm asking for."

Internal leadership hears that and knows you're managing the situation. The opposite — "I just discovered this is a problem" in week 8 — is what damages your credibility, not the escalation itself.

Escalation write-up template

# Escalation: [Short title]
Lane: [Platform / Commercial / Leadership]
Customer: [name]
Drafted: YYYY-MM-DD by [name]

## TL;DR
One sentence. What's broken / needed / at risk.

## Customer impact
- Use case affected:
- How visible to the customer today:
- What happens if we don't resolve in [timeline]:

## Evidence
- [Specific artifact 1]
- [Specific artifact 2]
- [Link to docs / sample / dashboard]

## What we've tried
1. [Attempt]: [Outcome]
2. [Attempt]: [Outcome]

## What I'm asking for
Be specific. A decision, a resource allocation, a fix, a conversation.

## What I'm doing in the meantime
- Workaround / containment in place: [description]
- Customer expectation set: [what you've told them]

## Timeline
- Customer expectation date:
- What slips if we miss:
- My ask-by date for the escalation owner:

## Context
Anything else they should know.

Anti-patterns

Slack-as-escalation

"Hey, the customer is asking for X — can someone help?" in a channel is not an escalation. It's noise. Use the write-up template; put it in the right channel with the right people tagged.

Escalating without trying

If you haven't documented what you tried, your escalation looks like a tossed problem. Always have at least one attempted workaround.

Multiple escalations on the same item

Don't escalate to platform, commercial, and leadership simultaneously hoping someone responds. Pick the right lane. If you're unsure which lane, escalate to your manager and ask.

Surprise escalations

If your manager has never heard of an issue before reading your escalation write-up, you've missed steps. Foreshadow in 1:1s.

Holding the issue too long

Trying to figure it out yourself for "just one more week" is the most common failure mode. If you've been blocked for 5+ business days, escalate. The clock is more expensive than the embarrassment of asking for help.

✓ Check yourself

Answer from memory before opening each one.

1. A customer wants a new column that needs a platform feature, and also asks for a discount because of the delay. Which lanes do you use?

   Show answer

   Two: the platform lane for the feature and the commercial lane for the discount. Keep the write-ups separate, since the platform PM and the AE need different information, and the AE owns the commercial frame. See the three lanes.

2. Compare "Customer X says feature Y is broken" with a note that names the 2018 supplier contracts whose rotated pages break date extraction. What makes the second work?

   Show answer

   It has a customer, a concrete sample, a mechanism and what you tried, so it becomes a ticket rather than noise. If the same evidence sits in a shared folder, the platform PM can see how many deployments are affected. See platform escalation.

3. Before you escalate to leadership, what must already be true so that the message is "I'm not surprised"?

   Show answer

   You have foreshadowed the risk in your internal report and in 1:1s, you have tried at least one workaround, and you can name the decision you want. Then leadership gets a request for action, not a surprise. See leadership escalation.

4. You have waited eight business days for the customer's IT team to approve a service account. Which lane is this, and what goes in the write-up?

   Show answer

   Commercial, since it is customer-relationship friction, and over five business days is past the point to wait. Include the ticket history, what you tried such as a workaround account, the specific ask of the sponsor and the date you need an answer. See the write-up template.

5. Your manager says "give it one more week" on a blocker that is already five days old. How do you weigh that?

   Show answer

   Early escalation is cheap and keeps options open, while a late one has fewer. Agree a dated trigger in writing with your manager, note the cost of waiting, and escalate on that date. "One more week" is the most common failure. See the escalate-early instinct.

6. Why not send one blocker to platform, commercial and leadership at once to be safe?

   Show answer

   Each owner assumes someone else is acting and you create noise. Pick the right lane; if unsure, ask your manager which one. See anti-patterns.

Takeaway

• There are three lanes: platform for technical blockers, commercial for scope, contract and relationship issues, and leadership for strategic risk.
• A platform escalation works when it carries customer evidence, what you tried, what you need and the date that matters.
• The AE owns the commercial frame and you supply the technical facts; do not settle scope changes alone.
• A leadership escalation names the decision you need and is foreshadowed in earlier reports and 1:1s.
• Escalate early, because it is cheaper, keeps more options open and builds trust; a blocker over five business days is due.
• Use the write-up template, not a Slack message, and send each issue down one lane.

Everything so far assumes you will leave the deployment, and the next chapter shows how to do that well. → Handoff Checklist

Further reading

• Managing Incidents — Google SRE book, 2016. Roles and clear ownership during an incident, a guide to who decides and who is told.
• Emergency Response — Google SRE book, 2016. Cases of how engineers responded to real outages and what they learned.
• Incident Response — Google SRE Workbook, 2018. Practical incident-response guidance, including preparing and when to escalate.
• The Atlassian Incident Management Handbook — Atlassian, accessed 2026. A working handbook with severity levels and roles that you can adapt for customer-facing escalation.