The Twenty Templates Every Help Desk Needs

Monday, 09:30, at Northgate Retail. Ines has run the store-support desk for a week and has just opened the template list for the first time. There are a hundred and twelve entries. Forty-one of them are versions of the acknowledgment, with names like "Ack", "ack2", "Acknowledgement - Pete", "New ticket reply FINAL" and "New ticket reply FINAL2". There are six for password resets, four of which give a phone number that no longer rings anywhere. There is no template at all for "I could not make this happen", so on Friday a technician wrote one from scratch at 16:55. And it said "works fine for me", and a store manager has already replied to it. A library of a hundred and twelve had, in practice, about nine templates and a great deal of sediment.

A starter library is the smallest set of templates that covers the messages a desk sends in the same shape most days. Each has a purpose, what the message is for, and a trigger, the moment in a ticket's life when it is the right one. Twenty is the number for most desks of one to ten people, because that is about how many shapes a week of tickets contains. This article is part of our Templates & Canned Responses Done Right series. This is the list: the twenty, in five groups, with what each is for and when it is sent, so it doubles as a set of support ticket response examples to copy.

It covers why twenty and not nine or a hundred and twelve. Then come the five groups in turn: opening the conversation, keeping them informed, closing, the awkward ones, and the desk speaking as a desk. Next comes a table with the trigger and the required line for every template. It covers how to build the library in an afternoon, then a short war story. It ends with the library index with the opening line of each template, in that order.

Why Twenty

Count the shapes. Take a week of the desk's outgoing messages, ignore the hand-written ones, and sort the rest by what they were for. You will find an acknowledgment, a request for something, a "still looking", a "fixed, please confirm", and a "closing soon". You will also find a handful of less frequent shapes that nonetheless arrive every week. The thing is not ours, the thing is a duplicate, or the thing is with a supplier. Most desks land between fifteen and twenty-five shapes, and the list below is the twenty that are common to nearly all of them. Yours may need two more and may not need two of these. The number is a starting point, not a rule.

Fewer than twenty means a routine message has no template. A routine message with no template gets written by hand at 16:55 by whoever is on the desk. Some of those versions will be "works fine for me". The missing template is written worst precisely because it is needed least often; nobody has practised it. More than about forty shared templates means several are variants of each other, which is what Ines found. The variants are worse than one agreed version because five technicians are speaking in five voices about the same thing. Twenty keeps every routine shape covered and every shape agreed.

Each template on the list follows the five-line skeleton from the earlier article in this series on writing a template that does not sound canned. The skeleton has a name slot, their words for the problem, and one sentence that proves the ticket was read. It has one ask or one statement of what is happening, and a time. What differs between the twenty is the trigger, the required content in line three, and the ask. The index at the end gives the opening line of each. The fixed text around it should be written on your own desk, from your own real tickets, in your own words.

Group One: Opening the Conversation

The first group is the four messages that start a ticket's conversation, and the acknowledgment is the first of them. Its purpose is to tell the requester that a person has their ticket, what happens next and when they will hear more. Its trigger is the first human read of a new ticket. It is the most-sent template on any desk and the most-read message the desk produces, because every requester reads the first reply to find out whether anyone is there. It is also the template most often left as the tool's automatic reply, which is not an acknowledgment but a receipt.

Missing information is the second, and its trigger is narrower than it is usually used. The trigger is that the desk cannot start work without one specific thing the ticket does not contain. Not "more details"; one thing, named, with where to find it. Restating what you understood is the third, sent when the ticket is vague enough that starting work would be a guess. It says what the desk thinks the problem is and asks the requester to correct it, which turns a guess into an agreement. Scheduling a session or visit is the fourth, sent when the fix needs the requester present. It proposes one time rather than asking "when suits you?", because an open question gets an open answer.

The acknowledgment and the missing-information template are the two to write first, because between them they are most of what the desk sends before lunch. Write the acknowledgment so it cannot be sent without a time in it. If the template's time slot is optional, it will be left empty on busy days. An acknowledgment without a time is the automatic receipt again, typed by a person. Twelve written-out versions of it, for the automatic receipt, the outage, after hours and the rest, are in Ticket Acknowledgement Templates.

Group Two: Keeping Them Informed

The second group is the four messages that stop the requester from asking "any update?", and each one is a time. The ETA template gives a date or time for the fix when the desk knows enough to give one. Its trigger is the moment the desk knows. It carries the estimate, what has to happen first, and an earlier time by which the requester will hear if the estimate moves. The status update with no news is sent at the time promised in the previous message, whether or not anything has changed. It says what was done since then and when the next update is. Its trigger is a clock, not an event. That is the entire discipline, and most desks do not have it.

Waiting on a vendor or another team is sent when the next step belongs to someone outside the desk. Its required line is the date the desk will chase them, because "waiting on the supplier" with no chase date is a ticket that waits forever. The plan has changed is sent the moment a promised date will not hold, before the date, with the reason in plain words and a new date. It is the hardest of the four to send, because it admits a miss. It is the one that most repairs trust when it is sent on time. A technician who sends it the day before the old date is believed; one who sends it the day after is not.

These four are the templates most worth getting right on a small desk. A requester who is told when they will next hear, and then hears at that time, stops chasing. And a desk that is not chased has an hour a day it did not have before. The requester-facing side of this, what to say and how often, is in the Managing Expectations series. The templates are how the desk keeps the promises it makes there without typing them fresh each time.

Group Three: Closing

The third group closes the conversation, and the resolved-please-confirm template is its centre. Its trigger is a fix the technician has tested. Its required lines say what was wrong and what was done, in plain words. They include a request to confirm, how to reopen if it comes back, and the date the ticket will close if nothing is heard. In most tools, QuerySolv among them, a requester's reply to a resolved ticket reopens it with the whole history intact. That is what the "reply to this message" line relies on. Some tools create a new ticket instead, so test yours before promising. The method for confirming without chasing for a fortnight is in User Confirmation Without Chasing Forever. The template is its first message.

Resolved with a workaround is the same message for a known problem the desk can get round but not yet fix. It says this is known, here is how to get going now, and a permanent fix is planned. It has the steps as its required content. It is sent whenever a ticket matches a known error, and the record it points to is described in Known Errors and Workarounds. No reply, closing soon is sent when the desk asked for something and heard nothing by the chase date. It repeats the one ask, gives a closing date, and says a reply after that still reopens the ticket. Closed, thanks is the short message after a confirmation. It exists mainly so that the last thing the requester receives is a person saying thank you rather than a status change.

Write the resolved template with the closing date as a slot rather than a fixed number of days, because the right wait depends on the ticket. A password reset can close tomorrow and a report that runs monthly cannot be confirmed until it runs. A fixed "we will close this in three days" in the template becomes a lie on the fourth kind of ticket and a complaint on the fifth.

Group Four: The Awkward Ones

The fourth group is the four messages technicians avoid writing, which is exactly why they need templates. A template written on a calm afternoon is better than anything written at 16:55 by someone who would rather not be writing it. Cannot reproduce is first. Its purpose is to say honestly that the desk tried and could not make the problem happen, without implying that the requester imagined it. Its required lines are what was tried, in order, and a proposal to look together at a specific time. That is because "I could not reproduce this" on its own is read as "I do not believe you", whatever was meant.

Out of scope is second, sent when the request is something the desk does not do. Its required lines are the specific thing declined, the reason in one plain clause, and the specific place that can help. A no without a door is a wall. The shape of a good decline, and how to avoid the wall, is in Declining Out-of-Scope Requests. The template carries the door so it is never forgotten. Needs approval is third, sent when the desk can do the thing but someone else must say yes first. It names who, says the desk has already asked them, and gives a date for the next update so the requester knows the ticket has not stopped. Duplicate, merged is fourth, sent when the same problem already has a ticket. It names that ticket's number, who has it, and where the updates will now appear.

All four are "with care" templates: the skeleton is a draft, and a sentence has to be written for this ticket before they go. A cannot-reproduce message with the generic list of things tried, rather than the actual list, is the "works fine for me" message in a better font. The template's job in this group is to make sure the required lines appear; the technician's job is to make them true.

Group Five: The Desk Speaking as a Desk

The fifth group is the messages where the desk speaks in its own name rather than one technician's. And the first is the odd one out: reopened, we have it. It is sent when a requester replies to a resolved ticket to say the problem is back. It thanks them for replying rather than raising a new ticket. It says the ticket is open again, and gives a first step and a time. It is in this group because it is often the first message after a failure, and the desk, not the technician, owns the failure. The outage first notice is second, and it is a different shape from everything else on the list. It has no name, because it goes to many people. Its slots are the service, who is affected, since when, and the time of the next update. The full discipline of the first notice and what follows it is in The First Notice. The template is the five lines it must contain.

The planned-maintenance notice is third, with the most required content of any template. It must include the service, the start, the end, what will not work, what to do beforehand, and who to contact if it is still broken after the end. It is sent on a schedule, usually twice, a week before and the day before. And it is the template most often found with a stale phone number in it, because it is read by nobody on the desk between sends. The pointer to a knowledge article is fourth, sent when the requester can do the thing themselves with a written guide. It links the article, says how long the steps take, and asks them to reply with the step number if they get stuck. That turns "read the manual" into an offer. The knowledge base may distinguish articles everyone can see from those only agents can see, as QuerySolv's does. In that case, the pointer must only ever link the public kind, and the template is where that rule lives.

That is the twenty. Each group has four, each template has a trigger, and between them they cover the routine messages of nearly every small desk. The two that most often turn out to be missing on a real desk are cannot reproduce and the plan has changed. And both are missing for the same reason: nobody wanted to write them.

The Table: Purpose, Trigger, Required Line

The table is the twenty on one page with the trigger and the one line each must contain beyond the skeleton. Read the trigger column as the rule for when to insert, and the required-line column as what the quarterly review checks is still present. Where a row says "with care", the template is a draft and a sentence is written for the ticket before it goes.

Building the Library in an Afternoon

Build the twenty in the order they are sent, not the order they are listed. That means the acknowledgment, missing information, status update, resolved and no-reply templates first. Those five are most of a day's messages and the desk benefits from them the next morning. Write each from a real ticket: open one the desk answered well last week, copy the reply, take out the specifics, leave the slots. A template written from a real reply inherits a real voice. A template written from a blank page inherits the lobby.

Name each one by its number and its purpose, so that "09 Resolved, please confirm" sorts into place and can be found by someone who has never seen the list. Write the trigger on the first line of each template. Mark the required content so it is not removed by a technician trimming for length. Test each on one colleague outside IT with the single question "what do you do next?", and fix any that get a question back. An afternoon is enough for the first ten. The second ten can follow over the next week as the triggers come up, which they will.

Then stop adding. A library that reaches twenty and keeps growing without anything being retired is Ines's hundred and twelve in five years. And the rules for keeping it at twenty, the owner, the naming, the review and the retirement, are the subject of Keeping the Template Library Alive and Trusted. The twenty is a floor and a ceiling. Technicians may keep personal templates on top of it; the shared library stays at the shapes the desk agreed.

A Short War Story: The Works-for-Me Closures at Bluewater Bank

Bluewater Bank's branch desk had a full library of templates for everything except the message it most needed. That was the one for a problem the desk could not make happen, so each technician wrote that one by hand. Rosa's version was written in a hurry and then saved as a personal template. It read "I have tested this and it works fine from here; please let me know if it happens again". Over one quarter she sent it to eleven tickets from four branches about the teller application pausing for several seconds at random. Each branch took the message as "not believed", stopped raising tickets about it, and told the tellers to live with it. They did, for eleven weeks. The branch supervisor, Dev, later estimated the cost at about an hour per teller per week in lost counter time. The pattern was found only when Dev mentioned "the pausing thing" to the IT manager at a different meeting. The cause turned out to be a link between two branch sites that dropped packets under load. A technician looking at four tickets together would have seen it in a day. The desk wrote the cannot-reproduce template that week, with the list of what was tried and a proposed time to look together as required lines. The first time it was sent, the requester replied with a screen recording. The template you do not have is the one that gets written worst, by whoever is most tired, and sent to the people who most needed a better one.

The Library Index With the Opening Line of Each

The index is the twenty templates with their purpose and the opening line of each, written in the five-line shape with the slots marked. Use it as the table of contents for the shared library and as the first draft of each template. The opening line is the line that matters most. And the rest of each template is the skeleton filled in from your own real tickets. The lines are plain, short and joke-free, because they are the words the desk will say most often. Change any that do not sound like your desk. But keep the slot in each one, because the slot is what stops it sounding like anyone's.

TEMPLATE LIBRARY INDEX — TWENTY TEMPLATES
Desk: ______________________   Library owner: ______________   Last review: ________

OPENING THE CONVERSATION
 01 Acknowledgment
    Hi [NAME], thanks for reporting [THE THING]. I have it, and I will update you by [TIME] either way.
 02 Missing information
    Hi [NAME], thanks for reporting [THE THING]. To look into it I need [ONE THING], [WHERE TO FIND IT].
 03 Restating what you understood
    Hi [NAME], before I start I want to check I have this right: [RESTATEMENT]. Reply if that is wrong;
    otherwise I will [NEXT STEP] by [TIME].
 04 Scheduling a session or visit
    Hi [NAME], the quickest way to fix [THE THING] is [A REMOTE SESSION / A VISIT], which takes about
    [DURATION]. Does [TIME] work? If not, reply with a time that does.

KEEPING THEM INFORMED
 05 ETA
    Hi [NAME], [THE THING] needs [WHAT HAS TO HAPPEN] and I expect it done by [DATE OR TIME].
    I will tell you by [EARLIER TIME] if that changes.
 06 Status update, no news
    Hi [NAME], still on [THE THING]. Since [LAST UPDATE] I have [WHAT WAS DONE]. Next update by [TIME].
 07 Waiting on vendor or team
    Hi [NAME], [THE THING] is with [SUPPLIER OR TEAM] as of [DATE]; they have promised [WHAT] by [DATE].
    I will chase them on [DATE] and update you the same day.
 08 The plan has changed
    Hi [NAME], the [DATE] I gave you for [THE THING] will not hold, because [REASON IN PLAIN WORDS].
    The new date is [DATE], and I will tell you by [EARLIER DATE] if that moves too.

CLOSING
 09 Resolved, please confirm
    Hi [NAME], [THE THING] should be fixed: [WHAT WAS WRONG AND WHAT WAS DONE]. Could you reply to
    confirm? If it comes back, reply to this message and the ticket reopens. I will close it on [DATE]
    if I do not hear back.
 10 Resolved with a workaround
    Hi [NAME], [THE THING] is a known issue we are working on with [WHO]. To get going now: [STEPS].
    A permanent fix is [PLANNED / SCHEDULED FOR DATE].
 11 No reply, closing soon
    Hi [NAME], I asked on [DATE] for [THE ONE THING] and have not heard back. I will close this on [DATE]
    unless you reply; a reply any time after that reopens it.
 12 Closed, thanks
    Hi [NAME], thanks for confirming. I have closed [THE THING]. If it comes back, reply to this message
    and it reopens with the history.

THE AWKWARD ONES
 13 Cannot reproduce
    Hi [NAME], I have tried [WHAT WAS TRIED, IN ORDER] and could not make [THE THING] happen here.
    That means I am missing something, not that it is not happening. Can we look at it together at [TIME]?
 14 Out of scope
    Hi [NAME], [THE REQUEST] is not something the desk can do, because [REASON]. The place that can is
    [ALTERNATIVE], and [WHAT I HAVE DONE TO HELP].
 15 Needs approval
    Hi [NAME], [THE REQUEST] needs approval from [WHO] before I can do it. I sent the request to them
    today. I will update you by [DATE] either way.
 16 Duplicate, merged
    Hi [NAME], this is the same issue as ticket [NUMBER], which [WHO] is already working on, so I have
    merged the two. Updates will come on that ticket; the next one is due by [TIME].

THE DESK SPEAKING AS A DESK
 17 Reopened, we have it
    Hi [NAME], I can see [THE THING] has come back; thanks for replying rather than raising a new ticket.
    I have reopened it and [FIRST STEP]. Update by [TIME].
 18 Outage first notice
    [SERVICE] is unavailable for [WHO] since [TIME]. We are working on it. Next update at [TIME] here,
    whether or not it is fixed.
 19 Planned-maintenance notice
    [SERVICE] will be unavailable from [START] to [END] on [DATE] for [REASON]. Save your work before
    [START]. Contact [DESK] if you still cannot use it after [END].
 20 Pointer to a knowledge article
    Hi [NAME], [THE THING] is covered step by step here: [LINK]. It takes about [DURATION]. If you get
    stuck at any step, reply with the step number and I will take it from there.

Ines rebuilt Northgate's library from this index over two afternoons, writing each template from a real reply in the archive. She retired the hundred and twelve with a note saying which of the twenty replaced each. The forty-one acknowledgments became one, with a time slot that could not be left empty. The cannot-reproduce template was sent for the first time on the Thursday, to the store manager who had received "works fine for me" the week before. It listed four things tried and proposed a call at 11:00. She took the call. The problem was a till that only failed when the shutter was down. Nobody at the desk could have reproduced that, and the template had been honest enough to admit it.

Frequently Asked Questions