What Tone and Voice Mean for a Help Desk

Tuesday, 09:40, at Meridian Parts. Dana took over the support desk a week ago and is reading last month's closed tickets to learn how the desk talks. Ticket 4471, a password reset, was answered by Tomas: "Reset. Policy requires change at next logon." Ticket 4473, a password reset, was answered by Lena: "Hiya!! All sorted, you should be good to go now, let me know if there's anything else at all!!" Ticket 4480, a password reset, was answered by Owen with a status change to Resolved and no words whatsoever. Three technicians, three replies to the same request, in the same hour, from the same desk. The requester on 4480 had added a reply of his own: "Is this still IT? It's a different person every time."

The desk does not have a voice. It has four, counting the automatic acknowledgement. That was written by whoever installed the tool and reads like the terms and conditions of a car park. None of the technicians did anything wrong. Nobody told them what the desk sounds like, so each of them guessed. Each guess was whatever they would have written to a friend, or to a magistrate.

Voice is who the desk is in every message it sends. It is the handful of traits a requester would recognise whether Tomas, Lena or Owen pressed send. Tone is how that same desk sounds in this particular message. It is lighter for a routine request, graver during an outage, plainer when the desk is apologising. Voice is decided once and written down. Tone is decided every time and never is. This article is part of our Support Tone & Voice series. This article is the one that defines the two words the rest of the series relies on.

It covers the difference between voice and tone, why a desk needs a voice at all, and the four traits worth choosing. Next come how tone moves with the moment while the voice stays put, with a picture, and the same message written in three voices. Then come where the voice lives, including the places nobody thinks of as messages, and how to choose a voice in an afternoon. A short war story and the one-page voice card to copy come last, in that order.

Voice Is Who the Desk Is; Tone Is How It Sounds Today

Think of a colleague you trust. They are the same person at a leaving do, in a tense budget meeting and at the hospital bedside of a friend. And you would recognise them in all three. What changes between those rooms is how loud they are, how many words they use, and how much of themselves they let show. The person is the voice. The volume, the pace and the warmth are the tone. A help desk works the same way, except that the "person" is six people and a form. That is why the voice has to be written down.

Voice is the part the requester should never notice changing. Suppose Priya in accounts gets a reply from Tomas on Monday and from Lena on Thursday. She should be able to tell they are different people, because they are. She should still feel that she is dealing with the same desk. Plain words both times. A next step both times. Somebody owning the problem both times. The signature changes; the character does not. A desk with a voice feels like one service. A desk without one feels like a lottery with a ticket number.

Tone is the part that should change, and change deliberately. A one-line "done, sign out and back in" is the right tone for a mailbox that took two minutes. It is the wrong tone for telling a department their shared drive is gone and the backup is from Friday. The same voice writes both messages. One of them is brief and light; the other is brief and grave, with no lightness anywhere near it. Tone that never changes is its own failure. (You have met the desk that is cheerful about everything. It is cheerful about data loss.)

The useful test is to swap the author. Take a reply and imagine another technician had written it. If the reply would still be right, you are looking at the voice. If it would be odd coming from anyone else, you are looking at either the author's personality or the moment. Only the moment is allowed to change the message. The author's personality is welcome at the desk. It is not what the requester came for.

Why a Desk Needs a Voice at All

A requester is not writing to Tomas. They are writing to "IT", a thing they picture as one entity that knows about their laptop. Every reply either confirms that picture or breaks it. A consistent voice confirms it. It tells the requester that whoever answers knows the same things, keeps the same promises, and will write the same way when the news is bad. That confidence is most of what people mean when they say a desk is "good". The fix was the same fix. The experience of asking for it was not.

A voice also removes a decision from every reply. Writing a support message under pressure involves choices the technician does not notice they are making. These include greeting or no greeting, how much detail, whether to apologise, and how to sign off. Without a voice each technician makes those choices alone, on every ticket, forever. The cost shows up as hesitation, as replies that take four minutes instead of one. It also shows up as the junior technician who copies the tone of whoever last replied to them. With a voice the choices are made once. The technician's attention goes on the problem, which is where you wanted it.

The third reason is that the voice is what the requester remembers when they decide whether to use the desk next time. People do not remember how long the reset took. They remember being told what would happen next, or not being told, and whether the desk sounded like it cared about the outcome. The quiet failures described in how support quietly fails start with a requester deciding, privately, that asking the desk is unpleasant. A voice is how you make asking pleasant without making it slow.

I learned this the expensive way, by not doing it. The first desk I ran had excellent technicians and no agreed voice, and the satisfaction comments split neatly by who had answered. One technician's requesters loved the desk. Another's thought it was rude. The fixes were identical. We were being graded on the wrapping, and we had let everybody choose their own paper.

The Four Traits Worth Choosing

A voice is three to five traits, no more, each one a thing a reader could check a message against. Pick fewer than three and the voice is too thin to recognise. Pick more than five and nobody can hold it in their head while typing, which means nobody will. The four below are the ones I would start every desk with. And most desks end up close to them after a year of trying something cleverer.

Plain words means the words the requester would use, in sentences they can read once. "Your mailbox is ready" rather than "the mailbox provisioning request has been actioned". The jargon problem has its own series in this library. The voice trait is simply that the desk chooses the plain word every time, even when the technical one is more precise. The desk explains the precise one only if the requester needs it. Plain is not the same as casual. A plain sentence can be as formal as the room requires.

Says what happens next means every message ends with the next step and, where there is a wait, a time. It says who does what, by when, and what the requester should do if that time passes. That is the single trait that most reduces follow-up e-mail, because the requester who knows when they will hear from you does not need to ask. The whole art of promising a time you can keep is in honest ETAs. The voice trait is the habit of always having one.

Owns the problem means the desk speaks as the party responsible for the outcome, even when the cause sits with a supplier, another team, or the requester's own cat. "We are chasing the supplier and will update you by three" owns it. "That is with the vendor" does not. Ownership is a sentence structure as much as an attitude: the desk is the subject of the verb. Sounds like a colleague means the message reads as if a competent person at the next desk wrote it. That rules out both the legal department and the greetings card. A colleague does not say "Dear Valued User". A colleague also does not use three exclamation marks. A colleague says "Hi Priya, that's done."

Notice that none of the four is "friendly", "professional" or "empathetic". Those are tones, and they are also words that mean something different to every person who reads them. A trait has to be checkable. "Did this message say what happens next?" has an answer. "Was this message friendly?" has an argument.

Tone Moves With the Moment, the Voice Does Not

Tone is set by three dials: length, pace and warmth. A routine request gets a short message, a relaxed pace and an easy warmth. A waiting-on-a-part update gets a slightly longer message, a steady pace and a specific, business-like warmth. An outage notice gets the shortest message of all, an urgent pace and no warmth to speak of, because forty people want facts and nothing else. A message about the desk's own mistake gets a plain, direct pace and the warmth of someone who means the apology. There are four moments, four tones. If you read the sample messages in the picture below you will find the same four traits in every one of them.

The picture makes the practical point: the voice is written down and the tone is not. You cannot write a rule for tone that survives contact with a real Tuesday. The right tone depends on who is asking, what has already happened on the ticket, and whether the building is on fire. What you can do is name the moments that come up most often and show one good example of each. That is what the voice card does. The technician reads the example, recognises the moment, and adjusts. Do not write a tone rule. Not one. Not "be friendly". It will be obeyed at a funeral.

Tone also drifts, and it drifts towards whoever on the desk writes the most. Leave a desk alone for a quarter and it has an accent. If the most prolific technician is terse, the desk becomes terse; if they are effusive, the desk starts using exclamation marks about printer toner. The voice card is the thing you drift back to. The peer-review habit in one voice across five people is how you notice you have drifted before a requester does.

The Same Message in Three Voices

The quickest way to feel the difference between voices is to write one message three ways. The situation is ordinary. Marcus in the warehouse asked on Monday morning when his replacement handheld scanner would arrive. The desk ordered it on Friday, the supplier says Wednesday, and nothing more can be done today. Below are three replies that contain the same facts. Each is a complete message somebody could send. And they are deliberately plain, because the point is in the comparison and not in any one of them.

THE SAME UPDATE IN THREE VOICES

1. The policy voice
   Dear Requester,
   Further to your request, please be advised that the
   replacement device has been ordered in accordance with the
   hardware replacement procedure. Delivery is anticipated
   within the standard lead time. Should you require further
   assistance, do not hesitate to contact the IT Service Desk.
   Regards, IT Service Desk

2. The pal voice
   Hey Marcus!! So sorry about this, totally get how annoying
   it is!! The new one is on its way, should hopefully be here
   soon-ish, fingers crossed! Let me know if there's ANYTHING
   else I can do :) Cheers, Lena

3. The colleague voice
   Hi Marcus,
   Your replacement scanner was ordered on Friday and the
   supplier has confirmed delivery for Wednesday. I will set
   it up and bring it to the warehouse that afternoon. If it
   slips, I will tell you here by 15:00 on Wednesday. Until
   then the spare at the goods-in desk is yours.
   Lena, IT desk

The policy voice is not rude; it is absent. Nobody is speaking. The passive verbs ("has been ordered", "is anticipated") have removed every person from the sentence. And "the standard lead time" is a number that only the desk knows. Marcus has learned that something happened and nothing about when. He will write again on Wednesday morning, politely, and he will be right to. The pal voice is warm and tells him even less. "Soon-ish" is not a day. "Fingers crossed" is not a plan. The apology is for a thing nobody did wrong, which, as empathy without being a doormat explains, costs the desk more than it earns. Both messages are the same length. Neither contains a Wednesday.

The colleague voice has all four traits and no decoration. It has plain words, a day, and a time by which Marcus will hear if the day moves. It has the desk as the subject of every verb, and a workaround he can use this afternoon. It is also the easiest of the three to write, once you have decided it is the voice. Every sentence answers a question Marcus actually has. The policy voice takes effort to sound like nobody. The pal voice takes effort to sound like your best friend. The colleague voice takes a day and a time.

Where the Voice Lives

The voice lives in every piece of text the requester sees with the desk's name on it, and most desks only think of one. The replies on tickets, yes. It also lives in the automatic acknowledgement that goes out when a ticket is created. That is the most-read message the desk sends and the one most often written by someone who no longer works there. It lives in the web form's labels and help text, the portal welcome page, and the out-of-office on the shared mailbox. It lives in the knowledge base articles the requester reads before deciding to ask, and the chat greeting. It lives in the one-line resolution note that arrives when a ticket is closed. Each of those is a message. Each of them is currently in somebody's voice, and it may not be the desk's.

Start with the acknowledgement, because every requester reads it and it sets the expectation for everything after. Suppose it says "Your request has been logged and will be dealt with in due course". The desk has then introduced itself as a department that uses the phrase "in due course". Rewrite it in the colleague voice: what happened, what happens next, and by when a person will reply. Then rewrite the knowledge base. A requester who reads an article written in the policy voice and a reply written in the colleague voice has met two desks. If you run QuerySolv, the articles everyone can read and the ones only agents see are already kept apart. In that case, the public ones are the list to read through for voice. In other tools, filter by visibility or ask whoever owns the knowledge base to point you at the requester-facing set.

The channel does not change the voice either. A request that arrives by chat, by e-mail, by the web form or by a message on a social account is the same request to the same desk. And a desk that is brisk on chat and ceremonious by e-mail has two voices with a routing rule between them. Every door may create the same kind of ticket in the same queue, as it does in QuerySolv and in many other tools. In that case, the voice is the one thing that should look identical on all of them. Tone may shift slightly with the channel, because chat is faster and shorter by nature. The traits do not.

How to Choose a Voice in an Afternoon

Do not start with a workshop. Start with thirty closed tickets, picked at random from the last two months, printed or opened side by side. And read the replies as a requester would. Mark the ones you would be glad to have received. On most desks there will be six to ten, and they will be written by two or three people. Then ask what those replies have in common, in checkable terms. They name a next step and use the requester's words. They are under a hundred words and sign off with a name. Those commonalities are the voice. You did not invent it. You found it in the replies the desk is already proud of.

Then bring the team in, with the good replies in front of them and the four traits as a starting proposal. The conversation you want is "which of these do we already do, and which do we only do when we have time?" The conversation you do not want is a debate about whether the desk should be "friendly". That can run for an hour and produce nothing a person could check. Give it forty-five minutes. Pick three to five traits. Write one example message for each of the four moments in the picture, from the real replies where possible. That is the card.

Test the card on somebody outside the desk before you call it finished. Hand a requester you trust two anonymised replies, one that follows the card and one that does not. Ask which desk they would rather deal with. If they pick the wrong one, the card is describing a voice the desk likes rather than one requesters want, which happens more than anyone admits. Then put the card on one page. I once wrote a six-page tone guide for a desk of four people. The team read the title, which was, to be fair, the best part.

Announce the voice the same way you would announce any change to the service, briefly and with an example. The technicians are not the only audience. If the acknowledgement and the portal text change on the same day, requesters will notice. In that case, a one-line note that says the desk has tidied up how it writes does no harm. The wider job of introducing a desk to its users is in announcing the desk. The voice is one part of that announcement, and it is the part people will hear in every message afterwards.

A Short War Story: The Two Desks at Stonebridge Insurance

Stonebridge Insurance's support desk had an automatic acknowledgement written by the legal team during the tool's installation. It opened "This mailbox has received your correspondence" and closed with two paragraphs about data retention. The desk's technicians, meanwhile, replied in a cheerful first-person voice that one claims handler described as "like a text from my nephew". Over one month, Farah, the desk lead, counted sixty-one duplicate tickets out of three hundred and forty. Almost all were raised because the requester read the acknowledgement as a bounce or a legal notice and sent their request again. Two further days were spent merging them. She rewrote the acknowledgement in the technicians' voice, with what happens next and a time. She asked the team to drop the nephew and keep the warmth. Duplicates fell to a handful the following month, and the claims handler asked whether the desk had hired someone new. A desk introduces itself with its first message. Stonebridge had been introducing itself as a law firm and then turning up as a relative.

The Voice Card

The card is one page: the traits, one line each on how to check them, one example message for each of the four moments. It also lists the two or three things the desk never does. Fill it in from the replies the team is already proud of and pin it where the replies are written. Give it to every new technician on their first morning along with five real tickets that follow it. The fuller style guide, with the sign-off, the subject line and the review habit, is the subject of one voice across five people. This card is the page it starts from.

THE DESK'S VOICE — ONE PAGE
Desk: ______________________   Agreed on: ________   Owner: ______________

WHO WE ARE IN EVERY MESSAGE (three to five traits, each checkable)
  1. ______________________   Check: _________________________________
  2. ______________________   Check: _________________________________
  3. ______________________   Check: _________________________________
  4. ______________________   Check: _________________________________
  5. ______________________   Check: _________________________________

HOW WE SOUND IN THE COMMON MOMENTS (one real example each)
  Routine request, done:
    _______________________________________________________________
  Waiting on something, with a date:
    _______________________________________________________________
  Something is down for many people:
    _______________________________________________________________
  We made a mistake:
    _______________________________________________________________

WE ALWAYS
  [ ] Open with the requester's first name
  [ ] End with the next step, who does it, and by when
  [ ] Sign off with a first name and the desk's name
  [ ] ______________________________________________

WE NEVER
  [ ] ______________________________________________
  [ ] ______________________________________________
  [ ] ______________________________________________

WHERE THIS VOICE MUST ALSO APPEAR
  [ ] Automatic acknowledgement       last rewritten: ________
  [ ] Web form labels and help text   last rewritten: ________
  [ ] Shared mailbox out-of-office    last rewritten: ________
  [ ] Public knowledge base articles  last reviewed:  ________
  [ ] Chat greeting                   last rewritten: ________

Reviewed every: ________   Next review: ________

Dana filled in the card at Meridian Parts on the Thursday of her second week, from eight replies the team picked out themselves. Six turned out to be Lena's with the exclamation marks removed. Tomas kept his brevity and added a next step. Owen started writing words. The acknowledgement lost its car-park paragraph and gained a time. Three weeks later Marcus in the warehouse replied to a ticket with "cheers, whoever this is", which Dana took as the compliment it was. He no longer needed to know who was on shift. That was the point.

Frequently Asked Questions