What makes a canned response sound canned?
Key Takeaways
For busy support leads: the problem with your macro library is almost never that it is too small. It is that half the entries say nothing, and the agent has to scroll past them to reach the four that work. Delete first, then write.
- 1Two facts or it does not ship. Every template must force the agent to insert at least two customer-specific details before it can be sent.
- 2Vague reassurance is worse than silence. "We are looking into it" generates a follow-up ticket. A named next step and a named time does not.
- 3Library size is a findability problem. Past roughly 30 entries, agents stop searching and start retyping, which defeats the point.
- 4Chat and email need different templates. The same information at email length lands badly in a chat window, and vice versa.
- 5Review quarterly or they rot. Old plan names, dead URLs and retired policies are the most common source of a confidently wrong reply.
Not the fact that it is reused. Customers do not object to reuse, they object to being answered without being read. A reply reads as canned when it contains zero information the sender could not have written before ever seeing the ticket.
That is a useful reframe, because it means tone is not the real problem. You can write a warm, beautifully phrased template and it will still land badly if it does not name the thing the customer actually asked about. Conversely, a blunt reply that says "your export failed because the date range exceeded 90 days" reads as human, because nobody could have written it in advance.
So stop editing your templates for warmth. Edit them for specificity. And keep them short: analysing 16 billion emails from 2 million users, Kooti and colleagues found that half of all replies are shorter than 43 words and that "the most likely reply length is only five words" (WWW 2015). That is consumer email rather than support email, so treat it as a directional finding, but a four-paragraph macro is already out of step with how people actually write to each other.
What is the two-fact test?
Here is the rule we apply to every template before it goes into a library: the agent must be unable to send it without inserting at least two facts specific to this customer and this ticket. One is not enough, because the first fact is almost always the customer's name, and a name is table stakes.
Fact one: who they are (name, plan, order number, account age). Fact two: what actually happened (the specific error, the specific charge, the specific date, the specific step that failed).
If a template can be sent with only a name filled in, it is not a template. It is a form letter, and the customer will treat it as one. The practical way to enforce this is to write placeholders that cannot be skipped without the sentence collapsing into nonsense. "I can see [specific thing you observed in their account]" is unskippable. "Thank you for your patience" is not.
Which canned responses should you delete today?
These six show up in almost every library we have looked at, and every one of them generates more work than it saves. Delete them and write nothing in their place.
| Delete this | Why it costs you | What to do instead |
|---|---|---|
| "Thank you for your patience." | Zero information. Usually sent when the customer has run out of patience. | Say what you are doing and when you will be back. |
| "We are looking into it." | Guarantees a follow-up ticket asking whether you are still looking into it. | Name the next checkpoint: "I will update you by 4pm even if I have no answer yet." |
| "Your feedback is important to us." | Reads as a form letter because it is one. | Say what specifically you did with the feedback, or say nothing. |
| "Please try clearing your cache." | Sent before reading. Customers who already tried it get angry. | Ask what they have already tried, then suggest the next step. |
| "I have escalated this to the relevant team." | Which team? When? Who owns it now? | Name the team and the expected response window. |
| "Is there anything else I can help with?" appended to an unresolved reply | Signals you consider the ticket finished when the customer does not. | Only use it after a confirmed resolution. |
The pattern is consistent. Each of these is a sentence written to fill space in a reply that had nothing to say. If a reply has nothing to say, the fix is to have something to say, not to pad it.
Greeting and acknowledgement templates
Keep these short. The greeting is not where you add value, it is where you avoid subtracting it.
First contact, chat
"Hi [Name], I can see you are on [plan] and reached out about [topic]. Give me one minute to pull up your account."
Email ticket acknowledgement
"Hi [Name], got your message about [specific issue in their words]. This is ticket #[number]. I am looking at [specific thing you will check] now and will reply by [specific time, with timezone]."
Returning customer
"Welcome back, [Name]. I can see we spoke on [date] about [previous issue]. Is this the same thing coming back, or something new?"
Out of hours
"Thanks [Name], our team is offline until [day, time, timezone]. Your ticket #[number] is queued. If this is blocking [specific critical workflow], reply with the word URGENT and it will be picked up first thing."
Troubleshooting templates that cut follow-ups
The measure of a good troubleshooting template is not how helpful it sounds. It is whether the customer replies again with the same question.
Known issue, fix in flight
"Hi [Name], you have hit [named bug]. We reproduced it on [date] and the fix is in [status]. Expected live: [date]. Until then, [named workaround]. I will message you here the moment it ships."
First report, need detail
"Thanks [Name], I have not seen this one before. To reproduce it I need three things: the exact error text, the browser and version, and roughly what time it happened. A screenshot covers all three if that is easier."
Cannot reproduce
"Hi [Name], I tried [exact steps you tried] on [browser/OS] and it worked on my end, which usually means something environment-specific. Could you try it in a private window and tell me whether it still fails? That narrows it to either a cached session or the account itself."
Step-by-step guidance
"Here is how to [task]: 1) [step], 2) [step], 3) [step]. The bit people usually get stuck on is [known sticking point], so if it fails there, that is expected and here is the fix: [fix]."
Handing over to a specialist
"Hi [Name], this needs someone with deeper access than I have. I am passing it to [named person or team] with everything you have told me, so you will not need to repeat yourself. They respond within [window]. I am still on this thread if anything changes."
That last one matters more than people think. Restating the problem to a second human is one of the most reliable ways to lose a customer's goodwill, so the template exists mainly to promise it will not happen. Our guide to human handoff goes deeper on transferring context cleanly.
Billing, refund and delivery templates
Money tickets punish vagueness harder than any other category. Every number must be real.
Refund approved
"Hi [Name], your refund of [exact amount] for [what it was for] is processed. Reference [number]. Your bank will typically show it within 5 to 10 business days, and it will appear on the card ending [last four]."
Partial refund
"Hi [Name], I have refunded [amount], which covers [precise thing being refunded, e.g. the 18 unused days of your annual term]. I have not refunded [the other portion] because [reason]. If you think that split is wrong, tell me why and I will look again."
Failed payment
"Hi [Name], the charge of [amount] on [date] was declined by your bank with the reason [reason if you have it]. Your account stays fully active until [date]. You can update the card at [link], and I will confirm here once it goes through."
Billing dispute
"Hi [Name], I pulled the charge: [amount] on [date] for [product and period]. Here is what triggered it: [specific cause, e.g. seat count went from 4 to 7 on the 14th]. If that does not match what you expected, tell me what you expected and I will reconcile the difference."
Delivery delay
"Hi [Name], order #[number] has not moved since [date] because [specific reason]. New estimate: [date]. I have already [specific action you took]. If that date does not work, I can [named alternative] instead."
How do you template an apology without sounding fake?
By removing the apology language and keeping the accountability. Most apology templates fail because they spend three sentences on feelings and none on facts. Invert that ratio.
Service failure
"Hi [Name], you were right, [specific thing] should not have happened. What went wrong: [one plain sentence]. What I have done: [specific action, already taken]. What happens next: [specific thing] by [specific time]."
Late reply
"Hi [Name], your message sat for [actual duration] and that is on us. Here is where it actually stands: [status]. I am handling it personally from here and will update you by [time]."
Frustrated customer, no answer yet
"[Name], I do not have the answer yet and I would rather tell you that than guess. What I know: [facts]. What I am waiting on: [specific dependency]. I will come back at [time] either way, even if the answer is still 'not yet'."
Customer has the wrong end of the stick
"Thanks [Name], I can see why it reads that way. [Feature] actually works like this: [explanation]. That said, if you expected [what they expected], that is a reasonable expectation and I have logged it. In the meantime, [workaround]."
Incident affecting them directly
"Hi [Name], between [start time] and [end time] on [date], [specific effect] affected your account. Root cause: [plain sentence]. Your data [was or was not] affected. What we changed so it does not recur: [specific change]."
Notice there is no "we sincerely apologise for any inconvenience caused" anywhere. Say sorry once, in plain words, then spend the rest of the reply on facts.
Closing, follow-up and feedback templates
Resolved
"Hi [Name], [specific issue] is fixed as of [time]. The cause was [cause] and we changed [change]. Closing this now, but replying to this email reopens it instantly if it comes back."
Workaround only
"Hi [Name], the permanent fix is not ready yet, so here is the workaround: [steps]. It has the limitation that [honest limitation]. I have flagged this thread to notify you when the real fix ships."
Expected behaviour, not a bug
"Hi [Name], I checked and this is working as designed: [explanation of why]. I know that is not the answer you wanted. The closest thing to what you are trying to do is [alternative], and I have logged your use case."
Nudge on a stalled ticket
"Hi [Name], I still need [specific thing] from you to move ticket #[number] forward. If it has resolved itself, no action needed and I will close it on [date]."
Feedback request
"Thanks [Name]. You asked about [topic] and I answered with [summary]. Did that actually solve it? One click: [good] / [not good]."
That last template is deliberately not a generic satisfaction survey. Asking "how did we do?" invites a rating of your personality. Asking "did that actually solve it?" invites a rating of the outcome, which is the thing you can act on.
How many templates should you actually keep?
Fewer than you have. Template libraries have a findability cost that grows faster than their coverage benefit, and most teams cross the break-even point without noticing.
Here is illustrative arithmetic. All inputs below are made up to show the shape of the trade-off, not measured from any study.
Say an agent handles 40 tickets a day. With a 20-template library, picking the right macro takes about 8 seconds: they know the list. With a 120-template library, it takes about 25 seconds, because they scroll, second-guess, and sometimes open two to compare. That is 17 extra seconds per ticket, 40 times a day, which is roughly 11 minutes daily or just under an hour a week per agent, spent choosing rather than answering. The 100 extra templates would need to save more than an hour a week each to pay for themselves, and the long tail of a macro library gets used a handful of times a month.
| Library size | Typical behaviour | Verdict |
|---|---|---|
| Under 10 | Agents remember all of them, heavy manual typing for edge cases | Fine for a team under 3 people |
| 10 to 30 | Sweet spot: searchable from memory, covers the repeating volume | Target this |
| 30 to 60 | Needs real folders and naming discipline to stay usable | Workable with maintenance |
| Over 60 | Agents stop searching and retype from scratch | Prune |
The counterintuitive move: when agents complain they cannot find the right macro, the fix is usually to delete templates, not to add better search.
Where does the template approach break?
Three places, reliably.
High-emotion tickets. A customer who has been failed twice already can spot a template at fifty paces, because the structure gives it away before the words do. For these, use the template as a checklist of what to cover, then write the reply from scratch.
Anything involving money you got wrong. Billing errors are the one category where a slightly-off template is worse than a slow custom reply. Wrong amounts in a reassuring tone destroy trust faster than a delay.
Products that change weekly. If your feature set moves fast, a 40-template library is a 40-item maintenance backlog. Teams shipping constantly are better off with 8 templates and a good internal doc.
There is also a quieter failure. Per-seat pricing pushes teams to run understaffed, and understaffed teams lean on unedited templates to keep pace. If your billing model punishes you for adding a teammate, that shows up in your reply quality eventually. That is one reason we chose flat pricing rather than charging per agent.
Where we are wrong about canned responses
We used to argue that AI makes template libraries obsolete, since a model can generate a grounded reply per ticket. That is too strong, and we have walked it back.
Templates do something a generated reply does not: they encode decisions. "We refund unused annual time, prorated to the day, no exceptions under $50" is a policy that lives inside a template. Generate that reply fresh each time and you get drift, where three agents give three slightly different refund policies in the same week. The template is not there to save typing. It is there to make the answer the same on Tuesday as it was on Monday.
The honest position is narrower than our old one: use generation for phrasing, use templates for policy. Where the answer is a company decision rather than a fact lookup, write it down and reuse it.
What to do this week
Open your macro list and sort by usage. Delete everything that has not been used in 90 days, plus every one of the six in the table above. Then take your top five by volume and run the two-fact test on each: can an agent send this with only a name filled in? If yes, rewrite it so they cannot.
That is a one-hour exercise and it will do more for your reply quality than adding thirty new templates.
If you want the AI to draft from your knowledge base and leave your team the edit, you can try it free and see how it handles your actual ticket mix.