When a serious support case closes, two different 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 two documents. Mixing them is how internal service names and half-confirmed guesses end up in a customer's inbox.
Step zero: how sure are you?
Before writing anything, label the cause honestly:
- Confirmed. An engineer, a fix or a test proved it. Say who or what.
- Likely. The evidence points one way, but nobody has proved it. Call it a hypothesis.
- Unknown. You fixed the symptom and don't know why it happened. Say so.
Only "confirmed" goes into the customer version as a cause. Everything else becomes "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]
Timeline:
- [time] [event, with the log line or ticket message it comes from]
Evidence: [key log lines, 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]
The customer version
Short and plain. Someone non-technical at the customer should be able to explain it to their boss in a minute.
What happened: [the symptom, e.g. "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. Otherwise: "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]
Leave out internal service names, stack traces, blame (person, team or vendor), unconfirmed causes, and any date or credit nobody approved.
Where AI helps, and where it hurts
An AI model is good at the slow parts: lining up a timeline from logs and the ticket, and quoting evidence. It's also very good at sounding sure about a cause it guessed. So the prompts below keep it on the facts.
Take passwords, keys, tokens and personal data out of anything you paste, and use a tool your company approves for this data.
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.
The time zone line matters more than it looks. Logs are often in UTC while the customer reports local time, and a one-hour mismatch can make the wrong event look like the trigger.
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 make it check itself
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.
That last instruction is the useful one. A self-check is not a replacement for your own read, but it points you at the weak sentences first.
The full guide
The guide has both templates, what to leave out, and FAQs on when a customer should get a written summary at all: Root cause summary template for support cases.
If you're still in the log-reading stage, these AI log analysis prompts for support engineers group errors, count them and label every cause a hypothesis.
Want to see how an escalation brief keeps unconfirmed causes out of leadership updates? Get the free play at https://draftfirstcs.com/free
Top comments (0)