What Canned Responses Are For, and Not For
Monday, 08:50, at Stonebridge Insurance. Tomas opens the queue and finds fourteen tickets that arrived over the weekend. Nine of them need the same first message: we have it, a person is looking, here is when you will hear more. He types it by hand for the first one, slightly differently for the second. By the third he has forgotten to say when he will come back. By the fourth he is copying the second one and changing the name, and he gets the name wrong. Ticket 5108, from a claims handler whose laptop was taken from her car on Saturday, gets the same four lines as the request for a second monitor. At 09:20 he has sent nine acknowledgments and none of them has told anyone anything.
A canned response is a message written once, in advance, for a situation that comes up again and again. It is dropped into a reply so it does not have to be typed again. Your tool may call it a template, a predefined reply, a saved reply or a macro; the thing is the same. This article is part of our Templates & Canned Responses Done Right series. It is about the question that comes before writing any of them: what are they for, and which messages should never be one.
It starts with what a template buys a desk and why those gains are real. Then comes where the robotic failure comes from, since it is not from the template itself. Next are the two kinds of message that are the template's natural home, and the messages that must never be canned. It explains why each of those messages fails when it is canned. A decision table for the grey area between follows, then how to write the rules down so the whole desk uses the same ones. A short war story and the canned-response purpose card to copy finish the article.
What a Template Buys You
A template buys three things, and the first is the one everybody names: speed. The acknowledgment Tomas typed nine times takes about ninety seconds by hand and about ten seconds from a template, once the name and the time are changed. Nine tickets is twelve minutes saved on a Monday morning, and the saving repeats every day the desk is open. Speed is a real gain and it is the least important of the three. Twelve versions of that first message, written out with the slots marked, are in Ticket Acknowledgement Templates.
The second thing is consistency, which means that every requester gets the same quality of message regardless of who is on the desk or how tired they are. The acknowledgment the newest technician sends at 16:55 on a Friday is as complete as the one the lead sends at 09:00 on a Tuesday. Requesters notice consistency without being able to name it. What they say is "IT always gets back to you", and what they mean is that the desk has never once sent them a message with the time missing.
The third thing is completeness, and it is the one that prevents incidents. A good template is a checklist disguised as a message. The "resolved" template has a line asking the requester to confirm and a line saying how to tell if the problem comes back. It has a line saying the ticket will close on a date if nothing is heard. Somebody wrote those lines once on a calm afternoon. Tomas, writing by hand at 08:53 with fourteen tickets waiting, would include two of them. The template does not get tired, and it does not forget the time. (It also does not get the name wrong. That part is still on you.)
Put together, the three gains mean the desk's routine messages are written by its calmest version of itself. That is the whole case for templates and it is a strong one. Every argument against them, and there are good ones, is an argument against a template badly written or badly sent, not against writing the routine message once. The rest of this article is about the difference.
Where the Robotic Failure Comes From
The robotic failure is the message that reads as though nobody wrote it and nobody read it. "Dear Valued Customer, thank you for contacting the IT Service Desk. Your request is important to us and has been logged under reference 5108. A member of our team will be in touch shortly." Every requester has received one. Most have received one in reply to something that mattered to them. That is why the word "canned" is an insult in most offices. It is why a manager, told the desk is "introducing templates", will pull a face.
The failure has three causes and the template is not one of them. The first cause is that the text was written for nobody. The author sat down to write a message to everyone who might ever raise a ticket, and a message to everyone is a speech. Nobody writes "I hope this message finds you well" to a colleague two desks away; they write it to a crowd they cannot see. The second cause is that the text has no slot for the person. There is nowhere in it for the requester's name as they signed it, their words for the problem, or the time they will hear back. So there is nothing a technician can change, so nothing gets changed. The third cause is that the message was sent without being read. The technician inserted it, saw the shape of a reasonable message, and pressed send. Nine times.
Notice what is not on the list. The failure is not caused by speed, or by the message being the same as yesterday's, or by the requester knowing it is a template. Requesters do not mind templates. They mind being treated as the template's occasion rather than its reader. A message that says "Hi Dana, thanks for reporting the dock 3 scanner losing its connection; I will have a look this morning and update you by 12:00 either way" is a template with three slots filled. Nobody who receives it will call it canned. The slots did the work. How to write a template with those slots in it is the subject of Writing a Template That Does Not Sound Canned. This article is about choosing which messages get one.
The Routine Message Is the Template's Home
A routine message is one the desk sends in the same shape many times a week, where the shape is the point and the details are small. The acknowledgment. The request for the one missing piece of information. The "still ours, no news yet, next update Thursday" status line. The "this is fixed, please confirm" at the end. The "we have not heard from you, closing on Friday unless you reply". Count them on your own desk for a week. You will find that most of what the desk writes is one of about twenty shapes. The full list is in The Twenty Templates Every Help Desk Needs.
The routine message is the template's home for two reasons. First, the shape matters more than the prose. An acknowledgment exists to tell the requester three things: that a person has it, what happens next and when they will hear more. Any wording that delivers the three is good enough. Nobody is moved by an acknowledgment. They are reassured by one, and reassurance comes from the facts in it. Second, the routine message is where the desk is most tired. It is written at 08:53 with fourteen tickets waiting or at 16:55 with a bus to catch. Those are the moments when a hand-written message loses its time, its ask, or its name. The template holds the shape when the technician cannot.
There is a quiet third reason. The routine message, written by hand, drifts. Five technicians write five acknowledgments and over a year the five diverge until one of them says "we'll get to this when we can". That is honest and also the sentence that ends a desk's reputation in a department. A desk that speaks in one voice is a desk that agreed on the words once. The argument for that, and the way to do it with five people, is in One Voice Across Five People. Templates are how the agreement is kept without a meeting.
Required Content Is the Second Home
The second kind of message that belongs in a template is the one with required content: lines that must be present every time for a reason beyond politeness. The password-reset confirmation that must tell the requester the desk will never ask for their password by e-mail. The out-of-scope decline that must name where the request should go instead. The planned-maintenance notice that must carry the start time, the end time, what will be unavailable and who to contact. The "resolved" message that must say how to reopen. Each of those lines exists because somebody, once, left it out and paid for it.
Required content is a template's natural home because memory is the wrong tool for it. A technician who has sent the maintenance notice forty times will, on the forty-first, leave out the end time. Not through carelessness but because the forty previous times went fine and attention moves on. The template carries the line so the technician does not have to. This is the same argument as the checklist in a cockpit or an operating theatre, and the people who use those are not less skilled for it. They have simply met the forty-first time.
The test for whether a message has required content is to ask what goes wrong when a line is missing. If the answer is "the requester asks a follow-up question", the line is useful but not required. If the answer is "the requester does something harmful, or the desk is exposed, or a rule is broken", the line is required. In that case, the message gets a template whether or not it is routine. The security caution on the password-reset message is the clearest case. It is sent many times a day, it is never read with interest, and the one time it matters it matters completely.
Remember: a template is for the message whose shape matters more than its prose, or whose lines must be present every time. It is never for the message where the requester needs to know that a particular person read their particular ticket and is answering it.
The Messages That Must Never Be Canned
Some messages fail precisely because they arrive in a shape the requester has seen before, and no amount of slot-filling saves them. The first is the apology for a real failure by the desk. The ticket was lost for three weeks, the fix broke something else, the technician promised Tuesday and it is Friday. A requester in that position is reading for one thing, which is whether a person understands what happened to them. A sentence they have seen on a previous ticket tells them nobody does. "We apologise for any inconvenience this may have caused" is the most expensive sentence in support. It is sent when the desk is already in debt and it adds to the bill.
The second is the reply to someone who is angry. An angry message is a test of whether the desk is a person or a wall, and a template answers the test on the first line. The reply must quote back what they said, in their words, and name the specific impact on them before it says anything else. That cannot be written in advance because the words and the impact are theirs. The discipline for that moment is in The First Sixty Seconds. A template can be open in another window as a reminder of the shape; the message is typed.
The third is specific bad news. "Your laptop cannot be repaired and the files on it that were not on the shared drive are gone." "The approval was declined." "The software you need is not supported and we cannot install it." Each of these is a message one person needs to hear from another person, and each has consequences for the requester that the desk should show it has thought about. The shape of a good decline is teachable, and the Saying No Professionally series teaches it. The message itself is written fresh, every time, because the thing being declined is different every time.
The fourth is the second message in a thread that has already gone wrong. Suppose the requester has replied "did you read my ticket?", or "this is the third time I have explained this", or "I have already sent that". The next message from the desk cannot be a template, because a template is what caused the reply. The only acceptable next message is one that proves a person has now read everything, and the proof is in the specifics. I have watched a technician answer "did you read my ticket?" with the missing-information template a second time. The requester's third message was to the technician's manager, and it was not a template either.
The fifth is anything addressed to a requester the desk is talking to for the first time about a sensitive matter. That might be a suspected security incident on their account, a complaint about a colleague's access, or a question about monitoring. Those conversations set the tone for everything after, and a canned opening sets it wrong. Write the first one by hand. If the matter turns out to be routine, the templates can come in from the second message onward.
Can, Can With Care, Never
Between the routine message and the never list there is a grey area, and the table below is how to decide inside it. "Can" means a template with its slots filled is the right message. "With care" means a template is a reasonable starting draft but the message needs a sentence or two written for this ticket before it goes. The technician should expect to spend a minute rather than ten seconds. "Never" means start from a blank reply. The last column says what changes about the message in each row, which is the practical part: it tells the technician what to type.
| Message | Template? | Why | What must be written for this ticket |
|---|---|---|---|
| Acknowledgment of a new ticket | Can | The shape is the point; the facts reassure | Name, their words for the problem, the time of the next update |
| Request for missing information | Can | Routine, and the one ask is clearer from a template | Name, exactly what is missing, why it is needed |
| Status update with no news | Can | Routine; prevents the chase | What was done since last time, next update time |
| Resolved, please confirm | Can | Required content: how to tell, how to reopen, when it closes | What was wrong, what was done |
| Cannot reproduce | With care | Easily read as "it works for me" | Exactly what was tried, and the one thing to try together next |
| Out of scope | With care | Required content (where to go instead) but the reason is specific | The specific thing declined and the specific alternative |
| Delay: the plan has changed | With care | Trust is already dented; needs a reason in plain words | Why, the new time, what happens if that slips too |
| Apology for a desk failure | Never | The requester is reading for understanding, not shape | All of it |
| Reply to an angry requester | Never | A template answers "are you a person?" with no | All of it, quoting their words first |
| Specific bad news | Never | Consequences for one person deserve one person's words | All of it |
| Second message after "did you read my ticket?" | Never | The template caused the question | All of it, with proof of reading |
| First contact on a sensitive matter | Never | The opening sets the tone for the whole conversation | All of it |
Two rows deserve a note. "Cannot reproduce" is the template most often sent when it should not be. The honest version of it is uncomfortable to write and the template offers a way to avoid the discomfort. The template is fine as a skeleton. The message is not finished until it lists what was actually tried, in order, and proposes a time to look at the problem together. "Delay" is the opposite case: a template is useful there because a technician who has just missed a promise is embarrassed and will otherwise write something too short. The template's job in that row is to make sure the new time and the reason both appear. The honest way to set the new time belongs to the Managing Expectations series, and the template only has to leave room for it.
The grey area moves with the desk. A desk that has just recovered from a lost-ticket episode in one department should treat every message to that department as "with care" for a month. The trust is not there to be spent. A desk whose requesters are mostly its own colleagues of ten years can be more relaxed than one supporting a hundred shop managers it has never met. The table is a starting position, and the way to find out where your own line is sits at the end of this series, in the numbers and in the comments.
Writing the Rules Down for the Desk
A desk that uses templates needs about five rules, written where the templates live, so that a new technician reads them before sending their first one. The rules are short because long ones are not read. I have seen an eleven-page "Communication Standards" document whose only measurable effect was that nobody opened the folder it lived in. The five below are the ones that survive contact with a busy Monday.
First, every template has a purpose and a trigger, both written at the top of it. These are what the message is for, and the moment in a ticket's life when it is the right one. A template without a trigger gets sent at the wrong moment, and the acknowledgment sent in reply to a reply is the usual example. Second, three things change every time: the name, the specific thing, and the time. A template sent with any of the three still in brackets is a template sent unfinished, and it is the sender's message, not the template's. Third, read it before you send it, the whole thing, as the requester will. Ten seconds. The routine for doing all this quickly is in Personalizing a Canned Response in Ten Seconds.
Fourth, the never list is a list, and it is pinned next to the templates. Apologies for desk failures, replies to angry requesters, specific bad news, the second message after a complaint about the first, and first contact on a sensitive matter are typed. Fifth, the library has an owner, and a template nobody owns is retired. Most help desks, QuerySolv included, keep predefined replies that can be personal to one technician or shared across the desk. The shared ones are the desk's voice, so somebody has to be responsible for what that voice says. Keeping the library alive is a job in its own right and it has its own article later in this series.
Write the five on one card and put it at the top of the library, where it is read, rather than in a policy folder, where it is filed. The purpose card at the end of this article is that card. It is deliberately dull. The interesting messages are the ones it tells you not to can.
A Short War Story: The Weekend Acknowledgment at Tollgate Foods
At Tollgate Foods, a chilled-food distributor, every new ticket received the same automatic acknowledgment: "Thank you for contacting IT. Your request has been logged and will be handled in order of receipt." On a Friday at 17:40 a depot manager called Hugo raised a ticket saying the cold-store temperature-logging PC had stopped recording. At a food business that is a compliance matter. He received the acknowledgment and nothing else. The technician who picked it up within twenty minutes and began fixing it remotely did not send a message of his own. Hugo read "in order of receipt" as "nobody is looking" and could not reach anyone by phone. He had his weekend staff log temperatures by hand on a clipboard, which they did with a gap on Sunday morning. On Monday the gap caused a day's chilled stock to be quarantined under the company's own procedure. The technician, who had finished the fix on Friday evening, learned about the weekend from the write-off report. The acknowledgment had cost a day's stock and a weekend of overtime while being, in every word, accurate. The desk replaced it with a human acknowledgment, sent by the technician who claimed the ticket, that named the problem and gave a time. It added a line to the purpose card: the acknowledgment is the one message every requester reads, so it is the one that must say something.
The Canned-Response Purpose Card
The card below is the one-page statement of what templates are for on your desk, which messages get one, and the rules for sending them. Fill in the owner and the review date, and add or remove rows in the never list to match your own desk. Put it at the top of the template library so it is the first thing anyone sees when they open the list. It is a reference, not a policy, and it should be read in under a minute. If your desk is new to templates, write this card before writing the first template, because the card decides what the first template is.
CANNED-RESPONSE PURPOSE CARD — ONE PAGE
Desk: ______________________ Library owner: ______________ Next review: ________
WHAT TEMPLATES ARE FOR ON THIS DESK
[ ] Speed on the routine message (same shape many times a week)
[ ] Consistency across everyone on the desk, every day, every hour
[ ] Completeness where lines are required every time
A MESSAGE GETS A TEMPLATE WHEN
[ ] The desk sends it in the same shape most days, and the facts matter more than the prose
[ ] It carries required content that must never be left out (security caution, how to reopen,
where to go instead, start and end times)
EVERY TEMPLATE HAS, WRITTEN AT ITS TOP
Purpose: what this message is for, in one line
Trigger: the moment in a ticket's life when this is the right message
Slots: the parts that change every time, in upper-case brackets
THREE THINGS CHANGE EVERY TIME
[ ] The requester's name, as they signed it
[ ] The specific thing, in their words
[ ] The time or date they will next hear from us (never "shortly")
BEFORE SENDING
[ ] Read the whole message as the requester will read it
[ ] No bracket left unfilled; no sentence the sender would not say out loud
[ ] Does the message answer what they asked, or only what the template asked?
NEVER CANNED (type these, every time)
[ ] An apology for something the desk got wrong
[ ] A reply to someone who is angry
[ ] Specific bad news: declined, not repairable, lost, not supported
[ ] The next message after "did you read my ticket?"
[ ] First contact about a sensitive matter (security, access, monitoring)
[ ] ______________________________________________
WITH CARE (template as draft, then a sentence written for this ticket)
[ ] Cannot reproduce: list what was tried, propose a time to look together
[ ] Out of scope: name the specific request and the specific alternative
[ ] Delay: say why, give the new time, say what happens if it slips again
OWNERSHIP
Shared templates are the desk's voice; the owner approves, reviews and retires them.
Personal templates follow the same rules and are proposed for sharing when used daily.
The card does one thing a template cannot: it tells the technician when not to reach for one. Tomas, at Stonebridge, printed it on the Tuesday after the Monday described at the top. The nine acknowledgments on the following Monday took him fourteen minutes instead of thirty. Each one named the problem it was about. Ticket 5108's successor, a stolen phone reported on a Sunday night, got a typed message at 08:52 that began with the phone and ended with a time. The claims handler replied "thank you, that is a relief". That is not a sentence anyone has ever written back to "a member of our team will be in touch shortly".
Frequently Asked Questions
Is the automatic acknowledgment the tool sends a canned response?
Our manager says templates will make us sound like a call centre. How do we answer that?
How many templates does a small desk need?
Can a template contain an apology?
Should we have templates for internal notes as well as replies to requesters?
We inherited a library of eighty templates from the previous team. Where do we start?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
