It shows up like this. In one week a support team sends the same renewal notice to three customers in three completely different voices. One is two lines and a link. One apologizes for the interruption before it gets to the point. One opens with "Dear valued customer." Nobody has done anything wrong: each of the three saved their own version months ago, and each version is fine on its own. Side by side they read like three companies.
That's the failure mode templates are supposed to prevent, and the reason a template is a different object from the snippet you paste mid-conversation. A renewal notice starts a thread. It needs a subject line, a greeting, a signoff and a decision about how formal you are, and those are exactly the parts a paste-in block never has.
So this is eighteen complete emails for the moments where your team writes first: onboarding, renewals and price changes, cancellations, apologies, announcements, and the times you're asking the customer for something. Before them, the part these libraries tend to leave out: what your subject line does to the customer's thread, and why the helpful instinct to tidy one up on reply is one of the more expensive habits on a support team.
Template or canned response? The subject line is the test
A canned response is a paragraph you drop into a conversation that's already running. The subject line, the greeting and the signature are already there, so the block is only the middle. If that's what you came for, we keep a library of those, grouped by the moment each one answers, and none of them belong on this page.
A template is a whole message you start from. Nothing exists yet, so it has to carry the subject line, the greeting, the body and the next step, and it has to survive being sent by five different people without sounding like five different companies.
That's the test: if your text works pasted into the middle of a reply, it's a canned response. If it needs its own subject line to make sense, it's a template and it's on this page. And if you're after what people say out loud rather than write, scripts for calls and chat are a separate craft.
How to write a customer service email: the six parts
Every email below has the same skeleton. It's worth knowing the skeleton because it tells you what to cut when a template runs long.
- Subject line. Under about nine words, the identifying detail first.
- Greeting. First name if you have it, no honorifics unless your market expects them.
- One sentence that proves a person read this. Not "thank you for reaching out." The order number, the date, the thing they actually said.
- The answer, or the honest state of it. This is the only part allowed to run long.
- The next step, with a date on it. Who does what, by when. A next step without a date isn't one.
- The ending. Stop at the last sentence. Your signoff and your name come from the mail client, not from the template, for the reason below.
A hundred to a hundred and eighty words covers all six comfortably. Past that you're usually explaining your internal process, which nobody asked about.
Part six is where templates quietly break. Gmail lets you set one default signature for new messages and a different one for replies, so a signoff written into the template arrives with a second one stapled underneath it. Outlook's device-stored signatures don't travel: Microsoft's documentation warns that "signatures on this device are stored locally on the device where they were created and may not be available when you use Outlook on another device". So a template ending with its own written "Best, the Support Team" goes out double-signed for everyone whose client already appends one, and goes out looking different depending on which laptop the sender opened. Write your templates to stop at the last sentence and let the client do the signing.
Customer service email subject lines: what they carry, and when never to change one
Every template library prints a subject line on each entry. Almost none of them say what the subject line does to the thread, which is a shame, because it does something drastic.
Gmail's documentation is blunt about it: "A conversation breaks off into a new conversation when the subject line changes, or the conversation gets to more than 100 emails." The mail standard underneath doesn't work that way at all. RFC 5322 threads on headers: "The 'In-Reply-To:' and 'References:' fields are used when creating a reply to a message", and "the 'References:' field may be used to identify a 'thread' of conversation." The subject is not what holds the conversation together in the spec. It is what holds the conversation together in the interface your customer is looking at.
That gap is where the damage happens. An agent inherits a thread with the subject "help???", rewrites it to "Invoice 4417, duplicate charge" because that's clearer, and hits send. In the customer's Gmail the history splits in two. The next teammate opens the new thread, sees one message with no context, and asks a question the customer already answered. Everyone was being helpful.
So: set the subject once, when you start the thread, and leave it alone forever after.
| Situation | What the subject has to carry | Worked example | Change it later? |
|---|---|---|---|
| You're starting a thread the customer didn't ask for | The identifier first, then the point | Renewal 14 March: your Team plan |
No |
| You're replying inside a running thread | Nothing new. Leave it exactly as it is | Re: Invoice 4417 wrong amount |
Never |
| You're announcing something to many people | What changes and the date it happens | Maintenance Sunday, 09:00 to 11:00 UTC |
No |
| You actually want a second, separate thread | A subject with nothing in common with the first | Billing address change, account 4417 |
This is the one case |
The identifier-first rule matters more than it sounds. On a phone the customer sees the opening words of a subject and nothing else, so "Following up on your recent inquiry regarding invoice 4417" shows them the word "Following" and nothing they can act on.
Set the voice once so five people sound like one team
Templates only hold a team together if somebody has decided what the team sounds like. Five decisions, written down on one page, settle almost every argument:
- Formality. First name or surname, and whether you ever write "Dear". Pick one and apply it to all eighteen.
- Contractions. Use them. "We'll have this fixed by Thursday" is how a person writes; "We will have this fixed by Thursday" is how a notice from a bank reads. This is the single fastest way to stop a template sounding like a template.
- The apology ladder. Decide what earns "sorry about the wait", what earns "that's our mistake", and what earns a full admission with a named cause. Without a ladder, everything gets the same apology and none of them land.
- How you say no. A refusal has a shape: the answer, the reason in one sentence, and what you can do instead. Agree the shape and nobody improvises it at 5pm.
- One term per concept. If it's a "plan", it's never a "subscription" three emails later. US federal plain-language guidance puts it plainly: "You can confuse your audience if you use different terms for the same concept or object", and asks you to keep the first term throughout.
Then the decisions have to live somewhere other than in one person's head. That's the mechanical reason the renewal notice went out in three voices: three saved copies in three mail clients, no shared original. A shared inbox tool like TriageFlow puts the set on the mailbox instead, so a wording fix lands in everybody's next send rather than in one person's drafts folder.
18 customer service email templates and examples
Six groups of three. Every entry gives you the subject line, the whole message, the one thing you have to change before sending, and the case where you shouldn't send it at all.
| If you need to | Go to | Templates |
|---|---|---|
| Start someone off well in their first two weeks | Onboarding and welcome | 1 to 3 |
| Warn about money before it moves | Renewals, price increases, failed payments | 4 to 6 |
| Handle someone on the way out, or bring them back | Cancellation and win-back | 7 to 9 |
| Own a failure in writing | Apologies and outage notices | 10 to 12 |
| Tell people about a change they didn't ask about | Announcements | 13 to 15 |
| Ask a customer for a review, feedback or an introduction | Asking for something back | 16 to 18 |
Refunds, order status, bug reports, feature requests, escalations and thread closings aren't here on purpose: those are replies inside a running conversation, and they belong with the canned responses instead.
Onboarding and welcome email templates
1. Welcome, sent the day they sign up.
Subject: Welcome to [Product]: your first step
Hi [First name],
You're in. Rather than send you a tour, here's the one thing worth doing today: [single specific action, e.g. "connect the mailbox you actually answer from"]. It takes about [n] minutes and everything else makes more sense afterwards.
If it doesn't work the way you expect, reply to this email. It comes to a person, not a no-reply address.
Change: the single action, which should be the one that predicts whether they stick. Don't send it when: a salesperson is already mid-conversation with them, or they'll get two welcomes.
2. Setup finished, here's what to do first.
Subject: [Product] is set up: what to do first
Hi [First name],
[Thing] went live on your account on [date]. Two things worth knowing before you start:
- [The setting most people get wrong, and what to set it to]
- [The thing that looks broken but isn't]
I'll check in again in two weeks to see how it's going. If anything looks wrong before then, just reply here.
Change: the date, and both numbered items, which come from your own support queue rather than from the docs. Don't send it when: setup isn't actually finished. A premature "you're all set" costs you the next three emails.
3. The two-week check-in.
Subject: Two weeks in: anything not working?
Hi [First name],
You've had [Product] for two weeks, so this is the point where either it's fitted into your week or it hasn't.
If something's in the way, tell me what it is and I'll either fix it or tell you honestly that we can't. Either answer is more useful to you than silence.
If it's all fine, ignore this one. No follow-up.
Change: the interval, if your product takes longer than two weeks to show what it's for. Don't send it when: they've got an open ticket. Asking "how's it going" while their problem is unsolved reads as tone deaf.
Renewal reminders, price increases and failed payments
4. Renewal reminder, before the card gets charged.
Subject: Renewal [date]: [Plan name], [amount]
Hi [First name],
Your [plan] renews on [date] and the card ending [last four] will be charged [amount].
Nothing to do if that's right. If you need an invoice in advance, a different billing address, or you want to change plan before it renews, reply and I'll sort it today.
Change: date, amount, last four digits. Every one of them, every time. Don't send it when: you can't actually action a plan change by that date. Don't offer what you can't do.
5. Price increase.
Subject: Your price changes on [date]
Hi [First name],
Your [plan] goes from [old price] to [new price] on [date]. The last change was in [year].
The reason, plainly: [one honest sentence, e.g. "our infrastructure costs went up and we'd rather raise the price than quietly cut what you get"]. What changes for you: [nothing, or the specific thing].
If that doesn't work for your budget, reply before [date] and let's talk about it rather than have you find out from a card statement.
Change: the reason and the last-change year. If you can't write the reason in one honest sentence, you're not ready to send this. Don't send it when: the increase is under 30 days away and your contract requires more notice. Check first.
6. The card was declined.
Subject: Payment didn't go through, account still active
Hi [First name],
The payment for [plan] didn't go through on [date]: the card ending [last four] was declined, which is usually something routine like an expiry or a bank block.
Your account's still running. We'll try again on [date], or you can update the card here: [link].
If you'd rather pay by [alternative method], say so and I'll send an invoice instead.
Change: the decline date, the retry date, and whether the account really is still active. Don't send it when: you've already suspended them. Then you're writing a different, more apologetic email.
Cancellation and win-back email templates
7. Cancellation confirmed.
Subject: Canceled: [Plan name], access until [date]
Hi [First name],
That's canceled. You've got access until [date] and there'll be no further charges.
Your data stays available to export until [date + retention window]: [link to export]. After that it's deleted, and we can't get it back.
No hard feelings and no sales sequence. The next time you hear from us it'll be because something you actually asked for has changed.
Change: the retention window, which has to match what your systems actually do. Don't send it when: you haven't canceled it yet. Confirm after the fact, never before.
8. The save attempt, asked as a question.
Subject: Cancellation booked: what stopped working?
Hi [First name],
You've asked to cancel and I've queued it, so this isn't me trying to talk you out of it.
One question, because your answer changes what we fix next: was it [likely reason A], [likely reason B], or something we didn't see coming? One line is plenty.
If it turns out to be something we can fix today, I'll tell you. If not, the cancellation goes through as planned on [date].
Change: the two likely reasons, drawn from your own churn data rather than guessed. Don't send it when: they've canceled angrily after a failure you caused. Send the apology instead and leave them alone.
9. Win-back, three to six months later.
Subject: [Product]: the [reason you left] has changed
Hi [First name],
You left us in [month] because [specific reason they gave]. That's now different: [one sentence on what changed and when].
I'm not going to pretend that's a reason to come back on its own, but if the problem's still yours to solve, the door's open and your old settings are still there.
If it's not relevant any more, reply "no thanks" and I'll take you off this list for good.
Change: the specific reason, quoted from what they told you. Without it this is spam. Don't send it when: you don't have their stated reason on record, or you're sending it as a batch. A batch goes out from the marketing system with a real unsubscribe link, not from the support address.
Apologies and outage notices as whole letters
These three are composed letters rather than paste-in blocks, and the apology as a genre has its own guide if you want more on the wording.
10. You let one customer down.
Subject: [What went wrong], and what we've done
Hi [First name],
[Specific thing] happened on [date], and it happened because [cause in plain words]. That's on us.
We've already [the fix for them, done, not planned]. To stop it recurring we've [the change on your side].
If there's knock-on damage I haven't accounted for, tell me what it is and I'll deal with that too.
Change: the cause. A cause you can't state plainly usually means you haven't found it yet. Don't send it when: the fix isn't done. An apology that arrives before the repair gets read as a delaying tactic.
11. The outage notice, sent to everyone affected.
Subject: [Product] outage [date], now resolved
Hi [First name],
Between [start time] and [end time] [UTC], [what didn't work]. If you were trying to [affected action] in that window, it either failed or was slow.
Cause: [plain-language cause]. Fixed at [time] by [what you did].
Nothing on your side needs doing: [queued items were processed / no data was lost / the specific reassurance that's actually true]. Full write-up here if you want it: [link].
Change: the reassurance line, which must be literally true. Don't send it when: you're still guessing at the cause. Send a short "we're on it" first and this once you know.
12. The support experience itself was bad.
Subject: We handled your [issue] badly
Hi [First name],
You wrote to us on [date] and it took [n] days and [m] replies to get you an answer. That's not the service we're trying to run, and I'm sorry.
What happened on our side: [the honest reason, e.g. "your message was assigned to somebody on leave and nothing flagged it"]. What we've changed so it doesn't repeat: [the specific change].
Your [issue] is now [status]. If any of it is still open, reply here and it comes straight to me.
Change: the honest reason. "High volume" isn't one. Don't send it when: you haven't actually changed anything. Promising a change you won't make is worse than the original delay.
Announcements the customer didn't ask for
13. Planned maintenance.
Subject: Maintenance [day], [start] to [end] [UTC]
Hi [First name],
We're taking [product or feature] offline on [day] from [start] to [end] [UTC] to [reason].
During that window: [what won't work]. Still working: [what will].
Nothing to do beforehand unless you [the one exception, e.g. "run scheduled exports in that window"]. We'll confirm here when it's back.
Change: the timezone, spelled out. "9am" means four different things to a customer base. Don't send it when: the window is under an hour and nothing customer-facing is affected. Not every change is news.
14. A policy or terms change that affects them.
Subject: Change to [policy] from [date]
Hi [First name],
From [date] we're changing [policy]: [old rule] becomes [new rule].
What that means for you specifically: [the practical consequence, in one sentence]. If you [specific situation], you'll want to [specific action] before [date].
The full terms are here: [link]. If this causes you a problem, reply and tell me what it is. We'd rather hear it now than at renewal.
Change: the "specifically" line. A terms email without it gets filed unread. Don't send it when: the change is invisible to that customer segment. Send it to the people it touches.
15. The thing they asked for is now live.
Subject: [Feature] is live, you asked for it in [month]
Hi [First name],
Back in [month] you asked whether [Product] could [thing]. At the time the answer was no. As of today it's yes: [one sentence on how it works].
Here's where to find it: [path or link]. It behaves slightly differently from what you described, in that [honest caveat].
If it doesn't solve the problem you had, I'd like to know that too.
Change: the month and the original ask, quoted. Delete the caveat sentence if the feature does exactly what they described. Don't send it when: the feature only half solves what they asked for and you'd have to oversell it.
Asking for something back
16. Review request, after you fixed something well.
Subject: [Their issue]: would you write two lines about it?
Hi [First name],
Glad we got [specific thing] sorted, and thanks for the clear description. It made it quick to find.
If you've got two minutes, a short review on [platform] helps people decide whether we're worth trying: [link].
If you'd rather not, no problem at all and this is the only time I'll ask.
Change: the specific thing, and the promise to only ask once, which you then keep. Don't send it when: the resolution took longer than it should have. You don't get to ask for a favor after making them wait.
17. Feedback request that says why you're asking.
Subject: One question about [specific thing]
Hi [First name],
We're deciding whether to [specific decision] in the next quarter, and you're one of about [n] customers who actually [relevant usage].
So, one question: [the single question].
Whatever you say goes straight to the people making the call. No survey, no follow-up sequence.
Change: the decision you're actually making. If there isn't one, don't send this. Don't send it when: you've already decided. People can tell, and they stop answering the next one.
18. The referral ask.
Subject: Introduction to someone else running [situation]?
Hi [First name],
You've been with us [duration], and [the specific thing they said it fixed]. That's the part I'd struggle to explain to somebody who hasn't tried it.
If you know someone running [the same situation] with the same problem, would you send me their name? I'll write to them myself and say you put us in touch, or introduce us however suits you better.
And if you'd rather keep work and recommendations separate, that's completely fair.
Change: the specific thing, quoted from something they've actually written to you. Don't send it when: they've had an incident in the last month. Wait a quarter.
How to fill one in without sounding like a template
The variable brackets aren't the personalization. Filling them in only stops the email being addressed to nobody. Real personalization is one sentence that proves you read their message, and it has to be written fresh: the delivery date they mentioned, the deadline they're up against, the thing they said they'd already tried.
Two habits stop most of the damage. Read the whole thing top to bottom before sending, which catches an unfilled [First name] faster than any checklist. And never paste a template into an angry thread without rewriting the opening; a customer mid-complaint can smell a form letter through a screen.
Then there's the edit test. If you find yourself rewriting the same template every single time before you send it, the template is wrong, not you. Fix the source once. A library you repair on every send is slower than typing from scratch, and it quietly teaches the team that the shared version can't be trusted.
Before you send the lifecycle ones to a list
Support replies go out one at a time. Renewal reminders, price increases, win-backs, outage notices, maintenance warnings and policy changes usually don't: somebody exports a segment and sends a few thousand at once, and at that moment those templates stop being support email and start being bulk mail in Google's eyes.
Google's sender requirements apply accordingly. Every sender has to "give recipients an easy way to unsubscribe" and keep spam rates reported in Postmaster Tools below 0.30%, with 0.10% recommended. Anyone sending 5,000 or more messages a day to Gmail accounts also has to support one-click unsubscribe and "include a clearly visible unsubscribe link in the message body", on top of SPF, DKIM and DMARC. Get that wrong and it isn't only the campaign that suffers: the ordinary support replies leaving the same domain are the ones that start landing in spam.
The practical version is a boundary. Anything you send in batches goes out from the marketing system on its own subdomain. Your support address, the one a human answers, stays one-to-one. Send template 5 or template 13 to eight hundred people from the shared mailbox and you've put your reply deliverability on the line to save a copy and paste.
Where the text itself lives is a separate question, and a solved one: where template text actually lives in Gmail and Outlook sets out what each built-in option can't do. The short version is that all of them store the text per account, which is fine for one person and starts to hurt around the third. When that sprawl is what pushes a team to look at tooling, the costs that never reach the quote are set out in help desk software for a small team.
Frequently asked questions
How do you write a customer service email?
Six parts, in order: a subject line with the identifying detail first, a greeting, one sentence proving you read their message, the answer or its honest status, the next step with a date attached, and then stop. Most replies fit in 100 to 180 words, and the part that usually pushes them over is an explanation of your internal process that nobody asked for.
How long should a customer service email be?
Between 100 and 180 words for a normal reply. Go longer only when the customer asked for steps they'll have to follow, and then number them so they can be worked through rather than read. Past that length the casualty is always the same one: the next step gets skimmed, it gets missed, and you write a second email anyway.
Should you change the subject line when you reply?
No. Gmail documents that "a conversation breaks off into a new conversation when the subject line changes", so tidying up a messy subject mid-thread splits the customer's history in two and leaves the next person on your team with an orphaned message. The only time to change it is when you actually want a separate thread.
How do you make templates feel personal rather than robotic?
Change one sentence that could only have been written to this person, and use contractions. Those two things do most of the work. The filled-in brackets don't count as personalization: a customer who gets "Hi Sarah" followed by four paragraphs of stock text knows exactly what happened.
What should a customer service email subject line say?
When you're starting a thread, the identifier goes first and the point second, because the customer reading it on a phone sees the opening words and nothing else. "Card declined on invoice 4417" survives a lock screen. "An important update regarding your recent payment" doesn't.