Ticket Acknowledgement Templates: Twelve First Replies That Say When

Thursday, 08:40, at Brightwater Marine. A yard supervisor called Marcus has e-mailed the IT address because the tide tables will not print, and at 08:41 he received a message that began "Your request has been received and assigned ticket #48213. Our hours are Monday to Friday, 08:00 to 17:00." He read it, learned that a computer had noticed him, and walked across the yard to find a technician, because the message did not say that a person would. The technician, Priya, had in fact read the ticket at 08:47 and started on it; she just had not said so, because the tool had "already replied". At 09:10 Marcus arrived at the desk, and the tide tables were printed by 09:12. The ticket was resolved in thirty minutes. The walk took twenty of them, and the acknowledgement that would have saved it was never sent.

An acknowledgement is the first reply a person sends on a new ticket. It tells the requester three things: that a named person has their request, what will happen next, and when they will hear more. It is not the automatic receipt, which can only tell them that a ticket number exists. 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. This article is part of our Templates & Canned Responses Done Right series, and it is the long version of the first entry in The Twenty Templates Every Help Desk Needs.

It covers what an acknowledgement must contain and why the receipt is not one. Then come the twelve situations that need their own version, with the line each must carry, and a table of the triggers. It covers how fast is fast enough, and the mistake of acknowledging everything with the same words. There is a short war story. It ends with the twelve templates written out with the slots marked, ready to paste into whatever tool you have.

What an Acknowledgement Must Contain

Five things, in the order the requester needs them. Their name, because a message with a name in it was read by a person. Their words for the problem, one phrase, so that they know the right ticket was read and not just the subject line. The name of the person who owns it now. What happens next, in one sentence, which may be "I am looking at it now" and may be "I need one thing from you first". And a time by which they will hear again, whether or not anything has changed.

The time is the one that gets left out, and it is the one that stops the walk across the yard. A requester who has been told "I will update you by 11:00 either way" can get on with their morning. A requester who has been told "we will get back to you as soon as possible" has been told nothing, and will reasonably ask again at 09:30. The time slot in the template should be mandatory in the sense that the template does not read as a sentence without it. An acknowledgement with an optional time is an acknowledgement with no time on busy days.

Two things do not belong. A promise to fix it by a certain time, because the acknowledgement is sent before the problem is understood, and a fix time given then is a guess that will be quoted back. And an apology, unless the desk did something to be sorry for. "Sorry for the inconvenience" in every first reply is wallpaper; the requester stops seeing it and the one time it is meant it is missed. Apologize when the desk was late, in the words for that, which are in Managing Expectations.

The Receipt Is Not an Acknowledgement

Most tools send a message the moment a ticket is created, and most desks leave that message as the vendor wrote it. It is useful. It carries the ticket number, which the requester needs to reply or to check the portal, and it proves the e-mail arrived. What it cannot do is acknowledge, because at the moment it is sent nobody has read the ticket. It can only say what is true at creation: the number, the desk's hours, how to add information, and when a person will first look. That last line is the one most receipts lack and the one that makes them bearable.

The receipt and the acknowledgement therefore have different triggers. The receipt's trigger is creation; it is automatic and identical every time. The acknowledgement's trigger is the first human read, and it is sent by the person who read it. A desk that treats the receipt as the acknowledgement has delegated its most-read message to a machine that has not read anything. Marcus's walk is what that costs. The first of the twelve templates below is the receipt, written so that it tells the truth about itself.

The Twelve Situations

One acknowledgement does not fit every ticket, because the thing the requester needs to hear next differs. These are the twelve shapes that arrive on most desks, and what the acknowledgement for each must say beyond the five basics.

01 The automatic receipt. Sent by the tool at creation. Must say the ticket number, how to add information (reply to this message), the desk's hours, and when a person will first look. Must not pretend to be a person.

02 The standard first reply. The first human read of an ordinary ticket. The five basics and nothing else. Sent within the response time the desk has promised, and in any case before starting work that will take more than a few minutes, because the requester cannot see you working.

03 Missing information. The desk cannot start without one specific thing. The acknowledgement carries the one thing, named, with where to find it, and says that the clock on their side starts when it arrives. Not "more details": one thing. If the ticket needs three things it needs a call, not a template.

04 Outage or known problem. The ticket is about something the desk already knows is down. The acknowledgement says so, names the outage, gives the next update time for the outage rather than the ticket, and says the ticket will be closed when the outage is, without the requester doing anything. This is the acknowledgement that stops the ninth ticket about the same printer becoming a ninth conversation. The outage side of it is in Outage Communication.

05 After hours. The ticket arrived outside the desk's hours and the receipt has already said so. The human acknowledgement, sent first thing, says when the desk opened, that the ticket is first in the queue or is not, and when they will hear more. If the desk has an on-call arrangement for emergencies, the receipt, not the acknowledgement, is where it is described.

06 High priority. The ticket is urgent on the desk's own scale: many people, or an important service. The acknowledgement says that it has been prioritized, who is on it now, and a shorter update time. It does not promise a fix time. The difference between this and the standard reply is the update interval and the word "now".

07 VIP or executive. The requester is on the list that gets a different service level. The acknowledgement is the standard one with a shorter time and a direct contact for the owner, and it is sent by the owner personally. It is not more flowery. The method is in VIP and Executive Support.

08 Chat that became a ticket. The conversation started in live chat, could not be finished there, and is now a ticket. The acknowledgement, sent by e-mail, says that the chat is now ticket number such-and-such, repeats what was agreed in the chat in one line, and gives the next update time. The requester otherwise assumes the chat ended and the problem with it.

09 Service request with an approval. The ticket is a request for something, access or equipment or software, that needs someone else's yes. The acknowledgement says that the request is understood, who must approve it, that the desk has asked them today, and when the requester will hear either way. Requests sit for days because this message was never sent and the requester did not know the delay was in a different inbox.

10 Duplicate of an existing ticket. The same person has already raised this, or another person has raised the same thing. The acknowledgement names the existing ticket, says the two have been merged or linked, and says where updates will now appear. It thanks them rather than telling them off.

11 Wrong desk, transferred. The ticket belongs to facilities, HR or a supplier. The acknowledgement says who has it now, that the desk has passed it on (not "please contact them yourself"), the new reference if there is one, and who to chase if nothing happens by a date. The door is left open. The shape of a decline with a door is in Saying No Professionally.

12 The shared mailbox with no tool. The desk is still an inbox. The acknowledgement is the standard one, typed by hand or from a signature, with a reference the desk invents (date and initials will do) and a time. It is here because the habit matters more than the tool, and because a desk that acknowledges from an inbox is ready for the tool when it arrives. Helpdesk From Scratch is the series for that desk.

The Table: Trigger and Required Line

The table is the twelve on one page with the trigger, the one line each must contain beyond the five basics, and whether it is sent as is or needs a sentence written for the ticket.

How Fast Is Fast Enough

The honest answer is: within the response time the desk has promised, and sooner than the requester would walk. On most small desks that means an acknowledgement inside an hour during working hours for ordinary tickets, inside fifteen minutes for high priority, and first thing for anything that arrived overnight. The number is less important than the consistency. A desk that acknowledges in ten minutes on Monday and four hours on Thursday has taught its requesters to call on Thursday.

Speed has one trap. An acknowledgement sent in thirty seconds that says nothing is the receipt with a signature. The five basics take a minute to write from a template, and the minute is the point: it is the minute in which the technician read the ticket. If the desk is so busy that nobody can spend a minute per new ticket, the acknowledgements are not the problem, and Backlog Recovery is the series to read instead. Until then, the rule is one minute, five things, one time.

The other trap is acknowledging everything with the same words. The twelve exist because a requester whose outage ticket gets the standard reply has been told their problem is ordinary, and a requester whose request-with-approval gets the standard reply has been told it will be worked today when it will not be. The template that fits the situation is the one that keeps the promise the situation needs. The method for choosing it in ten seconds, by trigger, is in Personalizing a Canned Response in Ten Seconds.

A Short War Story: The Four-Day Approval at Brightwater Marine

Brightwater's new chandlery manager, Teodora, asked for access to the stock system on a Monday. The receipt arrived in a second. The request needed the finance director's approval, which the desk requested the same morning by e-mail. Nobody told Teodora that. By Wednesday she had raised a second ticket, asked her own manager to "chase IT", and told the yard that IT took three days to do nothing. The finance director approved it on Thursday, having been on leave, and the access was granted in four minutes. The ticket's history showed the desk had done everything it could on Monday morning. The requester's history showed four days of silence. Priya wrote the request-with-approval acknowledgement that afternoon: who approves, that they were asked today, and a date by which Teodora would hear either way. The next new starter's access took the same four days and generated no second ticket, no chasing and no remark in the yard, because the requester knew on day one whose inbox the delay was in. The desk's work had not changed at all. The acknowledgement had.

The Twelve Templates

The templates are written in the five-line shape with the slots marked. The fixed text is plain and short on purpose; change it to sound like your desk, but keep every slot, because the slots are the five basics. Save them as predefined replies, numbered, with the trigger on the first line of each so that it is read before the reply is inserted. The receipt goes into the tool's automatic reply, not into the library.

ACKNOWLEDGEMENT TEMPLATES — TWELVE FIRST REPLIES
Desk: ______________________   Owner of this library: ______________   Last review: ________

 01 AUTOMATIC RECEIPT (the tool sends this; it is not an acknowledgement)
    We have received your request and given it ticket number [NUMBER]. Reply to this message
    to add anything. The desk is open [HOURS]; a technician will look at it by [TIME OR
    "within one working hour"] and reply to you then.

 02 STANDARD FIRST REPLY (first human read)
    Hi [NAME], thanks for reporting [THE THING]. I have it and I am looking at it now.
    I will update you by [TIME] either way.

 03 MISSING INFORMATION (one thing, named)
    Hi [NAME], thanks for reporting [THE THING]. To start on it I need [ONE THING], which
    you can find [WHERE]. As soon as I have it I will get going and update you within [TIME].

 04 OUTAGE OR KNOWN PROBLEM
    Hi [NAME], thanks for reporting [THE THING]. It is part of a wider problem with [SERVICE]
    that we are already working on. Updates on that are going out at [TIME]; I will close this
    ticket for you when it is fixed, and you do not need to do anything else.

 05 AFTER HOURS (sent first thing)
    Hi [NAME], thanks for reporting [THE THING] last night. The desk opened at [TIME] and
    your ticket is [FIRST / NEAR THE FRONT] in the queue. I will update you by [TIME].

 06 HIGH PRIORITY
    Hi [NAME], thanks for reporting [THE THING]. I have raised it to [PRIORITY] and [OWNER]
    is on it now. You will hear from us every [INTERVAL] until it is fixed, starting by [TIME].

 07 VIP OR EXECUTIVE (sent by the owner)
    Hi [NAME], I have [THE THING] and I am dealing with it myself. I will update you by [TIME];
    if you need me before then, [DIRECT CONTACT].

 08 CHAT THAT BECAME A TICKET
    Hi [NAME], thanks for your chat with [AGENT] just now about [THE THING]. We agreed
    [WHAT WAS AGREED]. It is now ticket [NUMBER] so that we can finish it properly; I will
    update you by [TIME].

 09 SERVICE REQUEST WITH AN APPROVAL
    Hi [NAME], thanks for your request for [THE THING]. It needs approval from [WHO], and I
    sent them the request today. I will tell you by [DATE] either way, and set it up the
    same day it is approved.

 10 DUPLICATE
    Hi [NAME], thanks for this. It is the same issue as ticket [NUMBER], which [WHO] already
    has, so I have merged the two. Updates will come on that ticket; the next one is due
    by [TIME].

 11 WRONG DESK, TRANSFERRED
    Hi [NAME], thanks for reporting [THE THING]. It is handled by [TEAM], so I have passed it
    to them today [WITH REFERENCE]. They aim to reply by [DATE]; if you have not heard by
    then, reply to this message and I will chase it.

 12 SHARED MAILBOX, NO TOOL YET
    Hi [NAME], thanks for reporting [THE THING]. I have it (ref [DATE-INITIALS]) and I am
    looking at it now. I will update you by [TIME] either way.

Priya built the twelve in an afternoon from the acknowledgements the desk had sent well in the previous month, and set the standard first reply as the default insert on every new ticket, with the time slot in a colour that made it impossible to miss. Marcus's next printing problem, in October, got a reply at 08:49 that said "I have it and I am looking at it now; I will update you by 09:30 either way". He stayed in the yard. The tide tables were printed by 09:05, and the acknowledgement was the only part of the ticket that had changed since the spring.

Frequently Asked Questions