One Voice Across Five People: Sounding Like One Desk

Monday, 08:50, at Redbrook Engineering. Owen runs a desk of five and has a message from the finance director waiting for him: "Which of your lot is the rude one?" He spends twenty minutes reading every reply the desk sent to the finance team in the last fortnight and finds nothing rude. He finds Priya, who writes four warm sentences for a password reset. He finds Marcus, who writes "Done." He finds Lena, who signs off "Lena, your friendly IT Ninja Squad". He finds Sam, who writes like a solicitor, and Tomas, who copies whoever replied last. Hana in finance had a ticket answered by Priya on Tuesday and by Marcus on Thursday. She read the difference as a judgement about herself. Nobody was rude. The desk had five voices, and a requester who hears five voices assumes at least one of them is about her.

Consistency is not a nice-to-have on top of a good desk. It is the thing that lets a requester trust the next reply before they read it. When replies vary by author, requesters start to prefer authors, address tickets to people, and wait for their favourite to come back from leave. The queue becomes five queues with one address. The previous article in this series, what tone and voice mean for a help desk, decides what the voice is. This one is about getting five people to use it.

A desk style guide is one page that says how the desk writes. It covers the voice traits and the mechanics of a reply (greeting, sign-off, subject line, how steps are laid out). It includes six real example replies and the short list of things the desk never writes. Peer review of replies is a colleague reading a sample of your sent replies against that page and telling you what they saw. This article is part of our Support Tone & Voice series. This article is about the page, the review, and the two other things that carry a voice across a team. Those are how new people are brought into it and the template library.

It covers why five people drift apart and why the guide is one page and mostly examples. Next come the mechanics worth fixing, with a table, and peer review that takes twenty minutes a week. It covers onboarding a new technician into the voice, then the template library as the carrier. Keeping the voice when the desk grows follows, along with a short war story. It ends with the one-page desk style guide to copy, in that order.

Why Five People Drift Apart

Everyone has a default way of writing to strangers, and it was set long before they joined the desk. Priya writes warmly because she was raised to. Marcus writes briefly because he types with two fingers. Sam writes formally because his last job was in a bank. None of these defaults is wrong. They are simply different, and on a desk where nobody has said what the desk sounds like, the default is what the requester gets. Five people left alone will produce five sign-offs, and one of them will involve the word "ninja".

The drift matters because requesters read differences as meaning. Hana does not know that Marcus is terse with everyone. She knows that Priya wrote four sentences and Marcus wrote one. The only variable she can see is herself. A short reply after a long one reads as impatience. A formal reply after a warm one reads as a complaint having been made. The technicians have communicated nothing of the kind. And the requester has heard it anyway, because people read tone into everything and a desk gives them five tones to compare.

The second effect is that requesters pick favourites. Once Hana has decided Priya is the kind one, she addresses her next ticket "Hi Priya" and waits for Priya to answer it. If Priya is on leave the ticket waits with her. The desk has not noticed, because the ticket is in the queue and the queue looks fine. Preference by author is one of the ways a queue quietly splits. The whole pattern of tickets waiting for an absent person is described in keeping tickets from hiding. A single voice does not stop requesters liking some technicians more than others. It stops them needing to.

The third effect is the quiet one: the newest technician copies the loudest. Tomas, in his first month, had no idea what the desk sounded like. So he copied whichever reply he had read most recently. His replies to the same requester changed from day to day. He was not inconsistent by nature. He was inconsistent because the desk gave him five models and no way to choose. A written voice is the choice made for him.

One Page, Mostly Examples

The style guide is one page. Not one page of rules with appendices, not a document with a contents list, not a shared folder. One page, printable, pinned where replies are written, and read in full by a new technician in under ten minutes. The reason is not aesthetic. A guide that is longer than one page is not read. And a guide that is not read is a page of good intentions with a version number. If it reaches two pages, cut the second one. Yes, that one.

Here is what goes on the page, in order. First are the three to five voice traits, with one line each on how to check a message against them. Next come the mechanics, as a short list of decisions already made. Then come six example replies, real ones from the desk's own tickets with names changed, one for each of the moments that come up most. Last is the never-list, three to six things the desk does not write. What stays off the page: grammar, spelling, the serial comma, the correct use of the semicolon. My own first style guide had a section on the serial comma. The desk had a four-day backlog at the time, and I had opinions about punctuation.

Rules get argued with. Examples get copied. That is the entire reason the page is mostly examples, and it is why the examples must be real. A rule that says "always end with a next step" produces a meeting about what counts as a next step. An example reply that ends "I will update you here by three on Wednesday, whether the part has arrived or not" produces technicians who write that sentence. (Nobody has ever read a grammar section to the end. Including the person who wrote it.) The six examples should cover: a routine request done, a wait with a date, a question back to the requester, a boundary, an outage notice, and an apology. If the desk has a seventh common moment, swap one out rather than adding.

Harvest the examples from the last two months of tickets, not from anyone's imagination. The team picks the replies they are proud of, and the lead picks the ones requesters responded well to. The overlap is the set. Refresh them twice a year, because an example from three years ago is in a voice the desk has already left. The examples are also the test of the guide. If a new technician can read the six and write a seventh in the same voice for a moment that is not on the list, the page is working. If they cannot, add a line to a trait or swap an example, and do not add a rule.

The Mechanics Worth Fixing

The mechanics are the small decisions that every reply makes and that nobody should have to make twice. They cover how the message opens, how it closes, and what the subject line says. They cover how steps are laid out and whether the message asks one question or three. These are the places where five people visibly differ. They are also the easiest to fix, because they are not matters of taste once the desk has decided them. The table below lists the ones that matter and a reasonable default for each. Your desk may choose differently; the point is to choose once.

Two of these deserve a word. The subject line is the most neglected sentence the desk writes. The tool fills it in with the original request and nobody changes it. So the message that says "your laptop is ready for collection" arrives under the heading "laptop broken again". Change it when the news changes. And the reply-versus-note decision is where a lot of inconsistency hides. One technician puts the diagnostic reasoning in the public reply because it shows effort. Another puts the "I'll call you at two" in an internal note by mistake. And the requester gets either too much or nothing. The rule on the page is one line: the requester gets what the requester needs, the ticket gets the rest.

Peer Review in Twenty Minutes a Week

Peer review of replies is the habit that keeps the guide alive after the first month, and it is far lighter than it sounds. Once a week, each technician is given ten recent replies written by a colleague, chosen at random. They read them against the page with two questions only. Would I know this came from our desk? Is there anything here the requester could not act on? They write one line of feedback per batch, not per reply, and hand it over in person or in the team chat. No scores. No forms. No "areas for development". Twenty minutes, once a week, and the pairs rotate so nobody is always read by the same person.

Pulling the sample is the only part that needs a tool, and every ticketing tool can do it. The replies are in the tickets, and a filter by author and date gives you ten. If you run QuerySolv, every reply and every internal note sits in the ticket's event history. In that case, a colleague's week is a filter and not an archaeology dig. In other tools, look for the agent activity view or export a week of tickets and sort by who replied. The sample should include the boring tickets. A desk that reviews only the hard replies learns to write hard replies well. It lets the routine ones, which are most of the volume, drift back to "Done."

Include the lead in the rotation, as a reviewer and as the reviewed. A desk where the lead's replies are never read against the page has a page with an exception written into it. And the team can see the exception. The lead's job in review is also to notice patterns across pairs. If three people in a month say Marcus's replies have no next step, that is a conversation. If three people say the subject lines across the whole desk still say "RE: RE:", that is a line to add to the mechanics. Review that produces no changes to the page in six months is review that has stopped looking.

The failure mode to watch for is review becoming surveillance. It becomes surveillance when scores appear, when the feedback goes to a manager rather than to the writer, or when it is tied to anything on a performance form. Keep it between colleagues, keep it to two questions, and keep it about the page rather than the person. The question is never "is Marcus a good writer". It is "would Hana know this came from us".

Onboarding a New Technician Into the Voice

A new technician learns the voice in a month if you plan it, and in a year if you leave it to happen. The plan has four stages, and the first one is on day one. On the first morning, they get the page and five real tickets that follow it, and read both before they write a single reply. The five tickets matter more than the page, because they show the voice in motion. They show the requester's question and the desk's answer and the follow-up that did or did not happen. Choose tickets that cover the six moments between them.

In the first week, every reply they write is read by their buddy before it is sent. Not corrected: read, with the same two questions as peer review, and a thirty-second conversation if the answer to either is no. This sounds slow and is not. A new technician in their first week writes perhaps fifteen replies a day. Reading fifteen short messages takes a buddy ten minutes. In the second week the buddy reads after sending, same questions, same day. In the third and fourth weeks the new technician joins the normal rotation. In week four they review somebody else's ten. That is the moment the voice stops being a thing done to them and becomes a thing they can see.

Say the one thing out loud that the page cannot: copy the voice, not the person. A new technician given Priya as a buddy will, with the best intentions, start writing like Priya. Priya's warmth is Priya's, not the desk's. The traits are the desk's. The words are the technician's own. The test on the page is the one to repeat. Would a requester know this came from our desk? Could they tell it was a different person? Both answers should be yes. A desk where they cannot tell has produced a script, and scripts are the subject of a different kind of complaint.

The Template Library Carries the Voice

On most desks, more than half of outgoing replies start from a template. That fact is the single biggest lever on consistency that nobody pulls on purpose. If the templates are in the voice, half the desk's replies are in the voice before anyone has typed a word. That includes the replies written at ten to six by someone who has not read the page in a month. If the templates are in the voice of whoever wrote them four years ago, the desk has two voices with a keyboard shortcut between them. The library is where the voice is stored. Treat it that way.

Rewriting the library is the second thing to do after the page exists. The first five to rewrite are the five most used. The tool can usually tell you those, and the team can tell you if it cannot. Each one is rewritten against the six examples: same greeting, same sign-off shape, a next step with a blank for the time, plain words, one question. The craft of a template that still reads like a person wrote it is in writing a template that does not sound canned. What goes into the library and how it is kept from rotting is the subject of that whole series. The point here is narrower: the voice page and the template library must agree. When the page changes, the library changes the same week.

Do not let the library become the only carrier. A desk that has good templates and no page produces good templated replies. It produces five different voices the moment a ticket needs an original sentence. That is exactly the ticket where the voice matters most. The page teaches the voice, and the library applies it to the routine. Peer review catches the drift, and onboarding passes it on. Remove any one and the other three carry more than they can hold. The library is the most powerful of the four and the least able to explain itself.

Keeping the Voice When the Desk Changes

The voice is most at risk at the moments nobody is thinking about it. Those include a new channel, a new department served, a merger with another team, a new manager with preferences. Each brings a new set of defaults into the desk, and each is a reason to reread the page rather than rewrite it. A chat channel will pull the desk shorter and faster, which is fine for tone and must not change the traits. A newly served department with external customers will pull it more formal. That belongs in the formality decision described in the desk's personality and its limits rather than in the voice. A merged team arrives with its own page, or without one. And the two desks become one by agreeing one set of examples, which takes an afternoon and should not take longer.

Give the page an owner, named on the page. Their job is to reread it twice a year with the review findings in hand and to make at most a handful of changes. The owner is also the person who says no to the branding request. Somewhere in the organisation's future is a committee that would like the desk to close every message with the corporate tagline. The owner's answer is that the sign-off is a first name and the desk's name. That is what the examples show, and the examples are what requesters trust. Tone drifts towards the loudest writer. Voice drifts towards the most recent meeting. The owner's job is to be heavier than both.

A Short War Story: The Chart at Northgate Retail

Northgate Retail's desk of five had no written voice. The five technicians signed off five different ways, from "Kind regards, IT Service Desk" to "Cheers! Dev, IT Ninja Squad". Lena, who ran the desk, found out how the store managers had adapted when she visited the flagship store. She saw a sheet taped inside the manager's office door. It had five names, a smiley or a frown beside each, and the note "ask for Priya or Dev, avoid Sam". The managers had been addressing tickets to Priya and Dev by name. When both were on leave in the same week, twenty-three store tickets sat in the queue addressed to people who were not there. Meanwhile, the other three technicians assumed the tickets were spoken for. Two stores ran a weekend on a broken label printer each, and the regional manager asked why the desk had "stopped answering". Lena wrote the page the following Monday from eight of Priya's and Dev's replies. She retired the Ninja Squad and put a line in the acknowledgement saying the next available technician would reply. The chart came down a month later. A desk with five voices does not have five technicians. It has one, chosen by the requester, and four the requester is avoiding.

The One-Page Desk Style Guide

The guide below is the template for this article. It is one page, in the order a new technician should read it. The examples are left as blanks because they must be your desk's own. Fill the traits from the voice card and the mechanics from the table above with your desk's choices. Fill the six examples from real tickets with the names changed. Print it, pin it, and give it to the next person who joins on their first morning with five tickets that follow it.

DESK STYLE GUIDE — ONE PAGE
Desk: ______________________   Owner: ______________   Reviewed: ________

1. OUR VOICE (every message, every channel)
   Trait: ____________________   Check: __________________________________
   Trait: ____________________   Check: __________________________________
   Trait: ____________________   Check: __________________________________
   Trait: ____________________   Check: __________________________________

2. THE MECHANICS (decided once)
   Greeting:       ______________________________________________________
   Sign-off:       ______________________________________________________
   Subject line:   says what happened, in the requester's words
   Steps:          numbered, one action per line, end with what they will see
   Questions:      one per message, or a numbered list
   Public reply:   what the requester needs.  Internal note: what the desk needs
   Length:         under ____ words unless the content needs more

3. SIX REAL EXAMPLES (names changed; refreshed every six months)
   Routine request, done:
     _____________________________________________________________________
   Waiting on something, with a date:
     _____________________________________________________________________
   A question back to the requester:
     _____________________________________________________________________
   A boundary, stated kindly:
     _____________________________________________________________________
   Something is down for many people:
     _____________________________________________________________________
   We made a mistake:
     _____________________________________________________________________

4. WE NEVER WRITE
   [ ] ____________________________________________________________________
   [ ] ____________________________________________________________________
   [ ] ____________________________________________________________________
   [ ] ____________________________________________________________________

5. HOW WE KEEP IT
   Weekly peer review: ten replies each, two questions, rotating pairs
     Q1: Would the requester know this came from our desk?
     Q2: Is there anything here the requester cannot act on?
   New starter: page plus five tickets on day one; buddy reads before
     sending in week one, after sending in week two, joins rotation week three
   Templates: rewritten against section 3 whenever this page changes
   Next review of this page: ________

Owen wrote Redbrook's page on the Tuesday after the finance director's message, from six replies the team chose. Four were Priya's and two, to everyone's surprise, were Marcus's, with a next step added. Sam kept his formality and lost "Further to". Lena kept her warmth and lost the ninjas. Tomas, who had been copying everyone, copied the page instead. That was the first time his replies had sounded like the same person two days running. The finance director did not write again. Hana did, a month later, to say thanks for a fix, and addressed it to "IT", which is the right name for a desk.

Frequently Asked Questions