DEV Community: Draft First

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:

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.

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.

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

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

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

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

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

AI Prompts to Summarize Support Tickets Without Losing the Details

Draft First — Sun, 18 Oct 2026 15:20:17 +0000

Ticket threads get long, and the important bit is usually buried in message 23. AI is good at summarizing them, but generic summaries drop exactly the details you need: what was promised, what's still broken, who's waiting on whom. These prompts keep those.

1. Summarize one ticket

Summarize this ticket thread in 5 lines: the customer's problem in their
words, what we've tried, current status, who's waiting on whom, and any
promise we made with its date. Quote, don't paraphrase, any promise.
[paste thread]

Sample output (made-up names and dates):

Problem: "Exports over a month time out" (Dana, Oct 2)
Tried: cache clear, smaller date ranges (works under 2 weeks)
Status: engineering reproduced, fix in testing
Waiting on: us. Release date not confirmed.
Promise: "We'll have a fix by the 10th" (Sam, Oct 4). Missed.

2. An account's ticket history

From these tickets for [account] over the last 90 days, list: total
count vs prior 90 days, top 3 themes with ticket numbers, any Sev1/Sev2,
open tickets older than 7 days, and any repeated issue. [paste or attach]

3. Weekly themes across all tickets

Group last week's tickets into themes. For each: number of distinct
accounts, ticket numbers, one verbatim quote, and whether it's new or
rising. Count accounts, not tickets. List tickets you couldn't classify.

4. Shift handoff note

From the open tickets assigned to me, write a handoff note for the next
shift: for each, ticket number, customer, one-line status, the next
action, and any deadline. Put anything due in the next 4 hours first.

Rules that keep summaries honest

Quote promises and customer complaints exactly.
Ask it to list what it couldn't tell from the thread.
Spot-check one summary a day against the real thread for the first two weeks.

Ticket themes feed your voice of the customer report, and account histories feed QBR prep.

Questions

Can AI summarize support tickets accurately?
Mostly, if you ask it to quote promises and complaints exactly and spot-check summaries at first.

What should a ticket summary include?
The problem in the customer's words, what's been tried, status, who's waiting on whom and any promises.

How do I find themes across many tickets?
Ask AI to group them and count distinct accounts per theme, with ticket numbers and a quote each.

Want one complete routine with guardrails and a sample result? Get the free play at https://draftfirstcs.com/free

The full guide, with every prompt in one place, is at Draft First.

AI Prompts for Customer Success Managers: 6 That Actually Hold Up

Draft First — Sun, 18 Oct 2026 13:27:07 +0000

Most lists of AI prompts for customer success look great until you run them on a real account. The model fills gaps with confident guesses, invents a usage number, or writes a cheerful email to a customer who is three days into a Sev1. The prompt wasn't the problem. The missing rules around it were.

Below are six prompts I use as starting points, followed by the four rules that make any CSM prompt safe to rely on. Swap the [brackets] for your own field names.

The four rules to put above every prompt

Name your sources. Tell the agent exactly which tools or exports it may read. If it isn't listed, it doesn't count.
No invented numbers. Every figure must come from a source. Anything it can't verify gets a [CONFIRM] tag instead of a guess.
Say what you couldn't check. End every output with a Skipped line. A broken connection should never look like a quiet week.
Draft only. Nothing goes to a customer or an executive until a person reads it.

1. Churn signal sweep

Review [accounts] for [date range] vs the prior period of equal length.
Flag an account only if it shows 2 or more signals: tickets up 50% or more,
any open Sev1 or Sev2 older than 3 days, weekly active users down 20% or more,
an executive email unanswered for 5 days, renewal inside 90 days with health
not Green. For each flagged account give the signals with source references
and one next step. End with a Skipped line.

The threshold of two signals keeps the list short enough to act on. One noisy week shouldn't put an account on your Monday list. There's a full write-up in the churn risk review routine guide.

2. QBR fact pack

For [account], collect from [CRM, tickets, usage, notes] since [last QBR date]:
goals they set last time and evidence on each, usage trend, top 3 ticket themes,
promises we made and whether we kept them, renewal date and stakeholders.
Mark anything you can't support as [CONFIRM]. Do not write slides yet.

Separate the facts from the story. Once you trust the facts, asking for a narrative is easy. More in QBR prep with AI.

3. Escalation brief

Write a one-page brief on [ticket or account] for [leader]: what happened,
customer impact in their words, timeline with dates, what we've done, what's
blocked and who owns it, the decision we need, and the next update time.
Quote the customer only from source messages.

See how to write an escalation brief for the structure and a worked example.

4. Renewal brief

For renewals landing in [90/60/30] days, list owner, ARR band, health, open
risks, last executive touch, and the one thing that would most improve the
odds of renewing. Use only [CRM fields]. End with a Skipped line.

5. Post-call follow-up

From these call notes, draft a follow-up email: a two-sentence recap, action
items with owners and dates, and one question that moves the account forward.
Keep it under 150 words and in my voice, based on these sample emails: [paste].

6. Friday update to your manager

Summarize my week from [calendar, CRM changes, closed tickets]: wins, risks,
asks. Five bullets max. No adjectives about effort.

Weak prompt vs strong prompt

Weak	Strong	Why it's better
Which accounts are at risk?	Flag accounts with 2 or more of these 5 signals for Oct 5 to 11 vs the week before	Fixed window and a clear rule
Write a QBR for Acme	List Acme's goals and evidence from these 3 sources. Facts only.	Facts before story
Summarize this escalation	One page for the VP: impact, timeline, owner, the decision needed	Names the reader and the ask

Why prompts alone plateau

A one-off prompt saves you ten minutes. A routine that runs on a schedule, reads the same sources and reports what it skipped saves you hours, because you stop doing the gathering at all. That's the shift from prompting to running AI agents for customer success.

Questions

Can I use ChatGPT for customer success work?
Yes, for drafting and summarizing, as long as your company approves it for customer data. Remove names from exports if you're unsure.

What makes a good CSM prompt?
Named sources, fixed date windows, a rule against invented numbers, and a line listing what it couldn't check.

Should AI send emails to customers?
No. Let it draft and have a person read every message before it goes out.

Want one complete routine with guardrails and a sample result? Get the free play at https://draftfirstcs.com/free

The full guide, with every prompt in one place, is at Draft First.