By the third month on a support queue you can type the paragraph about where the order number lives faster than you can read the question that asked for it. That's the moment a canned response stops being a nice idea and starts being the difference between finishing at six and finishing at seven.
The awkward part is that most published example libraries are written for live chat. "Hi [name], thanks for holding, I'll be right with you" does nothing for a queue where the customer wrote at 23:40 and will read your reply on the train tomorrow. Email support needs blocks that carry a next step, a date, and a plain statement of what happens if nobody replies.
So this is thirty-two of them, grouped by the moment that fires each one, written for asynchronous email rather than chat. After the library there's the part nobody covers: where these blocks actually live in Gmail and Outlook, what each of those options can't do, and the routine that stops a library turning into a graveyard of wrong prices.
What a canned response actually is, and the two things it is not
A canned response is a saved block of text that a person picks and sends. Somebody reads the message, decides this block fits, drops it into the reply, fills in the brackets and hits send. The human judgment is the whole point of the mechanism.
That makes it a different thing from an automated reply, which a system sends when a condition is met and nobody looks at it first. Auto-replies, out-of-office notices and order confirmations belong to a different problem and a different set of failure modes. It's also a different thing from a full email you compose from a saved starting point: a canned response is a paragraph you drop into a thread that's already running, not a whole letter with a subject line and a signoff.
One naming quirk that sends people in circles: Gmail called this feature Canned Responses for years, then renamed it Templates. If you're searching Gmail's settings for the words "canned response" and finding nothing, that's why. Outlook never used the term at all and splits the job across two features. Both are covered further down.
If what you actually want is spoken text for calls and chat, conversational scripts for calls and chat is the other article. Everything below is written to be read, not said.
How to write a canned response worth saving
Writing the text is the cheap part. What makes a library work is knowing when each block applies, so when you build your own, give every entry these four things:
- A trigger. The exact situation that fires it. If you can't state the trigger in one line, the block is too vague to save.
- A body. Two to six sentences. Long enough to answer, short enough that pasting it doesn't commit you to a tone for the whole reply.
- Variables. Anything you must fill in before sending. Square brackets are the convention in both Gmail and Outlook because they're visually loud: an unfilled
[order number]in a sent message is embarrassing enough that people catch it in the draft. - An abort condition, where one exists. When to write from scratch instead. Plenty of blocks don't need one, and inventing one for symmetry is worse than leaving it out.
In the library below, each entry leads with its trigger, then the text, then whatever's worth knowing before you save it. Square brackets mark the variables throughout.
If you're still deciding which repetitive answers deserve a block at all, where canned responses sit in a support automation plan covers the audit and the sequencing.
32 canned response examples, grouped by trigger
Eight groups, four blocks each. Read the group you need and skip the rest.
Acknowledge and set expectations
1. First reply on a new request, before you've looked into it.
Thanks for writing in, I've got this. I'm looking into it now and I'll come back to you by [time or day] with either an answer or a status update. If anything changes before then you'll hear from me first.
The promise of "an answer or a status update" is what keeps this honest when the answer takes longer than you thought.
2. The message arrived outside working hours and you're picking it up now.
Sorry for the wait on this, your message came in after we'd finished for the day. I'm on it this morning and I'll have something for you by [time].
Send this when you open the queue, not automatically. An auto-reply saying the same thing at 23:41 gets ignored. This one arrives with a person attached.
3. It needs a specialist who isn't in.
This one needs [name or team], who's back on [day]. I've flagged it for them so it's first in line rather than sitting in the queue. If it gets urgent before then, reply here and I'll see what I can do in the meantime.
Don't send this if you could solve it yourself in ten minutes. Parking something solvable teaches a customer that your queue is a waiting room.
4. Second touch, still working, no news.
Quick update so you're not left wondering: this is still open and still with [team or person]. Nothing new to report yet. Next update from me on [day] whether or not there's progress.
The value is in the last sentence. A no-news update that commits to the next no-news update stops people chasing.
Ask for the information you're missing
5. No order number.
Happy to look at this. I need the order number to find it, which is in your confirmation email and starts with [prefix]. Send that over and I'll pick it straight up. If you can't find the email, the address you ordered with plus the rough date works too.
Always offer the second route. People who can't find an order number can usually tell you what they paid and when.
6. You need to see what they're seeing.
Could you send me a screenshot of the screen where this happens, with the whole browser window in shot rather than just the error? The parts around the edge usually tell me more than the message itself.
No variables in this one, so it's safe to bind to a keyboard shortcut if your setup allows it.
7. A bug report with no reproduction path.
To get this in front of the right person I need three things: what you clicked just before it happened, what you expected, and what you got instead. Your browser and version helps too, and you'll find it under [path]. With those I can reproduce it here and get it filed properly.
Skip the reproduction ask if the customer already described the steps. Asking twice reads as not having read the first message.
8. You're waiting on the customer and the thread is going quiet.
I haven't heard back on this, so I'll assume it sorted itself out unless you tell me otherwise. If it didn't, just reply here with [what you still need] and I'll pick it straight back up.
Send this once, not twice. A second nudge on a thread the customer has abandoned reads as pestering.
Order, delivery and account status
9. Ordered, confirmed, nothing visible yet.
Your order [number] is confirmed and in the queue to be packed. Nothing's shipped yet, which is why tracking shows nothing. You'll get a tracking link automatically the moment it leaves us, and that's usually [timeframe] after the order.
Fill the timeframe from your real current numbers, not from the number on the website.
10. Delayed, with a new date.
Your order [number] is running late. The new expected date is [date], and the reason is [reason]. I'm sorry, that's longer than we told you. If that date doesn't work for you, say the word and I'll cancel and refund it in full today.
Naming the reason is what separates this from the version customers hate. So is offering the exit before they have to ask for it.
11. Marked delivered, customer hasn't got it.
The carrier has this as delivered on [date] at [time], which doesn't help you much if it isn't there. Two things worth checking first: with neighbours, and anywhere your building leaves parcels. If it hasn't turned up by [date], reply here and I'll [replace it or open a claim], no further proof needed from you.
That last clause matters. A customer who has to prove a negative goes and tells other people about it instead.
12. Wrong item.
That's our mistake and I'm sorry. The correct item [name] is going out today on [service] and you should have it by [date]. For the one you received: [return instruction]. You don't need to wait for the return to reach us before the replacement ships.
Decoupling the replacement from the return is a policy decision. Get it agreed before you save this block.
Refunds, billing and adjustments
13. Refund approved.
Refund of [amount] is processed and on its way back to [payment method]. Card refunds usually take [timeframe] to appear, and that's the bank's end rather than ours, so it can look like nothing's happened for a few days. The reference is [reference] if you need to point your bank at it.
Give the reference unprompted. It's the thing people write back to ask for.
14. Refund outside policy.
I've looked at this properly and I can't refund it, because [specific reason tied to the policy]. I know that's not what you were hoping for. What I can do is [concrete alternative], and if you'd like me to escalate the decision I'll pass it to [role] with your case attached.
This is the block that repays the most editing. It has to name the actual reason rather than "our policy", offer something real, and give a route past you. Never send it if the thread has already turned emotional: that's a rewrite, not a paste.
15. Partial credit or proration.
I've credited [amount] back to your account, which covers [what it covers] from [date]. The rest of the period stays as it is because [reason]. You'll see it on your next invoice rather than as a separate payment.
Say where the money appears. Most billing confusion is about the where, not the how much.
16. Duplicate charge.
You're right, there are two charges of [amount] on [date]. One of them is an authorization that'll drop off on its own within [timeframe]. If both are still there after that, tell me and I'll refund one directly. I've made a note on the account so you don't have to explain this twice.
Don't promise the drop-off until you've checked which of the two it is.
Bug reports and known issues
17. Reproduced and filed.
Reproduced it here, so it's a real bug and not something at your end. It's filed as [reference] with the engineering team. I don't have a fix date yet, and I'd rather say that than invent one. In the meantime, [workaround if one exists].
Confirming it isn't the customer's fault does more for the thread than the ticket reference does.
18. Known issue with a workaround.
This is a known one and we have it logged. Until it's fixed, [workaround steps]. I've added you to the ticket, so you'll hear from me when it ships rather than having to check back.
Adding them to the ticket is a commitment. Only save this block if your process actually delivers on it.
19. Can't reproduce.
I've tried this on [configurations] and it works every time here, which usually means something specific to your setup. Could you try [narrowing step] and tell me what happens? Even "no change" is useful, it rules something out.
Framing a failed attempt as useful keeps people replying after the second round trip.
20. Fixed and shipped.
The bug you reported on [date] is fixed and live as of today. Thanks for the report, it was a good one: [what their information made possible]. Nothing for you to do, but do tell me if you still see it.
Most teams never send this one. It costs a single paste.
Feature requests and the honest no
21. Logged.
Good suggestion, and I've passed it to the product team with your description attached rather than a summary of it. I can't promise it gets built. What I can tell you is that requests with a concrete use case attached get taken more seriously, and yours has one.
Pass the customer's own words rather than your paraphrase.
22. Not planned.
I put this to the team and the answer is no, at least for the foreseeable future. The reason is [reason]. I'd rather tell you that than leave you waiting for something that isn't coming. If [alternative] would work for what you're trying to do, I can walk you through it.
A clear no that arrives quickly annoys people far less than a vague maybe that arrives for two years.
23. Already possible, another way.
You can do this today, just not where you were looking. Go to [path], then [step]. It isn't obvious, and the fact that you looked in [where they looked] first is useful feedback in itself.
Write the real path into the block rather than leaving it as a variable. This is one of the few entries where the specifics never change.
24. On the roadmap, no date.
This is on the roadmap and I don't have a date for it. Dates I gave you now would be guesses and you'd plan around them, so I'm not going to. I've tagged your request so you get told when it moves.
The refusal to guess is the credible part.
Handover, escalation and waiting on someone else
25. Passing to a colleague.
I'm handing this to [name], who knows [area] better than I do. They've got the full thread including what we've already tried, so you won't need to repeat yourself. They'll pick it up on [day].
"You won't need to repeat yourself" is only true if your handover actually carries the history. Fix that before you save the block.
26. Escalating to engineering.
This is beyond what I can fix from the support side, so I've escalated it to engineering as [reference]. I'm staying on the thread and I'll relay updates as they come. Realistically the first update will be [timeframe].
Escalation that reads as a transfer out feels like being dropped, so the staying-on-the-thread line does real work.
27. Waiting on a third party.
This one's with [supplier or provider] now and I'm chasing it. I don't control their timeline, which I know is frustrating when it's our problem from where you're sitting. I'll update you on [day] either way.
Don't name the third party if naming them shifts blame rather than explaining the delay.
28. Taking over a thread somebody else started.
[Colleague] has handed this to me and I've read the thread, so you don't need to catch me up. Where we're at: [one-line summary of the open question]. I'll have an answer for you by [day].
The summary is the proof you read it. Without it this block claims something the customer can't verify and won't believe.
Closing, follow-up and reopening
29. Resolved and closing.
This is sorted, so I'm closing it off. Recap in case you need it later: [one-line summary of what was done]. Anything else on this, reply here rather than starting a new thread.
Write the recap even when the fix was obvious. It's what makes the thread findable for the customer months later, when they search their own mailbox instead of yours.
30. Closing after silence.
I haven't heard back so I'm closing this one. That's not a full stop: reply any time and it reopens with everything still attached.
Deliberately shorter than everything else here. A long goodbye to somebody who has stopped reading is wasted work.
31. Post-resolution check-in.
Circling back on [issue] from [date]. Did [the fix] hold? If it did, you can ignore this. If it didn't, reply and I'll pick it straight back up.
"You can ignore this" is doing the work: people with nothing to report stop feeling obliged to write, so the replies you do get are the ones you needed.
32. Reopening after a late reply.
Got it, and this is open again. No need to re-explain anything, I still have the thread. Picking up from where we left off: [the last open question].
Never send this alongside a note about the ticket having been closed. The customer doesn't care about your ticket states.
Where canned responses live in Gmail and Outlook, and what each option can't do
This is the question every other example library answers with "save it in your help desk", which isn't much help if you don't have one. Here's what the platforms most small teams are already on will actually do.
Gmail. The feature is called Templates and it ships switched off. Google's own instructions are: "On your computer, open Gmail. At the top right, click Settings and then See all settings. At the top, click Advanced. Next to Templates, click Enable. At the bottom, click Save Changes." To save one, compose the text, then use More options, Templates, "Save draft as template", "Save as new template". The catch is on the same page, stated plainly: Google's page on creating a Gmail template says "You can only turn on and use message templates from Gmail on your computer." No mobile. If your queue gets answered from a phone on a Sunday, that's a real gap. Google documents no limit on how many templates you can keep, and the numbers circulating in forums aren't from Google.
Outlook. Two separate features do this job. My Templates is the panel in Outlook on the web and new Outlook, and it has a ceiling almost nobody hears about until they hit it: Microsoft's KB on templates that won't save states that "The My Templates app has a total size limit of 32 KB for all templates", after which you get "This template is too large to save. Please make it smaller, then try to save it again." That's a budget across the whole library rather than per entry, so thirty-two blocks with any formatting in them are genuinely within reach of it.
Quick Parts is the other route, and Microsoft's Quick Parts page documents it separately per client. In new Outlook and Outlook on the web you select content in a draft and use Insert, Quick Parts, "Save selection to Quick Parts". Classic Outlook has the same command plus an older "Save Selection to Quick Part Gallery" route, and one prerequisite that catches people out: "The email must be popped out to see the Insert menu." If you're replying in the reading pane, the menu you're looking for isn't there.
Sharing them with the team. In Gmail's built-in Templates, you can't. In Outlook there's a route, and reading it tells you what kind of route it is: you open the draft, choose Forward as OFT, which Microsoft's guide to sharing templates as .oft files describes as saving the draft as a file and attaching it to a new email. Each colleague then adds it themselves under Settings, Mail, Templates, Add, Add OFT. Microsoft adds that "To use .oft files in new Outlook for Windows and Outlook on the web, your account needs to have a qualifying Microsoft 365 subscription." Quick Parts has no sharing route documented at all; Microsoft only notes that in new Outlook, entries "are listed by account".
| Where it lives | Where it works | Shared with the team | Documented ceiling | Best for |
|---|---|---|---|---|
| Gmail Templates | Desktop web only, no mobile | No, stored per account | None published | One or two people on a Gmail address |
| Outlook My Templates | Outlook on the web and new Outlook | Only by mailing .oft files around | 32 KB for all templates combined | A solo Outlook user with short blocks |
| Outlook Quick Parts | Classic Outlook, new Outlook, Outlook.com | No sharing route documented | None published | Desktop-heavy classic Outlook users |
| Team snippet library in a shared inbox tool | Depends on the tool | Yes, one library | Depends on the tool | Three or more people on one address |
The honest verdict: for two people answering a mailbox, Gmail Templates is genuinely enough, and anyone telling you otherwise is selling something. What breaks it isn't volume, it's arithmetic. Every option above stores the text against one person's account, so two people running the same address maintain two libraries, and the moment one of them improves the refund block, the other keeps sending the old wording. Whether you've reached that point is mostly a question of headcount against volume, and the support team size calculator is a quicker way to work it out than a spreadsheet.
At three or four people that divergence becomes the actual problem, and it's where a team-level snippet library inside a shared inbox starts paying for itself: a tool like TriageFlow keeps the blocks on the mailbox rather than on the person, so the answer one person sharpened is the answer everyone sends.
Keeping the library from rotting
Libraries decay quietly. A price changes, a policy changes, a product gets renamed, and the block keeps going out for months because nobody owns it. Four habits are enough to prevent that.
Name entries by trigger, not by content. "Refund outside policy" gets found. "Refund 2 final v3" gets retyped from scratch by whoever can't find it, and now you have two versions.
Give each category an owner. One person per group, responsible for the wording being current. Categories without a name against them are the ones that go stale.
Tie the review to what changes underneath the text. Anything containing a price, a policy, an SLA or a product name gets reviewed when those things change, which means whoever changes them has to know the library exists. A calendar reminder is the fallback, not the mechanism.
Delete aggressively. A block used twice in a year isn't saving anybody time, it's making the list longer for everything else. And where an answer already exists as a help article, the response should link to it rather than restate it. Two copies of the same answer stop matching within a couple of edits, and your knowledge base is the version customers can find without emailing you. If you're weighing up whether this is all getting big enough to need real tooling, help desk software for a small team covers what that category actually costs to run.
When should you not use a canned response?
Skip the library whenever pasting would tell the customer something about how much attention they are getting. Four situations where that's the case.
The customer already received this exact text on this thread. Pasting it again says nobody read the reply.
Emotional charge is the second one. Somebody who's angry, or who has been let down twice, can tell a paste from a written reply, and a stock paragraph at that moment makes things worse rather than faster.
Third, and the most common: the block is only roughly right. Approximately relevant reads as not having been read, which costs you more than a slower answer that engages with the actual question.
And the giveaway that undoes all of it is a response answering a question the customer didn't ask. That happens when the trigger is fuzzy, which is why every entry above starts with the trigger rather than the text.
Frequently asked questions
What is a canned response?
It's a saved block of text that a support agent picks and sends into an existing conversation. The test for whether something qualifies is simple: a person chose it. That's what separates it from an automated reply, and it's why a badly chosen one is a human error rather than a configuration bug.
What is the difference between a canned response and an email template?
Length and where it goes. A canned response is a short block you drop into a thread that's already running; a template is a complete message you start a new email from, subject line included. Many tools store both in the same place, which is why the words get used interchangeably even though the jobs are different.
Does Gmail still have canned responses?
Yes, under a different name. The feature was renamed Templates and has to be switched on under Settings, See all settings, Advanced. Google documents it as working only in Gmail on a computer.
Can you share canned responses with your team?
Not in Gmail's built-in Templates: those are stored per account. Outlook has a route, though a manual one, where you forward a template as an .oft file and each colleague adds it themselves. A single library everyone answers from is a feature of the tool layer rather than of Gmail or Outlook.
How many canned responses should you have?
As many as you can keep current, which for most small teams lands somewhere between twenty and forty. One hard number is worth knowing: Outlook's My Templates stops accepting new entries once everything you've saved adds up to 32 KB. Past that constraint, what limits you is how much you can realistically review, not how much you can store.