Canned Responses: Examples From Real Teams, Good and Bad

Search for canned responses examples and you get lists of templates written for the page they sit on. I counted about 785 across the 24 ranking pages that have any. The only real ones are a few help desk vendors quoting their own replies; none quotes another company's. This page does it the other way round. Every quoted canned response below is real, taken from a public handbook, a triage guide or a product's own documentation, with the team that uses it named. The rewrites and two examples are ours, and they are labelled.

A canned response is a reply written once and sent many times. It covers the welcome a project sends on a pull request, the receipt a help desk mails when a ticket arrives, and the three sentences a support agent pastes many times a day about password resets. Help desks call them macros, saved replies, snippets, message templates or shortcuts.

What is a canned response?

A canned response is a pre-written message that a person or a system sends in reply to a situation that keeps coming up. It can be pasted by hand, inserted with a shortcut, attached to a label, or fired by a rule when a ticket arrives. The sender's name may be on it or not.

Two things decide whether one lands. The first is whether it fits the message it answers. The second is whether it tells the reader what happens next. Most of the real examples below do both, which is a selection effect: teams that publish their replies have usually thought about them.

The name varies by product. Zendesk and Intercom call them macros. Help Scout calls them saved replies. HubSpot and Zoho Desk call them snippets, Front calls them message templates, and Crisp calls them message shortcuts. In Zendesk a macro can also change the ticket's status, tags or assignee along with the text, and KDE's triage set pairs nearly every reply with a line like "Then mark it as NEEDSINFO BACKTRACE", so one step answers the reporter and files the ticket.

Canned responses examples from real teams

These are quoted as they appear in the source, with the team's own placeholders left in. Line breaks are the original's, and where a reply goes on past the quote I say so.

Welcoming a contributor

The Rust project's bot posts this on a pull request when it assigns a reviewer:

Thanks for the pull request, and welcome! The Rust Project has assigned {reviewer} to review your changes, you should hear from them (or someone else) within the next two weeks.

Thirty words, a named reviewer, a deadline, and an honest hedge in "(or someone else)". It is the best-written canned response I found, and it is sent by a bot.

Help Scout's support team keeps a greeting as a personal text expander snippet rather than a saved reply:

Kristi from the Help Scout support team here!👋

Their saved replies carry no greeting or sign-off at all, for a reason that comes up later in this post.

Asking for more information

LibreOffice's QA team keeps a page of pre-written responses for bug triage. This one asks for a sample document:

Hello [user's name],

Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug.

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.

(Please note that the attachment will be public; remove any sensitive information before attaching it.

See <https://wiki.documentfoundation.org/QA/FAQ#sanitize> for help on how to do so.)

One ask, the status change explained, how to flip it back, and a warning the reporter would not think of on their own. KDE's version of the same request is shorter and makes the reason explicit:

If something crashed, we need a backtrace of it so we can figure out what's going on. Can you please attach a backtrace of the crash using the coredumpctl command-line program, as detailed in https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl?

Thanks!

Compare the opening of VS Code's reply when an issue is missing information:

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.

The reply goes on to point Copilot issues at a separate guidelines page and signs off "Happy Coding!". It is polite, but "some basic information or in some other way" means the reporter has to guess what was missing. The LibreOffice and KDE replies each name the one thing they need.

Confirming a bug

LibreOffice again, and this is the whole thing apart from the build details pasted under it:

Hello [user's name],

Thank you for reporting the bug. I can confirm that the bug is present in master.

Nothing else is needed. The reporter wanted to know whether anyone could reproduce it, and now they do.

Saying no to a request

VS Code closes out-of-scope issues with a reply that opens:

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

It then points at the project's roadmap and issue guidelines and signs off "Thanks for your understanding, and happy coding!". "We don't plan to address it" is a sentence many teams avoid writing, and VS Code writes it, then leaves the door open. The wont-fix variant keeps only the first clause and the sign-off: "We closed this issue because we don't plan to address it. Thanks for your understanding, and happy coding!" Without the invitation to disagree, "Thanks for your understanding" asks for something the reply has not earned.

KDE's triage guide has a decline written in the first person:

This is the kind of thing where there are arguments to be made one way or another, but if nobody submits a patch for it, very likely nothing will happen. Therefore we don't need to track this with a Bugzilla ticket. Feel free to submit a patch to add the feature if you can…

The sentence continues with an acceptance that time is limited and the ways to improve things are not. WooCommerce closes feature requests with a label called "needs: votes", and the reply says what the label means: "it doesn't fit in with our current priorities for the project", followed by "we are going to close this issue with the votes needed label and evaluate over time if this issue collects more feedback." It is a soft no with a mechanism attached. If the requests you decline arrive by email rather than GitHub, the feature request email templates post covers that side.

Sending someone to the right place

KDE's reply when a crash is in NVIDIA's proprietary driver:

The crash backtrace indicates that the problem is in the proprietary NVIDIA drivers.

Please report this issue to the NVIDIA folks, either by sending an email to linux-bugs@nvidia.com or making a post at https://forums.developer.nvidia.com/c/gpu-graphics/linux. It would be helpful to the NVIDIA developers if you could run nvidia-bug-report.sh and attach the resulting file in your report. Thanks!

The diagnosis in one sentence, then the exact address, the forum and the script to run. The WordPress.org support forums do the same for commercial plugins, and they explain the rule instead of citing it: "Forum volunteers are also not given access to commercial products, so they would not know why your commercial theme or plugin is not working properly."

Following up after silence

Node.js marks issues stale with the durations in the text:

This {0} has been marked as stale due to 90 days of inactivity.

It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

Ninety days, thirty days, and the one action that keeps it open. KDE's version owns the delay instead of blaming the reporter for it:

Thank you for the bug report. Unfortunately we were not able to get to it yet. Can we ask you to please check if this is still an issue with Plasma XXXX (the latest released version).

Closing

Node.js again, when a stalled issue finally closes:

Closing this because it has stalled. Feel free to reopen if this issue/PR is still relevant, or to ping the collaborator who labelled it stalled if you have any questions.

Thirty words: why it closed, how to undo it, and which person to ask. VS Code's duplicate close is in the same spirit, with a search link so the reporter can find the original: "We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues."

Moderation

AutoReviewComments, a browser userscript that Stack Exchange reviewers use to post comments from a list, ships with this one:

Please don't add "thanks" as answers. Invest some time in the site and you will gain sufficient privileges to upvote answers you like, which is the $SITENAME$ way of saying thank you.

It corrects and explains the norm in the same breath. KDE has one for a newer problem, a reply that was pasted from a language model:

Just so you know, copy-pasting LLM output into a conversation with another human is considered rude.

If you must use an LLM, synthesize its output into your own conclusion and then write it in your own words when communicating with other people.

It goes on to say that writing in your own language and machine-translating it is fine, as long as your own words are in there somewhere.

Out of office and billing: ours

No team I found publishes the text of its out-of-office reply, and the only billing reply in a public source is Crisp's example refund shortcut, eight words long: "You can request a refund within 14 days." So these two are written for this post and are not quoted from anyone. The bracketed parts are yours to fill in, and the promises in them are only worth making if they are true for your team.

Out of office, sent once when the whole team is away:

We're away until [day] at [time, timezone]. Your message is in the queue and nothing you sent is lost.

If you're locked out of your account, reply with "locked out" in the subject line and [who] checks for those.

An unexpected charge:

The charge on [date] is the [plan] renewal for [workspace]. The receipt is attached.

If you meant to cancel before it renewed, reply and say so and I'll refund it. To stop the next one, [where to cancel]. [What happens to your data after that.]

What it is like to receive a canned response

The pages of canned response examples I read are all written for the team sending them. Here is the other side, in the words people used on Hacker News and in support forums.

The complaint that comes up most often is that the reply shows the message was not read. "Heroku support answered my support ticket within a few hours (so good on them) with a canned response that pointed me to the article I had already referenced to them (not so good)." Another: "both times I got the same 'you should use the password recovery procedure' template response, even though I explained it doesn't work." And: "You know what makes support stand out, in a positive way? Actually reading my question."

A GitLab support engineer wrote up an automated reply that went out on a customer's ticket under their own signature. It "recommended steps the customer had already tried, making it seem that we offered a canned reply without reading the context of the customer's issue." It also "did not state that it was an automatic reply, and it used my signature, making it seem the reply was written by a human." Both complaints came from the person whose name was on the reply.

The second thing people notice is scripted empathy. In a Hacker News thread about a library of support phrases, a comment with seven replies said: "reflecting what I said back to me and telling me how frustrating it must be. No shit, I know that. Don't make me read that, just tell me how the problem can be solved." Someone else: "Might be a British/American difference but I found all of these incredibly patronising and insincere." When an official Zoho account replied in another thread on the same site, one reader answered "Downvoted for: (a) Sounding like a canned response", and Zoho came back with "This was definitely not a canned response, but we can understand why it was seen that way." A hand-written reply can read as canned when it uses the phrases a template would.

Stack Overflow had this argument at scale. Review-queue comments are posted from a fixed list, and a question on the meta site with 131 votes described new users who took them personally, some going "as far as arguing, revenge voting, and so on." Stack Exchange's answer in 2015 was to make every comment posted from a queue carry a link to the review task, so the reader can see it came from a process. The Discourse staff who asked for templates made the same point from the sending side: a consistent, pre-defined response is "faster for staff and more informative for forum members" than a vague reaction. Three of freeCodeCamp's closing templates say it in the text, "This is a standard message notifying you that", which is honest and which also tells the reader not to expect a reason.

How to write a canned response: four rewrites

No ranking page shows a weak template beside its rewrite. GitLab's support handbook does, with its own replies. It gives the robotic version first:

Thank you for contacting support. We can help you with this. It looks like you are asking for help with resetting your password…

Then the version it wants: "Ah, sorry to hear that you lost your password. I've issued a password reset and you are good to go. In the future, you can use this link: [link] Let us know if there is anything else we can help with." The second one has done the thing and says so. The first one has only classified the ticket.

Here are three more, on replies quoted earlier. The rule for each: nothing is added that the sender does not know. A rewrite that promises a reply time the team cannot keep is worse than the original.

TypeScript's close. The TypeScript repository closes labelled issues with a workflow that posts:

This issue has been marked as "$1" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

$1 is the label, for instance "Working as Intended". "House-keeping" tells the reporter their report was clutter, and nothing says what to do if they disagree. Same facts, rewritten:

This issue was labelled "$1" and has had no activity since, so it has been closed automatically. If something has changed, leave a comment and ask for it to be reopened.

Zendesk's default receipt. Zendesk's default trigger emails every requester this when a ticket arrives:

Your request ({{ticket.id}}) has been received and is being reviewed by our support staff.

To add additional comments, reply to this email.

Passive voice, a ticket number where the greeting should be, and "is being reviewed" when it has not been opened yet. Zendesk does not know your reply time or who will answer, so the rewrite can only say what the trigger knows:

Hi, your message is in our queue as request {{ticket.id}}. Replies come to this thread, and if you want to add anything, reply to this email.

probot/stale's default. The default text of a stale bot installed on many GitHub repositories:

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

It thanks the reader in the sentence after threatening to close their issue, gives no reason, and leaves them to infer that a comment keeps it open. Node.js's version, quoted above, fixed this with two numbers and one instruction. The typescript-eslint project went further and wrote the close itself, by hand, with the reporter's name in it:

Closing this issue as it's been stale for ~6 weeks without activity. Feel free to reopen @{{ author }} if you have time - but no worries if not! If anybody wants to drive it forward, please do either post here or in a new issue with the info we asked about. Thanks! 😊

The pattern across all four: say what happened, say what happens next, say what the reader can do about it, and cut the sentence that is only there to be polite.

Canned responses for customer service: how real libraries are run

Help Scout's support team has written up how it runs its own library, and the numbers are useful because few teams publish them. "We currently have over 300 saved replies, so it's important to keep things organized." Their rules: "We don't append greetings or closings to our saved replies, so they're easy to pop into any section of a reply we're crafting." "If a teammate has already sent a particular saved reply to a customer, we'll make sure not to send it again." Their don't list includes "Make product development promises" and "Include greetings or sign-offs", and they clean the library up about once a year.

Gorgias formats its chat macros the same way: "no greeting, no sign-off/signature, and only short, impactful sentences." Buffer went further in 2016 and introduced a weekly snippet-free day because "we've started to feel that perhaps we're leaning too heavily on snippets and losing a bit of the personal touch in our responses."

The teams that publish their templates warn against leaning on them on the same page. Fedora's stock-response page says: "If you can be more specific than this stock response, that would be very helpful for the reporter and also more polite." GitLab's handbook says above its email templates: "Whenever possible, it is strongly encouraged that each email message be customized for each individual & circumstance." And GitLab's support workflow goes one step back: "If you find yourself wanting to use canned responses, or are saying the same things over and over, it's probably an opportunity to improve our process."

The people running large libraries have a different problem, which is finding and trusting what they have. On the Zendesk community, one admin wrote: "My team alone has 313 active macros in use, but there's really no workflow to make sure that they are still accurate and updated." Another: "Agents make macros with incorrect settings (not adding a tag, removing all tags, changing Brand, etc) and we are not able to locate the macro until it is a problem." On a request to let admins see agents' personal macros, the answer with the most likes was: "I'd prefer they create them as personal macros, then I can review them and promote the macro to a group if it looks safe." The request to report on which macros get used, and which ones correlate with bad satisfaction scores, was posted in 2017 and has 127 upvotes.

Three product details bite people who did not read the docs. Intercom's macro search "only matches on the macro title", not the body, and "If a teammate's role changes (e.g., from Full to Lite seats), their personal macros are permanently deleted." Zendesk warns that applying macros with placeholders to problem and incident tickets makes it "easy to accidentally populate the wrong values in ticket comments." And a Zendesk user noted that the obvious greeting placeholder "works, but scrapes the full name, which sounds awkward."

Where canned responses live in each help desk

What the feature is called, the plan it starts on, and the limit, from each product's documentation in October 2026. "Not stated" means the page does not say.

Zoho Desk's snippet names cannot contain a space. Front cannot move a template between private and shared; you copy the text and recreate it. HubSpot snippets are capped at 2,500 characters. Before you pick a tool on these numbers, the help desk pricing comparison has the plan prices next to them.

When not to send a canned response

The strongest argument against canned replies on Stack Overflow's meta site, with 69 votes and the accepted answer, is: "If you bother commenting to a post, take the time and put the effort to write a comment that's specific, relevant and meaningful." The position a support lead took in a Hacker News thread, and others agreed with: "I'm all in favor of reusing my own replies to customers as long as I customize them. … save the typing, but not the thinking." The reply agreeing with it: "There's no reason why I should type the description of a Request Timeout error 15 times per day."

Both are right, and the cases where a template is wrong are specific.

There is a fourth option beyond write it, paste it, or ignore it, and it comes from a comment on a Hacker News story with 570 points: "the ideal solution is a combo of continually improving documentation as common questions emerge and a 'saved replies' feature." GitLab's handbook says the same thing about its own queue: a reply you keep sending is a sign that something earlier in the process could answer the question first.

UserJot has no saved replies feature. What it has instead is Juno, the support agent in our shared inbox, who answers from your docs and the sites you point her at. When a customer asks for a feature, she searches your feedback board and, once they confirm, files the request or adds their vote. When she is not sure, or the customer asks for a person, she hands the thread to your team, and your team writes that reply by hand with the conversation in front of them. The questions your docs already answer stop needing a person to type the answer.

app.userjot.com

UserJotPro

New Request

Public Board

Conversations

Queue

Open5

All

Visitors

Requests

Pending6

In Review3

Planned12

In Progress4

Workspace

Roadmap

Changelog

Members

Docs

SupportOnline

AllQueue

Search conversations…

PS

Priya Shahnow

Is there a way to export all the votes to a CSV?

Alex Martin4m

Done. Your vote is in and you’re following it, so you’ll get a note the day it goes live.Resolved

V4

Visitor 45802712m

Hey, how does pricing work for bigger teams?

Marcus Lee1h

The widget isn’t showing up on our docs site.

SR

Sofia Ramos3h

You can turn those off under Settings, then Notifications.Resolved

DK

Daniel Kim5h

Can Juno answer our customers in Spanish?Resolved

EW

Emma Wilson1d

Could we get SSO on the Pro plan?

NF

Noah Fischer1d

Thanks, that fixed it!Resolved

LN

Lena NovakSep 22

Your API key is under Settings, then API.Resolved

OH

Omar HaddadSep 21

Is there a Zapier integration yet?Resolved

GL

Grace LiuSep 20

Love the new changelog page.Resolved

Alex Martin

Resolved

Today

Any plans for a mobile app?

4:07 PM

Good news, that’s already on our board. Want me to add your vote so you hear when it ships?

Mobile app

The whole web app on iPhone and Android, with push notifications when something needs you.

Planned

128

4:07 PM

Yes please!

4:08 PM

Done. Your vote is in and you’re following it, so you’ll get a note the day it goes live.

4:08 PM

Juno resolved this conversation· 4:09 PM

Reply to Alex…

Reply

The inbox above is the live chat and shared inbox in UserJot. The small mark before a preview means Juno wrote the last message. The shared inbox guide covers what to do with the threads she hands over, and teaching Juno covers how to close the gap that let a question through.

Frequently asked questions

What is a canned response?

A canned response is a message written once and sent many times, by a person pasting it or by a rule that fires when a ticket arrives. Help desks call the feature macros, saved replies, snippets or message templates.

What is the difference between a canned response and a macro?

A canned response is the text. A macro, in Zendesk, is the text plus the actions that go with it: a status change, a tag, an assignment. Some products use the two words for the same thing.

How many canned responses should a support team have?

As many as the team can keep accurate. Help Scout's support team runs over 300 and cleans them up about once a year; a Zendesk admin with 313 reported having no workflow to keep them current. The number matters less than whether each one has an owner and a title people can find.

Should a canned response say that it is one?

Say it when the reply is automated and nobody read the message, the way Stack Exchange links review-queue comments to the review task and freeCodeCamp's closing templates say "This is a standard message notifying you that". When a person chose the reply after reading the thread, the reply does not need a label; it needs to fit.

Can customers tell when a reply is canned?

Often. What they complain about is a reply that repeats steps they said they tried, links a page they already cited, or answers a different question. The same reply sent to a message it fits is read as a quick answer.