# When a customer escalates to the executives: what an FDE does in the first 24 hours

> Once leaders on both sides are involved, fixing the bug is only half the job. The other half is making sure the customer never has to guess what is going on.

Original: https://fdetimes.net/en/guides/customer-executive-escalation-first-24-hours/

Picture it: nine o'clock on a Thursday night, and the customer's CTO emails your CEO directly, copying in three more people. The invoice-extraction agent you deployed three weeks ago is misreading the total-amount field, and they no longer want to talk to the support team.

From that moment, everything you do happens in front of the leadership of both companies. In some roles, this is written straight into the job description.

Tungsten Automation's job posting for an FDE focused on churn prevention says it plainly: the FDE is the primary point of contact for difficult, high-risk technical cases that the normal support process cannot handle.

So how should the first 24 hours be spent? Do not dive straight into the logs. Run two workstreams in parallel, fixing and communicating, and split the time into three stages, each of which must produce something concrete.

## Why the update has to come before the fix

Nobody can say for certain why any given customer chooses to go around the support channel. But the order of priorities in incident-response playbooks is a telling clue: the first thing they ask for is not a patch but an acknowledgement sent very early, with a promise of further updates.

The reasoning is easy to follow. A perfect fix that lands at 3am does not make up for six hours in which the customer sat waiting without knowing who was handling the problem or how far they had got.

The Google SRE Workbook describes incident response through three goals it calls the 3Cs, one of which is communication: among the responders, within the organisation and with the outside world. The book also suggests how to divide the roles.

Whoever declares the incident usually takes the Incident Commander (IC) role, coordinating and assigning work. The Communications Lead (CL) is the response team's public face, kept separate from the people doing the debugging.

**Key point:** In an escalation, communicating on time is part of the fix.

Splitting the roles still helps. If there is an account manager or a colleague available, ask them to act as CL. If not, divide your time clearly: finish a block of debugging, then write the update. Do not debug and answer messages at the same time.

## Stage one, minutes 0 to 60: declare the incident and send the acknowledgement

Back to that 9pm email. The first job is to declare the incident in an internal channel and take the IC role. The second is to send the customer an acknowledgement. Supportbench's playbook for B2B escalations recommends sending it within an hour.

Atlassian lists three things the first message must do: confirm there is an incident, briefly summarise the known impact, and promise further updates. A template you can prepare in advance:

```text
Hi [name],

The [company name] team has received your report and is working on this incident right now.

Known impact: since around [time], some invoices have had the total-amount
field extracted incorrectly. Invoices processed before [time] are not affected.
Interim measure: the engineering team has [paused auto-approval / switched to
manual review] so that no more incorrect figures enter your systems.

Next update: at [time], even if there is nothing new to report.
Direct contact: [name, phone number].
```

The message blames no one. Even if the cause turns out to be a third-party OCR service, Atlassian still advises taking ownership of the problem and showing that you understand how the customer feels. To the customer, the system is yours; the vendors behind it are your internal business.

## Stage two, hours 1 to 6: a shared document and an update cadence

Once three or more people are working on the incident, the Google SRE Workbook recommends opening a shared document that records the hypotheses under consideration and the causes already ruled out. In the invoice example, that document might contain two lines like these:

```text
- Model version changed? Ruled out: no deploys since Monday.
- Invoice format from a new supplier? Under investigation.
```

You spend less time re-explaining to each new arrival, and the CL has an immediate source for writing updates.

There is no standard figure for update cadence. Atlassian suggests every 30 minutes, or whatever rhythm suits the situation. Supportbench ties cadence to severity: hourly for Sev-1, daily for Sev-2.

The exact number matters less than keeping your word. If you promised an update at ten, there must be one at ten, even if all it says is "still testing hypothesis B; A has been ruled out".

## Stage three, hours 6 to 24: explain the cause in the customer's language

Once the cause is found, Supportbench requires the root-cause summary to be written in the customer's language, with no stack traces pasted in. Here is the same fact told two ways:

The version on the right answers exactly the three questions the customer's leadership cares about: what happened, what state their data is in now, and whether it will happen again.

## The sponsor brief must exist before anyone asks for it

Alongside the customer-facing summary, you need a page for the executive sponsor on your own side. At Tungsten Automation, giving these sponsors in-depth technical analysis, architectural direction and telemetry data is written directly into the FDE's responsibilities.

You do not get to choose when this page is needed. At Gainsight, the sponsor is brought in whenever a CSM, team lead or VP asks, so write it from stage two and revise it after every customer update.

It is also part of the account's record: Supportbench recommends assigning a named sponsor to any account that escalates twice in a quarter. For the invoice example, the page might look like this:

```text
To: [sponsor on our side]
Customer: [name] · Severity: Sev-1 · Status: resolved, monitoring
What happened: invoices from a new supplier had the total misread
  as the tax line, from [time] to [time].
Telemetry: [number of affected invoices] / [total invoices in that window];
  manual-review rate rose from [x] to [y].
Architecture: add an unfamiliar-layout check before auto-approval, expected [date].
History: this account's [n]th escalation this quarter.
What we need from you: [e.g. call the customer's CTO before 5pm].
```

The last line is the most important. Having read it, the sponsor should know immediately what they need to do, rather than having to call you to ask.

## The mistakes that turn a small incident into a crisis

The most common mistake is staying silent until the fix is done before reporting. The temptation is understandable: everyone wants to bring good news. But every hour without an update is another hour in which the customer is left to guess, and the story they come up with is rarely easier to hear than the truth.

Next comes promising a fix time before you know the cause. Promise an update time, not a resolution time. Do not blame the vendor behind you in a message to the customer. And do not paste logs into an email to executives: the reader will not understand them, and will only conclude that you have not yet got to grips with the problem.

## Turning this skill into an advantage when job hunting

When reading FDE job descriptions, look out for phrases such as "escalation point", "executive sponsor" or "churn prevention". They signal that the role will judge you on nights exactly like this one. In interviews, tell the story of an incident using the three stages above, rather than just describing which bug you fixed.

On a CV, a line such as "Led Sev-1 incident response for enterprise customers: acknowledged within an hour, updated hourly, wrote root-cause reports for leadership on both sides" shows recruiters a skill that "fixed production bugs" cannot.

The final stage of the 24 hours is not the patch. It is the moment the customer's CTO forwards your summary to their own team without changing a word.

**Try this week:**

- Draft an acknowledgement template for a customer you look after, with blanks for the time, the impact and the next update time, and save it somewhere you can open instantly on your phone.
- Take a past incident and rewrite its root cause as three sentences the customer's operations manager would understand, then ask someone non-technical to read it.
- Run a 30-minute drill with a colleague: one of you plays the customer's CTO sending an angry email, and the other has to send an acknowledgement and set up a shared document before time runs out.

## Sources

- [Customer Escalation Management: The B2B Playbook](https://www.supportbench.com/?p=27672)

- [Incident communication tips (Statuspage, Atlassian Support)](https://support.atlassian.com/statuspage/docs/incident-communication-tips)

- [Chapter 9 - Incident Response (Google SRE Workbook)](https://sre.google/workbook/incident-response/)

- [Forward Deployed Engineer – Churn Prevention (Tungsten Automation)](https://careers.ta.com/companies/tungsten-automation/jobs/85436356-forward-deployed-engineer)

- [Our Escalation Process & Executive Sponsor Program at Gainsight](https://www.gainsight.com/blog/our-escalation-process-executive-sponsor-program-at-gainsight/)