DEV Community: Draft First

How to Write an Escalation Email Your Leadership Can Act On

Draft First — Wed, 28 Oct 2026 03:02:49 +0000

When a customer escalation needs a decision from your own leadership, send them a short email. Lead with the impact, the status, the owner and the specific decision you need, then the next update time.

If the email ends with "please help," leadership still has to work out what you're asking for.

Below is one escalation update, field by field, for a made up customer called Larkspur Labs whose EU dashboard is down. It's the internal email to leadership. The customer needs a different email: who owns the problem and when they'll hear next.

Subject line: customer, problem, ask

Use the form Customer | problem | need: ask. Name the customer, then the problem in a few words, then what you need.

Impact

Impact is what the problem means for the customer. In the Larkspur example, the impact line is "About 60 users can't see reports. Board report due Oct 16."

Account context, if you have it

If you have renewal or account context, like a renewal date or account health, add it as one line of facts. If not, skip it.

Status

Stick to what's confirmed right now: whether the cause is found, and whether anyone has committed to a fix date. Never guess at a root cause in writing. Until the cause is confirmed, say you're investigating.

If you do mention a suspected cause internally, call it a hypothesis and say who raised it. Search your draft for the word "because." If nobody has confirmed what follows it, rewrite the sentence.

Owner

Name who owns it. In the example, that's Dana on the platform team.

The ask

"Help" isn't an ask. Make the ask specific and dated: name the decision or the thing you need, and the date you need it by.

The Larkspur ask, "A committed fix date by Oct 13," names the thing and the date.

Next update

Give the next update time, like "Oct 13, 10am ET" in the example. Promise update times, not fix times, until engineering has committed to a fix. Same person, same time, every update.

The finished email

Here's the full made up Larkspur Labs email.

Subject: Larkspur Labs | EU dashboard down 5 days | need: A committed fix date by Oct 13

Hi Maria,

Impact: About 60 users can't see reports. Board report due Oct 16.
Account: Renews Dec 12, health Yellow.
Status: Root cause found, no committed fix date.
Owner: Dana, platform team.
Ask: A committed fix date by Oct 13.
Next update: Oct 13, 10am ET.

Thanks,
Sam

The next update is on Oct 13, the day the ask is due.

Copy this template:

Subject: [Customer] | [problem] | need: [ask]

[greeting, optional]

Impact: [what the problem means for the customer]
Account: [renewal or account context, or leave this line out]
Status: [what's confirmed right now]
Owner: [one person, their team]
Ask: [the specific thing you need, and the date]
Next update: [time and time zone]

[sign-off, optional]

For a big escalation, expand this into a full escalation brief.

If you'd rather fill in the fields and copy the result, this free escalation email generator writes the same format. It runs in your browser and nothing you type is sent anywhere.

Whichever way you write it, read the Ask line on its own before you send. It should name one specific thing and a date. If it still comes down to "please help," rewrite it.

The two-minute escalation brief: a copy-paste AI prompt for support leads

Draft First — Wed, 28 Oct 2026 00:00:26 +0000

Executives don't want the 60-message thread. They want to know the impact, where things stand, who owns it and what you need from them. When an escalation is open, that one page is what leadership reads, and it's the page that's hardest to write while you're also working the fix.

Below is a prompt that writes the first draft of that page for you. Paste it into ChatGPT, Claude, Gemini or whatever AI assistant your team uses, paste the thread and the ticket under it, and you get back a brief a VP can read in two minutes. You check it, then you post it. Everything you need is in this post: the prompt, what to fill in, a worked example and what to check before you send it on.

When to use it

When: on demand while an escalation is open, and again before each leadership update.
What to give it: the chat thread or email chain, and the ticket.
Who gets the draft: you. You post it to leadership after you've checked it.

The prompt

Copy this as it is. The two parts in square brackets are the only things you change.

Summarize the escalation below for a VP who has two minutes.
Use these headings, under 250 words in total:
Customer impact | Timeline | Current status | Owner | Next update | What we need from leadership
Then list open questions.

Convert every time to [your time zone] and show the day. If a time has no zone, or a label like CET that could mean summer or winter time, keep the original and tag it [CONFIRM].
Use only what's in the thread and the ticket. If the thread has a theory about the cause, label it "Hypothesis" and say who raised it. Don't state a root cause unless someone in the thread confirmed it.
Describe what happened, not who's to blame.
If a heading has nothing in the thread, write "Not in thread". Don't fill it in.
This is a draft for me. Don't post it anywhere.

Thread and ticket:
[paste the thread and the ticket here]

Fill in before you paste

[your time zone]: the one your leadership reads in, like ET. Threads often mix time zones, and that's where briefs go wrong.
[paste the thread and the ticket here]: the whole thread, oldest message first. If your agent can read your chat tool directly, name the channel and ticket number instead.

Why each line is there

Fixed headings and a word limit. Leadership gets the same shape every time, so they know where to look for impact and for what you need from them.
Times converted, odd ones tagged. A brief that says "17:30" when it meant "17:30 in Berlin" sends people to the wrong meeting. Anything the assistant can't convert for sure gets a [CONFIRM] tag for you to fix.
"Hypothesis" instead of a cause. Threads are full of guesses. The prompt keeps a guess labelled as a guess, with the name of whoever raised it, until someone confirms it.
"Not in thread" instead of filling gaps. An empty heading tells you what to chase before you post. A filled in guess hides it.
Draft only. Nothing goes to leadership until you've read it.

A worked example

Everything here is made up: the company, the people, the ticket and the numbers.

Here is a short thread you might paste in:

Ticket #1234, Acme Widgets, priority high

Mon 9:12 AM PT, Priya (Acme ops lead): Since this morning none of our warehouse staff can log in to the scanner app. Around 40 people are stuck. We ship at 2 PM.
Mon 9:30 AM PT, Sam (support): Thanks Priya, I can see the same thing on our side. Pulling in engineering now.
Mon 10:05 AM PT, Jordan (engineering): Started after last night's SSO certificate rotation, could be that.
Mon 10:40 AM PT, Jordan: Workaround: staff can sign in with the backup PIN login. Steps sent to Sam.
Mon 10:52 AM PT, Sam: Workaround sent to Priya.
Mon 11:15 AM PT, Priya: PIN login works for most people. A few still can't get in.
Mon 17:30 CET, Marta (engineering): Fix is ready, deploying after review.

With [your time zone] set to ET, the draft that comes back should look something like this:

Customer impact
Warehouse staff at Acme Widgets can't log in to the scanner app. About 40 people
affected (customer's estimate). They ship at 2 PM [CONFIRM], time zone not stated.

Timeline (ET)
Mon 12:12 PM  First customer report, ticket #1234
Mon 12:30 PM  Support confirmed the problem, engineering joined
Mon 1:40 PM   Workaround found: backup PIN login
Mon 1:52 PM   Workaround sent to the customer
Mon 2:15 PM   Customer: PIN login works for most staff, a few still locked out
Mon 17:30 CET [CONFIRM]  Fix ready, deploying after review

Current status
Workaround in place for most users. Fix ready, waiting on review before deploy.

Owner
Sam (support), Jordan and Marta (engineering)

Next update
Not in thread

What we need from leadership
Not in thread

Open questions
- How many staff are still locked out after the workaround? Nobody counted.
- Hypothesis (raised by Jordan): last night's SSO certificate rotation. Not confirmed.
- When will the fix deploy? Nobody gave a time.

Look at what that draft hands you before you post it. Two times need a human to confirm. Two headings say "Not in thread", so you need to set the next update time and decide whether you need anything from leadership. And the certificate rotation is still a theory, so nobody upstairs should hear it as the cause.

Check it before you post it

Look for the word "because". If the summary sounds more sure than the thread, that's usually where it happens. Assistants like to turn a hunch into a cause. Anything presented as a cause should be labelled a hypothesis.
No names in blame language. People's names belong under Owner, not next to what went wrong.
You post it, not the assistant.

Two ways to tune it

Paste in your own severity definitions, so "Sev1" means what it means at your company.
Ask for a second draft in plain language with no internal names. That's your starting point for the customer update, so you go into the next customer conversation with the same facts leadership has.

If you want this play as a 3-page PDF with the fill-in list, guardrails and a made-up sample result, it's free here: draftfirstcs.com/free.

Checking in email samples that give customers a reason to reply

Draft First — Tue, 27 Oct 2026 12:39:44 +0000

"Just checking in" is the email customers learn to skip. It asks for their time and gives them nothing back, so after the second or third one they stop opening it.

The problem usually isn't the wording. It's that the check-in has no purpose. When there's no rhythm behind it either, two things happen: the friendly customers hear from you every week, and the quiet ones don't hear from you until they cancel.

Below are seven checking in email samples that each carry a reason to reply, some subject lines, and a simple way to decide how often to send them. Swap in your own names and details. (Names in the examples are made up.)

Want a complete play you can run with an AI assistant? Get our free 3-page sample play.

The rule: every check-in needs a reason

A check-in earns a reply when it does one of these:

Asks about their side: what's changed, what's coming up.
Shares something from their account they'd want to know.
Saves them time with a tip that fits how they actually use the product.
Asks one question that matters, and makes it easy to answer.

If you can't name the reason before you write, don't send it yet.

Seven checking in email samples

1. The everyday check-in

For when there's no special news. Ask about their side, not yours.

Subject: Anything changed on your side?

Hi Ines,

What's changed on your side since we last talked? Anything coming up
in the next couple of months I should know about?

If something's getting in the way, tell me and I'll pick it up.

Theo

2. Proposing a regular check-in

Use this when you start working with an account, or when you set up a rhythm for the first time.

Subject: A monthly 20 minutes?

Hi Ravi,

I'd like to check in with you about once a month, 20 minutes, to make
sure you're getting what you need. If that's too often or not enough,
tell me.

Would the first Wednesday of the month work?

Theo

3. Sharing a result

Lead with one number from their account. Fill in the real figure; don't round it up.

Subject: Your [month] numbers

Hi Ines,

One number from your account this month: [the number and what it
means, in one line]. Thought it might be useful for your next team
meeting.

Is there anything you'd like us to focus on next quarter?

Theo

4. A tip based on how they use it

Only send this if you've actually seen something in their usage.

Subject: A quicker way to [the task]

Hi Ravi,

I noticed your team [what you saw in their usage]. There's a quicker
way: [the feature or setting, in one line]. Here's a short walkthrough:
[link].

Happy to show your team live if that's easier.

Theo

5. The quiet account

For the customer you haven't heard from in a while. Make the reply as small as possible.

Subject: Still getting what you need?

Hi Ana,

It's been a while since we spoke, and I want to make sure you're
still getting value. If anything's changed, like new people or new
goals, I'd like to hear it.

Would a short call be useful, or is email easier?

Theo

6. When they've said no to regular check-ins

Some customers don't want a monthly call. Agree a lighter touch and keep to it.

Subject: Once a quarter, then

Hi Marcus,

No problem at all. I'll send you a short email once a quarter instead,
and you can reach me any time in between if something comes up.

Theo

7. Following up when they don't reply

One question, and a yes or no is enough.

Subject: One quick question

Hi Ana,

Bumping this in case it got buried. Just one question: is anything
getting in the way for your team right now? A yes or no is fine. If
it's yes, I'll take it from there.

Theo

Subject lines that say why you're writing

Anything changed on your side?
Your [month] numbers
A quicker way to [the task]
Still getting what you need?
One quick question

"Just checking in" as a subject line tells the reader you don't have a reason.

If they say yes to a call

Keep it short and keep it to four questions:

What's changed on your side?
What's next for you?
Is anything blocking you?
What's one thing I can help with?

Afterwards, write down two things in your account list: the date of this last real conversation, and the next step. That list is what makes the rhythm below work.

How often to send a checking in email

A rhythm per tier works better than treating every account the same. Here's a starting point:

Tier	Who's in it	Check-in	Booked as
One	High value, or high need, such as a complex setup	A monthly call	A recurring invite
Two	Standard accounts	A quarterly call or email	A calendar reminder
Three	Small or self-serve	A monthly update email	A calendar reminder

A few notes on making it stick:

Tier by need, not just size. A small account with a complicated setup can belong in tier one. A big account that never needs help may not. Two or three tiers is plenty, and two if you have fewer than 30 accounts.
Check the hours. Add up what each tier's rhythm costs you in a month, with prep and follow-up. If it doesn't fit your calendar, the promise is too big.
Sort every Monday. Sort your accounts by the date of the last real conversation and reach out to anyone past their rhythm. Twenty minutes is enough.
Skip once, never twice. A quiet, happy account can miss one check-in. Not two in a row.
Risk means now. If a check-in turns up a risk, act on it. Don't wait for the next scheduled one.
If you keep falling behind, the rhythm is wrong for your hours. Lower one tier's rhythm and tell your manager, rather than quietly missing check-ins.

How do you know it's working? A starting target: no more than two overdue accounts in tier one for two weeks running.

Let AI make the Monday list

If your account list lives in a spreadsheet, an AI assistant can find who's overdue and draft the first lines for you. Use only a tool your company approves, and follow your company's data policy before you paste anything. Taking names out isn't always enough.

Here's my account sheet with tier and last real conversation date.
Today is [date]. Rhythm: tier 1 every [n] days, tier 2 every [n],
tier 3 every [n].
List accounts past their rhythm, sorted by how overdue. For each,
draft a two-line, friendly outreach message that doesn't sound
automated. Use only the sheet. Draft for me.
[paste sheet]

Read each draft and add the reason for writing yourself. That's the part an AI can't see in a spreadsheet.

Where to start this week

Delete "just checking in" from your templates, give every account a tier and a rhythm, and put the Monday sort in your calendar. That alone catches the quiet accounts before they go silent for good.

If you want to see a full play in this format, with its prompt, a fill-in list for every bracket, guardrails and a made-up sample result, the free sample is one complete play from The CS Agent Playbook: the Escalation Brief for Leadership, as a 3-page PDF. Get the free sample play.

How to respond to an angry customer: example replies and an apology email you can copy

Draft First — Thu, 22 Oct 2026 14:14:18 +0000

Here's an email that lands in a support queue at 4:50 on a Friday:

Subject: AGAIN??

This is the second time your sync has wiped our stock counts. I spent
my whole morning recounting two warehouses by hand. Nobody answered my
email on Tuesday. If this isn't fixed today I'm telling my boss we're
done with you.

And here are the two replies most of us want to send:

Reply A:
Hi, I understand your frustration. Could you send a screenshot of the
sync page so we can look into this?

Reply B:
Hi, we sincerely apologize for any inconvenience this may have caused.
We're so sorry for the trouble, we value your business, and we
apologize again.

Reply A asks for something and gives nothing back. Reply B says sorry three times and never says what went wrong or what happens next. Either way, the customer writes again, angrier.

A reply to an angry customer needs three things in it: a fact that proves you read their history, a name against the next step, and a time they'll hear from you. Here's how to write that, with example replies for the situations you'll actually meet. (Companies and people in the examples are made up.)

Step 1: Read the ticket before the tone

Before you type a word, pull three facts from the ticket record:

Contact count. How many times has this customer raised this, across every channel and every agent? Count it in the history. Don't rely on what they say.
Owner of the next action. You, another team (engineering, billing, the account manager), the customer, or nobody named yet.
Exposure. What do they lose, and when? A payroll run, a board meeting, their own customer's deadline.

In the email above: this is the second contact (Tuesday's email went unanswered), the fix sits with engineering, and the exposure is today.

Those facts pick the reply for you. A first contact you can fix yourself needs a different reply from a third contact stuck with another team. And if what they lose lands within two working days, treat the ticket one step more seriously than the count says: a first contact like a second, a second like a third.

Step 2: Swap "I understand" for the effect on them

"I understand your frustration" gets said so often in support that it reads as filler. Right before bad news, it can land as "no". Replace it with one sentence that names what this actually cost them:

You spent this morning recounting two warehouses by hand because of our sync.

Your team has been answering these customer emails one by one since Monday.

One sentence, then move on to the next step. A long paragraph of empathy feels like stalling. Watch for swaps that aren't really swaps: "I hear you" and "that must be frustrating" are the same filler with new words. If you can't name the effect yet, ask: "What has this meant for your team this week?"

Before you send, search your draft for "understand", "hear you" and "frustrat". Aim for zero hits.

Step 3: Pick the reply that fits what's true

When you got it wrong: the apology email

If the mistake is yours and you've confirmed it, the customer is watching to see whether you'll admit it. One specific apology plus action does more than three vague ones. The rules:

Apologize once. Name the mistake and its effect on them.
Say what you've already done, or what you're doing right now.
Mention a change to stop it happening again only if that change is real and confirmed.
Give the next step and a time you control.
Then stop apologizing. Saying sorry in every message starts to sound like you're managing them.

Example, after your team gave a wrong answer:

Subject: The setting we gave you on Monday was wrong

Hi Marta,

Our reply on Monday told you to switch off "Merge duplicates" to fix
the missing contacts. That was the wrong setting, and it cost your
team two more days of importing by hand. I'm sorry.

The setting you need is "Match on email" under Import options. I've
turned it on for your workspace and re-run last night's import, and
the missing contacts are back.

I'll check tomorrow morning's import by 10am and reply to confirm it
ran clean.

Joel

Refunds, credits and compensation follow your company's policy and your own authority. If you mention refund timing, confirm it with billing first. And if they won't accept the apology, don't repeat it. Say what you've done and what happens next, then stop.

When you don't know yet: four lines

Under pressure it's tempting to fill the gap with a guess, and guesses turn into promises. Instead, give them four short lines they can forward to their own team:

What you know.
What you don't know yet, and who is finding out.
What you're doing next.
What you can't do, if they've asked for it.

Then a time for the next update that you control. In email, make the four lines bold labels and put the update time in the subject line.

Here's a reply to the Friday email from the top. It mixes two moves: an apology for the part that's confirmed (nobody answered on Tuesday) and four lines for the part that isn't (why the sync broke).

Subject: Stock sync: next update from me by 2pm today

Hi Dana,

You spent this morning recounting two warehouses by hand, and your
email on Tuesday went unanswered. That second part is on us, and I'm
sorry.

What we know: last night's sync overwrote the counts for both of your
warehouses.
What we don't know yet: why. The engineers who own the sync are
looking at it now.
What I'm doing: I've sent them your account and both dates it
happened, and I'm keeping this ticket.
What I can't do: give you a fix time I'd be making up.

I'll update you by 2pm either way.

Sam

No "probably", no "should be sorted by end of day". If any of the four lines is empty, say so.

When they're wrong, and angry

You still have to correct them. How you do it decides whether you keep the relationship.

Start with the part they're right about, if there is one. State the correct fact once, without "actually" or "as I said", and show where it's written down: the invoice line, the audit log, the release note. Then help with what they were trying to do in the first place.

Hi Ben,

You're right that your invoice went up this month, and the notice
about it was easy to miss. The extra charge is for three seats added
on September 4. Here's the entry in your account's audit log: [link].

If you don't need those seats, I can remove them today so next
month's invoice goes back down. Want me to go ahead?

Priya

Notice it points to the record, not to the person on their team who added the seats. If they dispute the evidence, don't argue a second round. Offer to have someone else review it, and give a time.

The third email about the same problem

By the third contact, the process is part of the complaint. Read the whole history before you reply. Name it in your first line, take ownership by name, and give a date for the next contact that you control. Never ask them to explain it again.

Hi Omar,

This is your third message about invoices going to your old billing
address, and you've already sent the new one twice. I have it, and
I've updated it myself.

I'm keeping this ticket until your next invoice reaches the right
place. You'll hear from me by Wednesday at noon either way.

Leah
Your next update from me: Wednesday, by 12pm

Step 4: On chat or the phone, keep it short

Long angry story? Let them finish. Don't interrupt, even to help. Note their words for the key facts as they talk: what broke, when, what it cost them, what they've tried. Then play it back in two or three sentences, in their words, and end with "Did I get that right?" Only then start on the fix.

All caps in chat? Reply fast with a short acknowledgment and the first step you're taking. Keep each reply to two or three sentences with one question at most, and end with what you're doing next and when. Don't mirror the caps, and don't mention them.

Customer: WHY IS MY DASHBOARD EMPTY. I HAVE A MEETING IN 20 MINUTES
Agent:    I'm on it now. Checking your data connection first.
          Back to you in 5 minutes.
Agent:    Found it: the data connection was paused on Friday. One
          question: can you switch it back on, or should I send steps?

If you've found the cause but the fix will take a while, say so now, with the time you'll be back. Silence in chat reads as being dropped.

Language aimed at you? Swearing about the problem ("this stupid app") is frustration, so let it go. Insults or threats aimed at you get one calm warning that names the behavior and what happens next:

I want to help you get this fixed, and I can't continue if the language stays like this. If it does, I'll end the call and we'll follow up by email.

One warning, not three. After that, follow your company's policy.

Step 5: Phrases to drop, and what to say instead

Instead of	Try
"I understand your frustration."	The effect on them: "You've re-entered these orders by hand twice this week."
"We apologize for any inconvenience."	The actual mistake and what it cost them, once.
"Actually, that's not how it works."	"You're right that it changed. Here's where the setting is now."
"As I said in my last email..."	"To recap where we are:"
"That's another department."	"Our billing team needs to make this change. I've sent them the details and I'm keeping your ticket."
"It should be fixed soon."	"There's no fix date yet. I'll update you by Friday at 2pm either way."
"Calm down."	"I want to fix this. Let me check one thing and come straight back."
"Could you describe the issue again?"	Nothing. Read the history instead.

Step 6: Three checks before you send

Run these on every reply to an angry customer. If it fails any of them, it isn't ready.

Record. Does it contain one specific fact from their history, like a date, a ticket number or what they already tried? If not, it could have been sent to anyone.
Owner. Does it name who acts next, as a person or a team? "We" is not an owner.
Clock. Does it contain a time you control? A fix date from engineering doesn't count unless they gave it to you in writing.

Run them on Reply A from the top and it fails all three: no record (it asks for a screenshot instead of using the history), no owner, no time. A warm reply with no owner and no time still leaves the customer stuck, so they write again. A plain reply with an owner and a time gives them something to wait for.

Using AI for the first draft

An AI assistant can turn your rushed draft into something calmer. Use only a tool your company approves, take out personal and payment details you don't need, and never let it send.

Here is a customer's message: [paste] and my draft reply: [paste].
Rewrite my reply to be calmer and shorter: 5 sentences at most for
email, 3 for chat, one question at most. Name the specific effect on
the customer once, using their facts. End with what I'll do next and
when: [time and time zone]. Remove any promise of a fix, date, refund
or credit that isn't on this list of things I've confirmed: [list, or
"none"]. Remove stock lines like "I understand your frustration".
Don't add new facts. Draft only.

Then read it and fix it yourself. You're the one sending it.

Where to start this week

If you only change three things: count the contacts in the history before you reply, take "I understand" out of your macros, and put a time you control in every reply to an upset customer. Those are the parts the customer notices.

Chatbot to human handoff: how to hand off without making the customer start over

Draft First — Tue, 20 Oct 2026 23:53:44 +0000

You've probably seen this chat, or been the customer in it:

Want to see one full play before you read on? Play 3 of 15 from The CS Agent Playbook shows how an AI agent turns a long escalation thread into a one-page brief for leaders, and it is free as a 3-page PDF: get the free sample play.

Customer: my invite button is greyed out
Bot:      Here's our article on adding users!
Customer: I read it. Can I talk to a person
Bot:      I can help! What would you like to do?
Customer: A PERSON
Bot:      Transferring you now. Someone will be with you right away.

(two hours later)
Agent:    Hi, how can I help you today?

Three things broke. The customer asked for a person twice. The bot promised "right away" with nobody available. And the agent got no context.

None of these needs a new tool. They need written rules for when the bot hands off, a short brief that travels with the handoff, and a first human reply that proves someone read the chat. Here's how to set each up, with scripts and prompts you can copy. (Companies and people in the examples are made up.)

Step 1: One request for a person is enough

When a customer types "human", "agent" or "let me talk to someone", route on that first request. No "before I transfer you, can I try one more thing". Each extra try lands on a customer who is already frustrated.

People don't only type "human". They write "real person", "someone who knows" or "call me", with typos and in other languages. So build the trigger from your own transcripts.

Paste this into whichever AI assistant your company approves:

Search [conversation export, last 30 days] for every way customers asked to speak
to a person. Quote each distinct phrasing once, with a count and 2 example
conversation IDs.
Then list conversations where the customer asked more than once before a handoff
happened, with each request quoted and the bot's reply in between.
This is a draft for me. Don't change the bot.

Check it: read two ask-twice conversations in full. If the customer accepted the bot's reply in between, it isn't a miss.

What the bot says when it routes:

Of course. I'm passing this to the team now with everything you've told me, so you won't have to repeat it. [The current wait is about X minutes, or: You'll hear from us by X.]

Step 2: Hand off after two failed tries

The second trigger is the loop: the bot answers the same question twice, the customer is still stuck, and the bot tries a third time.

Count tries per problem, not per message.
A try has failed when the customer says it didn't work, repeats or rephrases the question, or asks for a person.
Start at two strikes. Use one strike for high-stakes topics like billing and account access. Allow three only where your own transcripts show third tries actually working.

At the handoff, the bot should sound like it noticed:

That hasn't fixed it, and I don't want to keep you going in circles. I'm passing this to a person now, with what we've tried.

Step 3: Watch for mood turns and never-automate topics

Two more triggers round out the set.

Mood turns. Messages get shorter, sharper or all capitals while the bot stays cheerful. Agree a few plain signals with your team: whole sentences in capitals, swearing, phrases like "this is ridiculous", or the customer saying they've already contacted you about this. On billing, account access or data, one signal hands off. Elsewhere, two. And take stock lines like "Great question!" out of the bot's replies.

Never-automate topics. Some topics route to a person on sight, whatever the bot thinks it could do: money disputes and refunds outside policy, legal threats or any mention of lawyers or regulators, security reports and possible data exposure, account access requested by someone who isn't the account holder, cancellations, and a customer who seems distressed or at risk. For distress, legal and security topics, the wording and destination come from your company's policy owners. Listen for real phrasing like "my lawyer", "chargeback" or "I'm reporting you".

The whole set, as starting points to test against your own transcripts, not standards:

Trigger	Topics	Starting threshold
Asks for a person, any wording	All	First request
Failed tries on the same problem	All	2 (1 for billing, access)
Mood signal	Billing, access, data	1 signal
Mood signal	Everything else	2 signals
Never-automate topic	Your list	On sight

Step 4: Never promise a wait you can't see

"Someone will be with you right away" at 2 a.m., into a queue nobody reads until 9, is a broken promise. Give the bot your real staffed hours for each channel and each destination team, holidays included. The rule: the bot never says "shortly", "right away" or "in a few minutes" unless it can see that a person is available.

After hours, it says this instead:

Our team is offline right now and back at [time and time zone]. I've saved everything you've told me in ticket [number], so whoever picks it up starts where we left off. You'll get a reply by email.

Step 5: Send a five-line brief with every handoff

This is the fix for "Hi, how can I help you today?" Have the bot write the same five lines on every handoff, shown at the top of the ticket above the transcript:

Goal: [what the customer wants, in their words]
Verified: [facts checked through a tool, with the method] or none.
          Customer says: [anything not checked]
Tried: [what the bot suggested, and what happened] or none
Promised: [anything the bot told the customer, word for word] or none
Next: [one suggested step]

Filled in, it looks like this:

Goal: "I need to add a second admin before our audit next Thursday."
Verified: Ostrander Labs, signed-in admin (session check), Growth plan.
Customer says: the invite button is greyed out.
Tried: sent the "Adding users" article. No change.
Promised: a person will reply by email today.
Next: check whether the account has reached its seat limit.

Two lines need the most care. Customer says keeps anything the bot didn't check through a tool out of Verified, so nobody acts on a claim as if it were a fact. Promised matters because the customer may remember every promise the bot made, so the person needs to know them too. If a line is empty, the bot writes "none".

The test: a brief works if the person picking it up can write their first reply without opening the transcript. Check five briefs a week against that.

Step 6: Make the first human line prove you read it

Read the brief before typing. The first line names what's been tried, skips it, and says what happens next or asks the one open question.

Hi Tomasz, thanks for waiting. You need a second admin before next Thursday's audit, so I'm checking your seat limit now.

Hi Ines, I can see the reset code expired twice. Let's skip that and I'll sort out your access directly.

The rule: if your first line could be sent to any customer, rewrite it. Macros that open with "Thank you for contacting us" can tell the customer nobody read the chat. Keep example first lines in your macros for your top handoff reasons, and expect people to edit them each time.

Step 7: Count the misses every week

Two numbers tell you whether the handoff is holding up:

Ask-twice count. Conversations where the customer asked for a person more than once. Read every one. The aim is zero, because one request is enough.
Brief pass rate. Briefs that pass the Step 5 test, out of the five you check each week. If it's below 4 of 5 two weeks running, fix the brief instructions first.

Write the count and the denominator, like 3 of 5, not just a rate.

Where to start this week

If you only do three things: route on the first request for a person, switch on the five-line brief, and agree who can switch the bot to "route everything to people" when it starts giving bad answers. Those are the gaps a customer can see, and none of them needs a new tool.

What to send after a support ticket closes (CSAT survey email templates)

Draft First — Tue, 20 Oct 2026 14:35:22 +0000

A CSAT survey email after a ticket closes should ask one question about that ticket, name the ticket so the customer knows which one you mean, and make the rating a single click. Then make sure a person reads and answers every low score, or the survey tells the customer nobody is listening.

The one-question version

Subject: How did we do on [ticket subject]?

Hi Priya,

We closed your ticket [#4850, ticket subject] today. How satisfied
were you with the help you got?

[1 Very unhappy]  [2]  [3]  [4]  [5 Very happy]

One click is enough. If you want to tell us more, there's an optional
comment box after you pick a score. Someone on the support team reads
every answer.

[Support team name]

Three rules that matter more than the wording

Name the ticket. "How did we do on your export problem?" is clearer than "Tell us about your experience".
Send one reminder at most. A survey that keeps chasing someone about a closed ticket can become the next complaint.
Store the ticket ID with every response, so each low score can be matched to its ticket and answered within a day by a real person.

The full guide has a plain-text version, a version for long or escalated cases, the reminder, subject lines, when not to send, and an AI prompt for drafting your own: https://draftfirstcs.com/guides/csat-survey-email-template?ref=devto-csat

All names are made up.

ChatGPT prompts for customer service replies you still send yourself

Draft First — Mon, 19 Oct 2026 04:36:13 +0000

The best ChatGPT prompts for customer service give the assistant the customer's message and the facts you have, ask for a short draft in plain words, and set hard limits: use only what you pasted, never promise a fix, a date or a credit, and leave sending to a person. Below are six prompts for the replies support agents write most, plus a check to run before you hit send.

These work in ChatGPT, Claude, Gemini, Copilot or whatever assistant your company has approved. Swap the [brackets] for your own details and paste the email or ticket after the prompt.

What rules should go above every customer service prompt?

Paste these once at the top of the chat, or in your assistant's custom instructions if it has them. They do most of the work.

Rules for every reply you draft for me:
- Write drafts only. I read, edit and send them myself.
- Use only the facts in what I paste. If something isn't there,
  tag it [CONFIRM] instead of guessing.
- Never promise a fix, a date or a credit, and don't say anything
  is fixed or solved unless I tell you it is.
- Use the customer's own words about the problem.
- Keep it short and in plain words. No sales language.

1. How do you reply when a customer asks for an update?

Draft a short update email from me to [customer name] about
[ticket or problem]. Use only the facts below.
Include: what we know, what we're doing now, and when they'll hear
from us next ([next update time]).
Acknowledge the impact in their words if their email has them.
Don't share internal names or theories about the cause.
Never promise a fix, a date or a credit. Under 150 words.
Facts: [paste the ticket notes]
Their email: [paste it]

The next update time is the part customers remember. Give one and keep it. There are ready-made versions in the ticket update email templates.

2. What do you send when you can't answer yet?

Write a two-sentence holding reply to this email. Say when I'll get
back to them properly: [day and time]. Don't promise anything else.
Email: [paste it]

A holding reply buys you time honestly. It only works if you then reply by the time you gave.

3. How do you start a reply to an upset customer?

Draft a reply to this customer. Thank them for telling us, acknowledge
the problem in their own words, and offer one next step: a short call,
one question, or passing their feedback to the team.
Don't argue with their account of what happened. Don't promise a fix,
a date or a credit, and don't say anything is solved.
Under 120 words. Their email and the ticket: [paste both]

Many people write the first sentence themselves and let the assistant draft the rest. For a fuller walkthrough, see how to respond to an angry customer email.

4. How do you answer a low survey score?

This customer gave us [score] out of [scale] after ticket [ticket ID].
Their comment: [paste it exactly, or "no comment"].
Draft a short reply from [account owner] that thanks them,
acknowledges the problem in their words and offers one next step.
If there's no comment, ask one simple question about what went wrong
and offer a short call. Mention the ticket by subject so it doesn't
read like a form letter.
Under 80 words. Never promise a fix, a date or a credit.

More on who should reply and when in following up on low NPS and CSAT scores.

5. How do you ask a customer for missing details?

From this ticket, list what we still need from the customer to move
the case forward. Then draft one short email that asks for all of it
at once, as a numbered list, with the exact question for each item.
Explain in one line why we need it. Don't guess at the cause.
Ticket: [paste it]

Asking once, with a numbered list, beats three emails over three days. More case prompts are in AI prompts for support case work.

6. How do you check a draft before you send it?

Run this on any draft above, in the same chat, before anything goes to a customer.

Check the reply you just wrote. List anything that:
- promises a fix, a date or a credit, or says something is fixed
- doesn't use the customer's own words about the problem
- mentions a ticket or detail that isn't in what I pasted
- opens or closes the same way as your other drafts today
Don't rewrite it. Just list the problems, or say "No problems found".

Why do AI replies sound like a bot, and how do you fix it?

Every reply opens the same way. Customers notice. Ask for three different openings and pick one.
It doesn't sound like you. Write one apology in your own words and paste it in as the example.
It answers a nearby question. Make it quote the customer's actual ask before it drafts.
It's too long. Set a word limit in every prompt. Short replies get read.

Only use an assistant your company approves for customer data. If you aren't sure, take names and contact details out of what you paste.

Get one complete AI play free. The Escalation Brief from The CS Agent Playbook: the prompt, guardrails and a sample result, sent to your inbox.
Send me the free play

Questions

Can ChatGPT answer customer emails for me?

It can write the first draft. A person should read every reply, check the facts and send it. Nothing in these prompts asks the assistant to send anything.

Is it safe to paste customer emails into ChatGPT?

Only if your company approves that tool for customer data. If it doesn't, or you aren't sure, take names, emails and account details out first and check what's left.

How do I stop AI replies sounding like a bot?

Paste one reply you wrote yourself as the example, ask for three different openings and pick one, and make sure the draft uses the customer's own words about the problem.

Why do the prompts ban promising a fix or a date?

Because a promise in writing is hard to take back. If engineering hasn't committed to a date, the reply shouldn't either. Say when the customer will hear from you next instead.

Want to try a full routine first? The Escalation Brief play from The CS Agent Playbook is free: https://draftfirstcs.com/free?utm_source=devto&utm_medium=post&utm_campaign=chatgpt-prompts-for-customer-service-replies-you-still-send-yourself

Originally published at draftfirstcs.com.

How to answer a customer asking for an update on their ticket

Draft First — Mon, 19 Oct 2026 04:35:22 +0000

When a customer asks for an update, reply with what you know, what you're doing now and when they'll hear from you next. Use their own words for the impact. Leave out internal names and guesses about the cause, and don't promise a fix, a date or a credit unless the people doing the work have committed to it. Keep it under 150 words.

"Any update?" usually means "is anyone working on this?". The templates below answer that question first. Swap the [brackets] for your details. All names are made up.

What should a ticket update email include?

What we know. Facts only, in plain words.
What we're doing now. Actions, not effort. "Engineering is testing a fix" beats "the team is working hard".
When they'll hear next. A day and time, not "soon".
The impact, in their words, if they've told you. It shows you read their email.

1. Still investigating

Hi Dana,

Thanks for checking in on the export timeouts. We can reproduce the
problem on reports longer than a month, and our engineers are looking
at why those time out.

Shorter date ranges still work, so splitting the report by week will
get you the numbers for Friday's close.

I'll update you by [day, time] either way.

Sam

2. Waiting on engineering

Hi Raj,

A quick update on [ticket number]. Our engineering team has the details
and is working on it. I don't have a fix date to give you yet, and I'd
rather not guess.

I'll check in with them [day] and write to you by [day, time].

Sam

3. Workaround in place

Hi Priya,

While we work on the root problem, there's a workaround: [steps]. It
should let your team [what it unblocks]. If it doesn't work for you,
reply here and I'll look at it straight away.

Next update by [day, time].

Sam

4. Waiting on the customer

Hi Tom,

To keep this moving, I need three things from you:
1. [the exact item, like the error message or a screenshot]
2. [when it happened, with the time zone]
3. [who is affected]

As soon as I have them I'll pick it back up, and I'll update you
within [time] of your reply.

Sam

Ask for everything once, as a list. Three emails over three days feel like being passed around.

5. You missed the update you promised

Hi Dana,

I said I'd update you yesterday and didn't. I'm sorry. Here's where
things stand: [one or two lines].

Next update by [day, time], and I'll keep to it.

Sam

What should you never put in an update?

A fix date nobody has committed to.
A credit or refund you haven't been cleared to offer.
Internal names, ticket chatter or blame.
A cause someone suspects but hasn't confirmed. Wait until it's confirmed.
"Fixed" before the customer can see it working.

If the problem hits many customers at once, use incident communication templates instead. If it needs leadership, write an escalation brief.

How do you draft ticket updates with AI?

Using only the facts in the ticket notes below, draft a short update
email from me to [customer contact].
Include: what we know, what we're doing now, and when they'll hear
from us next ([next update time]).
Acknowledge the impact in their words if the thread has them.
Don't share internal names, theories about the cause, or anything
marked Hypothesis or [CONFIRM].
Never promise a fix, a date or a credit.
Under 150 words. This is a draft for me to edit and send.
Ticket notes: [paste them]

This is the customer update follow-up from the Escalation Brief play, the free play from The CS Agent Playbook. More reply prompts are in ChatGPT prompts for customer service.

Get one complete AI play free. The Escalation Brief from The CS Agent Playbook: the prompt, guardrails and a sample result, sent to your inbox.
Send me the free play

Questions

How often should I update a customer on an open ticket?

Whenever you said you would. End every update with the time of the next one, and keep it even when there's no news. Your own support policy may set a minimum.

What if there's no news?

Send the update anyway. Say what you checked, that you don't have an answer yet, and when they'll hear from you next. Silence reads as nobody working on it.

Should I give the customer an ETA for the fix?

Only if the people doing the fix have committed to one. Otherwise give the time of your next update instead of a fix date.

Can AI write ticket updates?

It can draft them from the ticket notes. Tell it to use only those facts, to leave out internal names and theories, and never to promise a fix, a date or a credit. Read it before you send.

Want to try a full routine first? The Escalation Brief play from The CS Agent Playbook is free: https://draftfirstcs.com/free

Originally published at draftfirstcs.com.

Incident Communication Templates: What to Tell Customers While You're Still Fixing It

Draft First — Mon, 19 Oct 2026 02:09:48 +0000

During an incident, customers want three things: to know you know, to know what it means for them, and to know when they'll hear from you next.

Most bad incident emails fail on the third. They promise a fix time nobody committed to, or they go quiet for three hours while everyone's heads-down.

Rules for every message

Describe what customers see, not what broke inside. "Reports won't load" beats the name of the service that fell over.
Promise the next update time, not a fix time, unless the people fixing it have committed to one.
No theories about the cause until someone has confirmed it. Theories change, and a wrong one has to be taken back in public.
No credits unless someone with authority approved them.
One source of truth. Status page, email and account team say the same thing at the same time.
Time zone on every time.

First notice

Subject: We're looking into [what customers see]

We're aware that [what customers see, like "some reports won't
load"] since about [time and time zone].
Our team is working on it now.
We'll send the next update by [time and time zone], or sooner if
anything changes.
[Status page link, if you have one]

Ongoing update

Send it on time even when nothing changed. Silence reads as "they forgot about us".

Subject: Update: [what customers see]

Where things stand: [Investigating / Fix in progress / Monitoring]
What you may notice: [current impact, and what's changed since the
last update]
What we're doing: [one plain sentence]
Next update by: [time and time zone]

Workaround available

Subject: A workaround for [what customers see]

While we work on a fix, you can [workaround in one or two short
steps]. This avoids [the problem] for now.
We're still working on the fix and will update you by [time and
time zone].

All clear

Subject: Resolved: [what customers see]

[What customers saw] is working normally again as of [time and time
zone]. It began at about [time].
If you still see a problem, reply to this email and we'll look at
your account directly.
We're sorry for the disruption.

Only promise a written summary afterwards if someone actually owns writing it.

Things never to say mid-incident

"This only affects a small number of customers." It doesn't feel small to them, and you may not know the number yet.
"It should be fixed in an hour." Unless someone committed to it.
"A third-party provider caused this." Even when true, it reads as blame.
Internal service names, or anything quoted from the internal channel.

Let an LLM draft the update, from the facts only

When you're running the incident, turning a fast-moving internal thread into a clean customer update is exactly the kind of work to hand off. The trick is strict limits, because a model will happily turn "Leo thinks it might be the config change" into "this was caused by a configuration change".

Using only the facts in [the incident thread or brief], draft a
short update to customers.
Include: what customers are seeing, what we're doing now, and when
they'll hear from us next ([next update time and time zone]).
Don't share internal names, theories about the cause, or anything
marked Hypothesis or [CONFIRM].
Never promise a fix, a date or a credit.
Under 120 words. This is a draft for me to edit and send.

A person reads it and sends it. Every time.

Full guide, including a personal note for key accounts and FAQs on update cadence and fix times: Incident communication templates for customers.

Want the full Escalation Brief routine, with its customer update follow-up and a sample result? Get the free play at https://draftfirstcs.com/free?utm_source=devto&utm_medium=post&utm_campaign=incident-communication-templates-what-to-tell-customers-while-youre-still-fixing-it

A Bug Report Template From Support to Engineering (So Nobody Has to Ask "Which Version?")

Draft First — Mon, 19 Oct 2026 02:09:31 +0000

A bug report from support has one job: let an engineer make the problem happen again without asking a single question. Every "can't reproduce" or "which version?" adds a day for the customer.

Here's a template that puts things in the order engineers actually read them, plus a few AI prompts that do the boring gathering without making things up.

The template

Title: [what breaks, for whom, where]
  Good: "CSV export times out over 10k rows (web app, all plans)"
  Not: "Customer says export is broken"

Steps to reproduce (from a known starting state):
1. [Log in as a user with role X / open page Y]
2. [Action, with the exact data or file used]
3. [Action]
Expected: [what should happen]
Actual: [what happens, with the exact error text]
Reproduced by support? [yes, on date / no, and why not]

Environment: [app version or build, browser and version, OS,
account or workspace ID, region, plan]

Evidence: [log lines quoted exactly, with timestamps and time zone;
screenshot or recording; failing request if you have it]

Impact: [linked tickets: #IDs | accounts affected: count and how
you counted | first seen: date | workaround: yes or no, and what]

Already ruled out: [cache cleared, other browser, permissions
checked, known issue list searched]

Hypothesis (optional): [what you suspect and the evidence for it]

Source ticket: [link]. Don't paste the whole customer thread.

The parts that matter most

Steps from a known state. "Log in as an admin and open Reports" beats "go to the report".
Expected vs actual, two lines, no adjectives. That's the acceptance test for the fix.
Environment. A common reason reports bounce. Pull it from the ticket before writing anything else.
Evidence quoted exactly. A paraphrased error message sends people down the wrong path.
Impact counted honestly, with ticket IDs. It sets priority, so it has to be checkable.
Ruled out. Saves the engineer from repeating support's first hour.
Hypothesis, labelled as one. Useful as a lead. Harmful if it reads like the cause.

AI prompts for the gathering

An LLM is good at pulling environment details out of a long thread and quoting log errors. It's also good at confidently filling in a field it can't see. So these prompts make missing data visible instead.

Strip passwords, tokens, keys and personal data before pasting anything, and use a tool your company approves.

Draft the report from the ticket

Using this ticket thread and the log lines below, fill in this bug
report template: [paste the template].
Take environment details only from the ticket or logs. If a field
isn't there, write [MISSING] so I know what to ask for.
Quote error messages and log lines exactly, with their timestamps.
Write the steps to reproduce as numbered steps from a known starting
state, and tag any step you're inferring as [CONFIRM].
Label any cause as Hypothesis with the lines that point to it.
This is a draft for me. Don't file it or contact anyone.

Ask the customer for what's missing

List every field marked [MISSING] or [CONFIRM] in the bug report.
Draft a short, friendly request to the customer for those details as
a numbered list. Remind them to remove passwords and personal data
before sending logs or screenshots. Don't promise a fix or a date.

Find the duplicates

Search [ticket export for the last 30 days] for tickets that might
be this same bug: [one-line description and the exact error text].
List each with ID, date and the matching phrase. Put tickets that
are only maybe the same under "Possible" and say why.
Don't count a ticket twice.

The "Possible" bucket matters. Inflated impact counts get bugs prioritized for the wrong reasons, and engineers stop trusting support's numbers.

Then a person runs the repro steps before anything gets filed.

Full guide, with why each field is there and a pre-filing checklist: Bug report template: support to engineering.

Want one complete routine with guardrails and a sample result? Get the free play at https://draftfirstcs.com/free?utm_source=devto&utm_medium=post&utm_campaign=a-bug-report-template-from-support-to-engineering-so-nobody-has-to-ask-which-version

5 AI Email Triage Prompts That Draft Replies but Never Send

Draft First — Mon, 19 Oct 2026 01:51:04 +0000

If you lead a support or customer success team, your inbox mixes a customer who's about to churn with newsletters, ticket notifications and calendar noise. Sorting it eats the start of the day, and on busy mornings the important one still slips.

Email triage is one of the easiest places to start with an AI agent, because it only needs one source: your email. The trick is the rules around the prompt, not the prompt itself.

Four rules first

It never sends, deletes, archives or labels. Drafts only. Say it in every prompt.
Drafts don't commit you to dates. Have it write [day] so you fill it in.
It tells you what it read. One line at the top: how many emails, over what window. If that's zero on a Monday, something broke. Quiet output and broken output look the same unless you ask.
It stays short. Under 20 lines, or you'll stop reading it.

Fill in three things once: your manager, up to 10 key accounts or email domains, and one line per team member on what they handle. Without that list, the agent guesses who to hand things to.

1. The morning sort

Sort my unread email from the last 24 hours into three groups.
On Mondays, go back to Friday morning.
Needs me today: anything from [my manager] or [my key accounts],
anything with a deadline today or tomorrow, and any customer who
sounds upset.
Can delegate: suggest who, from [team list].
FYI: everything else, as one line of counts.
For each Needs me today item, write a short draft reply. Write [day]
instead of committing me to a date.
Never send, delete, archive or label anything.
Start with one line: how many unread emails you read.
Keep it under 20 lines.

2. Did it miss anything?

Run this daily for the first two weeks, then weekly. Inboxes are where the exceptions live.

Look again at every email you put under Can delegate or FYI. List any
that come from [my manager] or [my key accounts], mention a deadline
in the next 3 days, or sound upset or mention a cancellation, a
contract or a renewal. Give the sender, subject and why it might
belong under Needs me today. If there are none, say so.

3. Promises you forgot

Triage only sees unread mail. What really gets dropped is the "I'll send that Friday" sitting in a thread you already answered.

Read my sent and received email from the last [14] days. List every
promise made by me or to me that isn't finished: the account, what
was promised, who owes it, the date if there is one, and whether it's
waiting on someone else. Skip anything clearly done. Sort by date.
Don't draft anything, just list them.

4. End of day sweep

Check today's Needs me today emails that I haven't replied to. For
each, say whether it can wait until tomorrow, using the deadline in
the email if there is one. For anything that can't, write a
two-sentence holding reply that says when I'll get back properly.
Don't promise anything else. Drafts only.

5. Before you go on leave

I'm out from [date] to [date] and [name] is covering. From my inbox
and sent mail, list open threads with customers that might need an
answer while I'm away: the account, one line of context, the
decision needed and any deadline. Write a short handover note for
[name]. Don't contact anyone.

What to expect

Expect to tune the first prompt more than any other. When it files something urgent under FYI, add that sender or phrase to the prompt. Skim the FYI pile for two weeks before you trust it.

And only connect an agent to your email if your company approves that tool for it. Read access plus drafts is plenty.

Full guide with a sample morning sort and FAQs: AI email triage prompts for CS and support leads.

Want one complete routine with guardrails and a sample result? Get the free play at https://draftfirstcs.com/free?utm_source=devto&utm_medium=post&utm_campaign=5-ai-email-triage-prompts-that-draft-replies-but-never-send

Root Cause Summaries for Support Cases: One for Your Team, One for the Customer

Draft First — Mon, 19 Oct 2026 01:51:01 +0000

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?utm_source=devto&utm_medium=post&utm_campaign=root-cause-summaries-for-support-cases-one-for-your-team-one-for-the-customer