Personalizing a Canned Response in Ten Seconds

Thursday, 14:10, at Bellweather Logistics. Jonah has thirty-one open tickets and a new one from Fatima in dispatch. It has three paragraphs, two screenshots, and the exact time the dispatch board froze. The ticket says what she was doing when it froze and that the colleague at the next desk can still use it. Jonah reads the subject line, inserts the missing-information template, and presses send. Fatima receives: "Hi, thanks for your ticket. Could you send more details about the issue, including any error messages, when it started and whether it affects other users?" She replies at 14:14 with four words. "Did you read my ticket?" Jonah reads it now. It takes him forty seconds, which is thirty more than it would have taken to make the template fit.

Personalizing a canned response means the small edits that turn a template into a message to one person about one ticket. It is not the marketing sense of the word, where a machine inserts a first name into a mailing. It is the opposite, a human reading and changing. This article is part of our Templates & Canned Responses Done Right series. This article is about the ten seconds between inserting the template and pressing send. Those are the ten seconds that decide whether the requester reads a message or a form.

It covers why ten seconds is the right number and what skipping them costs. Next come the three things to change every time: the name, the specific thing and the time, each with its own section. Then it covers the one sentence to add and the read-aloud test that catches what the first four miss. What personalizing is not comes next, because the wrong kind makes it worse. The routine with a stopwatch on it, a short war story, and the personalization checklist to pin beside the screen finish the article.

Why Ten Seconds Is the Right Number

Ten seconds is about how long it takes to change three words, type one sentence and read five lines. That is the whole cost of personalizing a template that was built properly with its slots marked. The template itself saved around ninety seconds of typing. Spending ten of those ninety on making it fit is a small fraction of the saving. The message that results is one the requester cannot tell from a hand-written one. Skip the ten seconds and the message is a form with a name on it. That form costs more than it saved.

The cost of skipping is the second exchange. "Did you read my ticket?" arrives, and now the technician must read the ticket properly and write a reply that proves they did. They must do it from a position of having already annoyed the person. That is five to ten minutes, plus a requester who will read every future message from the desk looking for signs of a form. The arithmetic is lopsided: ten seconds against ten minutes and a dent in trust. I have never met anyone who disputes the arithmetic. I have met a great many people who skip the ten seconds anyway, at 14:10, with thirty-one tickets open, because the template looked finished. It is designed to look finished. That is the problem with it.

The ten seconds depend on the template having been written with slots, which is the subject of Writing a Template That Does Not Sound Canned. A template with no gaps in it cannot be personalized in ten seconds or in ten minutes. There is nothing to change, so the technician either rewrites it or sends it as is. Everything below assumes the template has a marked slot for the name, the specific thing, the time, and one free sentence. If yours does not, fix the template first and come back.

The First Thing: The Name, as They Signed It

Change the greeting to the requester's name as they signed their message, not as the directory lists them. The directory says Robert; the ticket is signed Bob; the message says "Hi Bob". The directory says Elizabeth Okafor-Grant; the ticket is signed Liz; the message says "Hi Liz". A requester who signs one way and is addressed another learns in the first two words that a system, not a person, chose the name. The rest of the message is read in that light. It takes one second to look at the signature and one to type the name. It is the cheapest trust the desk will buy all day.

Tools that fill the name automatically help with half of this. The field they fill is the directory's version, and the directory is right often enough that people stop checking. Check anyway. A merged field that reads "Hi Robert" to someone who has signed Bob for thirty years is worse than "Hi" on its own, because it demonstrates the mechanism. When the ticket has no signature and the directory has only a formal name, use the formal name and move on. The point is not to guess at nicknames. It is to use the one they gave you if they gave you one.

Watch for the wrong requester as you do this. A ticket forwarded by an assistant, or sent from a shared mailbox, carries a name that is not the person with the problem. Personalizing to the wrong name is a form of filing the ticket under the wrong person. "Hi Dana" to a message that begins "my colleague Sam cannot log in" is a message to the wrong desk. Fix the requester field before the reply, not after the fourth exchange, and address the message to the person whose problem it is.

The Second Thing: Their Words for the Problem

Replace the slot for the specific thing with the requester's own words for it, lifted from their ticket. Not the category. Not the technician's translation. Fatima wrote "the dispatch board freezes when I open the Tuesday run", so the message says "thanks for reporting the dispatch board freezing when you open the Tuesday run". It tells her three things at once. The message is about her ticket and not some other. Someone read far enough to find the sentence. And the desk has not yet renamed her problem into something she will not recognize.

Quoting their words is also the fastest way to notice when the template does not fit. Jonah, copying Fatima's sentence into the slot, would have seen the three paragraphs it came from. He would have realized that the missing-information template was the wrong one, because nothing was missing. The slot forces a read of at least one line of the ticket. One line is usually enough to catch a mismatch between the template's trigger and the ticket's situation. A technician who fills the slot from the subject line alone has skipped the read and kept the risk.

When the requester's words are vague, "it's broken again", quote them anyway and add the desk's understanding alongside: "thanks for reporting that it is broken again; I think you mean the label printer on bay 2 that we looked at on Monday, tell me if not." That one clause is the restatement that turns a vague ticket into a workable one. The method behind it is in Translating the Vague Ticket. In a template it fits in the same slot, and it costs three seconds more.

The Third Thing: A Real Time

Replace the time slot with a clock time or a date that you have actually looked at the calendar to choose. "I will update you by 15:00 today." "I will come back to you by Thursday lunchtime." Never "shortly", never "as soon as possible", never "in due course", and never the template's example time left unchanged because it looked plausible. A real time is the one thing in the message that the requester will hold the desk to, which is exactly why it reassures. It is a promise with a shape, and a person made it.

The time should be one you will keep whether or not the problem is fixed by then, which is what "either way" means in the template. The update at 15:00 may say "fixed", "still looking, next update tomorrow at 10:00", or "I need something from you". All three keep the promise. What breaks the promise is silence at 15:01. Choosing a time you can keep is a skill of its own. The rules for it, including what to do when you have no idea how long something will take, are in Honest ETAs. For the ten-second routine the rule is simpler: pick a time, write it, and put it in your own list before you press send.

Two seconds of this step are spent checking that the time in the message is after now. Templates with example times in them produce messages that promise an update by 12:00 sent at 16:40, and the requester notices. Suppose the tool stamps the ticket with when it arrived and shows every touch since, as most do and QuerySolv does through the ticket's event history. In that case, the honest time is a glance at that history rather than a guess. That is because you can see how long the desk has already taken and set the next promise accordingly.

The One Added Sentence

Add one sentence, written fresh, that could not have been written about any other ticket. It is the sentence that proves a person read the ticket. It is the single most powerful edit in the routine, because no template and no automatic field can produce it. "I can see it dropped three times this morning." "I have checked and your colleague's account is on the new server and yours is not yet, which is probably the difference." "I tried the Tuesday run from here and it froze for me too." Each one tells the requester that their problem exists in someone's head other than their own.

The sentence comes from one of three places. What you noticed in the ticket that the requester might not expect you to have noticed. What you have already checked or tried since reading it. What you are about to do first. Any of the three will do. The first is available even when you have had no time to do anything, because it only requires having read. Jonah, with no time at all, could have written "I can see your colleague's board is fine, which is useful". Then Fatima would have known she was dealing with a reader.

Put the sentence near the top, in the second line, not at the bottom after the time. The requester reads the first line and the last line and skims the middle. The proof of reading has to land before they decide this is a form. A perfect added sentence buried after the sign-off is wasted. Five seconds of the ten go on this sentence, and they are the best-spent five seconds in the whole exchange. (The other five are spent not sending the previous ticket's sentence to this requester. More on that in the war story.)

The Read-Aloud Test

Before pressing send, read the whole message once, under your breath, as though you were standing at the requester's desk saying it. This catches what the three changes and the added sentence miss, and it takes three seconds for a five-line message. You are listening for five things. A bracket still unfilled. A name that does not match the signature. A time that has already passed or that you did not choose. A sentence you would never say out loud to a colleague, which is filler or jargon and should go. And the ask that asks for something the requester already gave you, which is the mistake Jonah made and the one requesters forgive least.

The read-aloud test works because reading silently lets the eye accept the shape of a message as the message. A template is designed to have the right shape, so a silent read passes it. Reading aloud, even under the breath, forces the words through one at a time. And "please send any error messages" said to a person whose ticket has two screenshots of the error message is impossible to say with a straight face. Technicians who adopt this test report the same thing: it feels silly for a week, and after the week they cannot send a message without it.

The test also catches the wrong template, the one whose trigger does not match this ticket. An acknowledgment read aloud in reply to a requester's third message sounds absurd, because it is. A "resolved, please confirm" read aloud over a ticket where the fix has not been tested sounds like a lie, because it is close to one. Where the words will not come out of your mouth, do not let them out of the desk.

What Personalizing Is Not

Personalizing is not adding warmth. "I hope you're having a wonderful day!" at the top of a missing-information message is not personal. It is a second template, and a worse one, because it is warmth addressed to a crowd. Exclamation marks, cheerful sign-offs and "happy to help!" do not make a message feel written. They make it feel like a message that has been told to feel written. The requester with a frozen dispatch board is not having a wonderful day and would rather you asked for the asset tag.

Personalizing is not adding length. The three changes replace words; the added sentence is one sentence; the read-aloud test removes words more often than it adds them. A personalized message is usually shorter than the raw template, because the read-aloud test took out the hedging. If the routine is making messages longer, the added sentence has become a paragraph, and the paragraph is being skimmed.

Personalizing is not using what you know about the requester from elsewhere. That includes their job title, their manager's name, the fact that they raised a similar ticket last spring, and their department's current project. None of it belongs in the message unless it bears on the problem. "I see you're in dispatch" is the directory talking, and the requester knows where they work. The test for every addition is whether it is about this ticket. If it is about the requester as a record, leave it out.

The Ten-Second Routine, Timed

The table puts a stopwatch on the routine so it is clear that ten seconds is a real estimate and not a slogan. The times assume a template built with slots and a ticket already open on screen. The first time through, on a new template, expect double. The order matters slightly. The name comes first, because it forces a look at the signature. The specific thing comes second, because it forces a look at the body. The time comes third, because by then you know what you are promising. The sentence comes fourth, because by then you have something to say. The read comes last, because it checks the other four.

Ten seconds, on a desk sending forty templated messages a day, is under seven minutes. That is the entire daily cost of never sending a form. Against it, one "did you read my ticket?" costs more than the whole day's personalizing, and a desk that skips the routine gets several a week. The routine is not a courtesy. It is the cheapest work on the desk.

The one situation where the routine shortens is the outage, where the first notice goes to many people at once. For that notice, the slots are the service, the impact and the next update time rather than a name. That message is a template of a different shape, written for an audience rather than a person. It is the subject of The First Notice. Everything that is a reply to one requester about one ticket gets the full ten seconds, including during the outage.

A Short War Story: The Printer That Was Not There at Meridian Parts

At Meridian Parts, a technician called Caleb kept a personal copy of the resolved template with the last ticket's details still in it. That was because it was quicker to overwrite them than to start from the blank slots. On a busy Wednesday he sent it to Amira in purchasing, whose locked account he had just unlocked, without overwriting anything. Amira received a message confirming that her printer on the second floor was now working and asking her to confirm. She replied that she did not have a printer, had never had a printer, and still could not log in, because the unlock had not taken. She copied her manager. The manager forwarded it to the IT manager with the question of how many other "resolved" tickets had been resolved for someone else. The IT manager, having no good answer, had the desk re-check every closure from that month. That meant a hundred and forty tickets, two technician-days, and three more wrong closures found. Caleb's read-aloud test would have taken three seconds and would have stopped at the word "printer". The lesson the desk wrote down was that a template with the wrong specifics in it is worse than one with none. The lesson also said that the three seconds of reading are cheaper than the two days of proving you did.

The Personalization Checklist

The checklist is the routine on one card, meant to sit beside the screen for the first month and in the technician's head after that. Print it, and run it on every templated message until it is a habit, which takes about two weeks of deliberate use. The timings are on it so that nobody can claim it is slow. The last section is for the desk lead. The lead checks a sample of sent messages against the checklist once a week during the first month and once a month after. That is because a routine that is not checked is a routine that fades.

PERSONALIZATION CHECKLIST — TEN SECONDS, EVERY TEMPLATED MESSAGE
Technician: ______________   Template used: ______________________   Ticket: ________

BEFORE THE TEMPLATE GOES IN
  [ ] Read the ticket, not the subject line
  [ ] This template's trigger matches this ticket's situation
  [ ] The requester field is the person with the problem, not a forwarder or a shared box

THE THREE THINGS THAT CHANGE (5 seconds)
  [ ] NAME: the one they signed with, not the directory's version
  [ ] THE SPECIFIC THING: their words for the problem, copied from their message
  [ ] THE TIME: a clock time or date I chose and will keep, and it is after now

THE ONE ADDED SENTENCE (3 seconds)
  [ ] One sentence in line two that could only be about this ticket:
        what I noticed / what I have checked / what I am doing first
  [ ] It is one sentence, not a paragraph

THE READ-ALOUD TEST (2 seconds)
  [ ] No bracket left unfilled
  [ ] No sentence I would not say standing at their desk
  [ ] The ask does not request anything the ticket already contains
  [ ] Nothing left over from the previous ticket
  [ ] The time is written in my own list before I press send

NOT PERSONALIZING
  [ ] No added warmth, exclamation marks or "hope you are well"
  [ ] Nothing about the requester that is not about this ticket
  [ ] The message is not longer than the raw template

DESK LEAD: WEEKLY SAMPLE (first month), MONTHLY (after)
  Messages sampled: ____   All three slots changed: ____   Added sentence present: ____
  "Did you read my ticket?" replies this period: ____   Template involved: ______________

Jonah ran the checklist for the rest of that month at Bellweather. His second message to Fatima, written by hand after her four words, took nine minutes and began with an apology he meant. His next hundred templated messages took about ten seconds each over the raw template, and none of them produced a "did you read my ticket?". The one that came closest was a time he forgot to change, caught by the read-aloud test at the word "12:00" at twenty past four. He said later that the test felt ridiculous for a week. He said he now does it to messages he has typed by hand, which is where it came from in the first place.

Frequently Asked Questions