Home / Guides / Escalations and support operations

A root cause summary for support cases: an internal version and a customer version

By Draft First. Updated October 2026

When a serious case closes, two people want to know what happened. Your own team wants the full story so it doesn't happen again. The customer wants to know what broke, whether it's fixed and whether they can trust you. Those are different documents. Mixing them is how internal service names and half-confirmed guesses end up in a customer's inbox.

First: how sure are you?

Before you write either version, label the cause honestly.

• Confirmed. An engineer, a fix or a test proved it. Say who or what confirmed it.
• Likely. The evidence points one way, but nobody has proved it. Call it a hypothesis.
• Unknown. You fixed the symptom but don't know why it happened. Say so.

Only "confirmed" goes into the customer version as a cause. Everything else is "we're still confirming".

The internal version

Case: [ID] | Customer: [account] | Severity: [level]
Window: [start] to [end] [time zone]

What the customer saw: [the symptom, in their words]
Impact: [who was affected and for how long, from the ticket and logs]

Timeline:
- [time] [event, with the log line or ticket message it comes from]
- [time] [event]

Evidence: [the key log lines or data, quoted exactly]
Cause: [what happened] | Status: [confirmed by X / hypothesis / unknown]
Ruled out: [what you checked and why it isn't that]
Fix: [what changed, and when it reached the customer]
Prevention: [change] | Owner: [name] | Due: [date]
Still open: [questions nobody can answer yet]
Help article needed? [yes / no, and which]

The customer version

Short and plain. A non-engineer at the customer should be able to explain it to their boss in a minute.

Subject: What happened with [the symptom] on [date]

Hi [first name],

Here's a summary of the issue your team hit on [date].

What happened: [the symptom, like "Scheduled exports failed between
9:20 and 10:05 AM UTC."]
Who was affected: [your account only / accounts using X]
Why: [one plain sentence, only if confirmed. If not: "We're still
confirming the cause and will update you by [day]."]
What we did: [the fix, and when things were back to normal]
What we're changing: [only changes that are agreed and owned]

I'm sorry for the disruption to [what it affected for them]. If you
have questions, reply here and I'll get you answers.

[your name]

What to leave out of the customer version

• Internal service names, stack traces and ticket numbers from other systems.
• Blame, whether it's a person, a team or a vendor.
• Causes that aren't confirmed.
• Dates, fixes or credits nobody has approved. "We're adding monitoring" is only fine if someone owns it.

AI prompts that keep it honest

An AI agent is good at the slow parts: lining up a timeline from logs and the ticket, and quoting the evidence. It's also good at sounding sure about a cause it guessed. These prompts keep it on the facts. Take passwords, keys, tokens and personal data out of anything you paste, and use a tool your company approves.

Build the timeline

Build a timeline of what happened between [start] and [end] in
[time zone], using these log lines and the ticket. One line per event:
the timestamp, then the exact log text or ticket message it comes from.
Tag any timestamp with no time zone as [CONFIRM]. Don't add events
that aren't in the logs or the ticket.

Draft the internal summary

Using the timeline and the case notes, fill in this root cause summary:
[paste the internal template]. Quote evidence exactly. Label every
cause Hypothesis unless the notes say who confirmed it. Leave a field
as [UNKNOWN] rather than guessing. This is a draft for me.

Write the customer version, then check it

Rewrite the internal summary as a short note for the customer using
this structure: [paste the customer template]. No internal names, no
blame, no unconfirmed causes, and no promises of dates or credits.
Then list every statement in your note that isn't supported by the
internal summary. Don't send anything.

If the case still needs log work, start with the AI log analysis prompts. If leadership needs a summary while it's still open, use an escalation brief instead.

Questions

What if we don't know the root cause yet?

Say so. Write what you know, what you've ruled out and what you're still checking. A guess that turns out wrong costs more trust than an honest note that you're still confirming.

Should the customer get the internal version?

No. Write a separate customer version: what they saw, how long, why in plain words, what you fixed and what you're changing. Leave out internal names and blame.

Can AI write the root cause analysis?

It can build the timeline, quote the evidence and draft both versions. It shouldn't decide the cause. Have it label each cause a hypothesis until an engineer or a test confirms it.

When should a customer get a written root cause summary?

When they ask for one, or when the impact was big enough that they'll need to explain it to their own leadership. Follow your company's policy on what can be shared.