Home › Topics › IT's Internal Brand › The Language

The Language of the Desk: Replies, Signatures and Signs

Wednesday, 11:20, at Northgate Retail. Imogen, who runs the four-person desk, has been forwarded an e-mail by Carl, the manager of the flagship store, with one line above it: "Is this a real person?" Below it is the desk's own acknowledgement, which Imogen has never read because she has never raised a ticket. "Your request has been received and assigned reference NR-20417. Please do not reply to this email. Tickets are processed in order of priority in accordance with the IT Service Level Agreement. Thank you for your patience." It went to Carl at 09:02, and to roughly four hundred other people that month. It is the first thing every one of them hears from the desk, and the desk did not write it. The tool's installer did, five years ago, and nobody has looked at it since.

The language of the desk is every piece of writing a requester meets that nobody thinks of as writing. It is the acknowledgement, the signature at the bottom of a reply, the labels on the request form. It is the status names the requester sees and the sign on the door. Together they say more about the desk than any article or report, because they are read by everyone, every time. That is also because they were mostly written by a vendor, a predecessor, or someone in a hurry. This article is part of our IT's Internal Brand series. It is about taking those words back and making them sound like the people who work there.

It covers why the small writing matters more than the big, then the tone, borrowed from the series that owns it. Next come the no-jargon rule, names on replies and the signature, and auto-replies that sound like a person. Then it covers the portal copy, the words the tool chooses, such as status names, and the sign on the door. A short war story and the language guide to copy finish the article.

Why the Small Writing Matters More Than the Big

The desk's most-read piece of writing is its auto-reply, by a wide margin, and almost nobody on the desk has read it. A knowledge base article the team spent an afternoon on might be read forty times in a year. The acknowledgement goes out on every ticket. A desk handling four hundred tickets a month publishes it four hundred times, to four hundred people. It arrives at the exact moment they have just asked for help and are deciding what kind of department they have asked. The signature is read on every reply. The form labels are read by every requester before they have typed a word. These are the desk's brand, in print, at scale, and they were never drafted.

The reason the small writing is neglected is that it is not experienced as writing by the people who set it up. It is configuration. The acknowledgement was a default. The signature was copied from a predecessor's. The form labels are whatever the tool called the fields. The sign on the door was printed in a hurry after a bad week of interruptions. Each one is a sentence the desk says to the organisation hundreds of times, and each was composed with less care than a reply to a single ticket. (The reply to the single ticket, meanwhile, was agonised over.)

The fix is to find all of it, read it as a requester would, and rewrite it once in the voice the desk already uses when it is at its best. That takes an afternoon. The language guide at the end of this article is the record of the afternoon, so that the next person to configure anything knows what the desk sounds like. It is a short document. The desk's voice is not complicated; it has just never been written down.

The Tone, Borrowed

The desk's tone of voice is owned by another series in this library, and this article does not redo it. The other series covers what tone and voice mean, how to be warm without being a doormat, and how five people write as one desk. Those lessons are in One Voice Across Five People and its neighbours. The style guide there is the one to use. The brand article asks only one thing of it: that the same voice be used everywhere, including in the places nobody thinks of as writing. A desk whose replies are warm and whose auto-reply says "do not reply to this email" has two voices, and the requester hears the cold one first.

If the desk has not yet written its tone down, the three-word version is enough to start: plain, named, kind. Plain means words the requester would use. Named means a person's first name on everything a person sent. Kind means the reader's situation is acknowledged before the desk's process is explained. Every piece of small writing in this article can be checked against those three words, and most of the defaults fail all three at once.

The No-Jargon Rule

Jargon is any word the desk uses that the requester would not, and the no-jargon rule is that it does not appear in anything the requester reads. The rule is simple to state and hard to keep, because jargon is invisible to the people who use it. "Your ticket has been escalated" sounds like information to a technician and like a threat to a store manager. "The incident has been resolved" sounds like a close to the desk and like an insurance letter to everyone else. The craft of catching this in a reply is in Skipping the Jargon Without Dumbing It Down; here it is applied to the fixed writing, where one jargon word is repeated hundreds of times.

The table lists the words that appear most often in default auto-replies, signatures, forms and status names, with the plain version. None of the plain versions is longer than a sentence, and most are shorter than the jargon they replace. The test for any word not in the table is to ask whether the requester would say it to a colleague. Nobody has ever walked into a kitchen and said "my incident has been escalated to tier two".

The word the tool or the desk usesWhat the requester hearsThe plain version
"Your ticket has been escalated"Something has gone wrong, or someone is in trouble"I've passed this to Priya, who looks after the network. She'll be in touch by Thursday."
"Resolved" / "the incident has been resolved"A form letter; possibly it is fixed"Fixed. Here is what was wrong and what to do if it comes back."
"In accordance with the SLA"There is a rule and it is not for you"We aim to reply within the hour and to fix most things the same day."
"Pending" / "On hold"Nothing is happening and nobody will say why"Waiting for: a part / your reply / the vendor. Expected: Friday."
"Do not reply to this email"Go away"Reply to this message to add anything; it goes straight onto your ticket."
"End user" / "the user"I am a category"You"
"Root cause"A meeting is coming"What caused it"
"Impact" / "Urgency" / "Category" (as form labels)I do not know what to put here"How many people does this affect?" / "When do you need it by?" / "What is it about?"

Keep the jargon inside the desk, where it does real work. "Escalated", "incident", "priority two" and "on hold" are precise between technicians and belong in internal notes and in the queue. The rule is not that the desk stops using its vocabulary. It is that the vocabulary stops leaking into the requester's inbox. There, it does not inform anyone and reliably makes the desk sound like a department that would rather not be asked.

Names on Replies and the Signature

Every reply a person sends is signed with that person's first name, and the signature under it says who they are, how to reach the desk, and nothing else. "Imogen, IT desk, Northgate Retail. Reply to this message to add anything, or call the desk on 200. We're here 08:00 to 18:00 on weekdays." Four lines. No legal disclaimer, no inspirational quote, no request to consider the environment, no logo the size of a postcard. A signature is read on every reply. A reader who has to scroll past twelve lines of boilerplate to find the name learns that the desk's words are mostly not for them.

The name matters more than any other word in the signature, for a reason that has nothing to do with manners. People can thank a name, and they do; nobody has ever thanked "the IT department". People can also trust a name, forgive a name, and tell a new starter about a name. "Imogen sorted it" is a sentence that builds a brand; "IT sorted it" is a sentence that builds nothing, because IT is a budget line. A desk that signs its replies "IT Support" has chosen to be a budget line in its own correspondence. Sign it. The policy voice can have the internal notes.

Where the tool sends from a shared address, the sender shows as the desk rather than the person. The name goes in the text anyway, at the top ("Hi Carl, Imogen here") and the bottom. Some tools can show the technician's name as the sender; some cannot; check yours, and if it cannot, the first line of the reply does the job. The point is not the e-mail header. It is that a person who asked for help is answered by a person, and knows it.

Auto-Replies That Sound Like a Person

The acknowledgement is an automatic message and should still read as if a person had written it, because a person did, once. The requester reading it is deciding whether a person is on the other end. It has five jobs. It says the request arrived. It gives the number. It says who will look at it, or at least that someone will, and by when. It says how to add something, which in most tools is "reply to this message". And it says what to do if the matter is urgent and cannot wait for the reply time. Five sentences, in the desk's voice, with a name at the bottom, and no "do not reply".

Here is Northgate's, rewritten. "Hi Carl. Got it, thanks. This is ticket NR-20417. One of us will reply by the end of the hour with who's looking at it and when you can expect it done. If you want to add anything, just reply to this message and it goes straight onto the ticket. If it's stopping a till or a whole store, call the desk on 200 now and we'll jump on it. Imogen, for the IT desk." Compare it with the version at the top of the article. Same facts. One was written by a person who had just been asked for help and wanted the asker to feel it was going to be alright. The other was written by a configuration screen.

The sentence "just reply to this message" must be true before it is written. If you run QuerySolv, a reply to the acknowledgement lands on the same ticket as a public message in the thread. So the sentence is true by default. In some other tools, it is true only if the mailbox is set up to thread replies. In a few, it is not true at all. Test it with a real reply before you promise it. An acknowledgement that invites replies into a mailbox nobody reads is worse than the one that said "do not reply". That one was already bad. The craft of writing automatic text that does not sound canned is in Writing a Template That Does Not Sound Canned. It also covers keeping that text alive after the first draft. The acknowledgement is the most important template the desk has.

Review the acknowledgement every time it changes who reads it. A desk that adds a new department, a second site or a new channel is sending the same message to new people with different expectations. "Call the desk on 200" is a strange sentence to someone in a building where the desk is three hours' drive away. The acknowledgement is published four hundred times a month. It deserves a read four times a year.

The Portal Copy

The request form is the longest piece of writing most requesters read from the desk, and its labels are usually the tool's field names, which were written for administrators. "Category", "Impact", "Urgency", "Subject", "Description", "Submit". A requester faced with "Impact" does not know whether to write "high" or "I can't print". Either way, they feel they have failed a small test before anyone has helped them. Each label is a question the desk is asking. It should be written as one, in words the requester uses: "What is it about?", "How many people does this affect?", "When do you need this by?", "What's happening, and what did you expect to happen?"

The design of a form people will finish is the subject of A Request Form People Will Finish. That article covers the fields that are required and the ones that should not be. The brand article does not redesign the form. What the brand adds is the voice of the labels, the help text under each field, and the page after the button is pressed. "Your request has been submitted" is a tool talking. "Thanks, that's with us. You'll hear from one of us within the hour" is the desk talking. Both are configuration. One of them is a person.

The portal's front page is the sign on the desk's door for anyone who never comes to the building. The words on it decide whether people come back, which is the subject of Designing a Portal People Return To. The brand rule for it is the same as for everything else. It is written by a named person, in the desk's voice. It says what the desk will do rather than what the requester must. "All requests must be submitted via this portal" is a rule. "The quickest way to reach us is here; we see it in seconds" is a reason. People follow reasons.

The Words the Tool Chooses

Some of the desk's language is chosen by the tool and not by the desk. This includes the status names the requester sees on their ticket and the subject line the tool puts on its messages. It includes the wording of the satisfaction request and the name of the button. Some tools let the desk rename these; many do not; check yours, and do not assume. Where a word can be changed, change it to the plain version from the table. Where it cannot, the desk explains it once, in the acknowledgement or on the portal, in the requester's words. For example: "if your ticket shows as On Hold, it means we are waiting for something and the ticket will say what".

The status names are the ones that do the most quiet damage. A requester checks their ticket, sees "Pending", and learns nothing except that the desk has a word for nothing happening. A status alone is never an update. The update is the sentence that says what the desk is waiting for and when it expects to have it. The discipline of sending that sentence before the requester has to ask is in the expectations series. The language rule is only that the status name never travels alone. A word the tool chose is still the desk's brand when the requester reads it.

Remember: everything the requester reads from the desk is the desk's voice, including the words nobody wrote on purpose. Find all of it, read it as a requester, and rewrite it once: plain, named, kind. Then write down what you decided so that the next person to configure anything keeps it.

The Sign on the Door

The sign on the door is the only piece of the desk's writing that people read without needing anything, and it is usually the rudest. "NO WALK-UPS. RAISE A TICKET." was printed at Northgate after a week of interruptions and taped to the door with the capitals intact. Every person who walked down that corridor for two years read it. Most had never interrupted anyone. A sign is a sentence said to the whole building, all day, in the desk's absence. It should say what the desk will do for the reader, and it should say it the way the desk would if it were standing there.

"We're at our desks 08:00 to 18:00. Quick question? Knock, we're happy to help. Anything that needs doing properly, raise it at it.example.com or call 200 and we'll come to you." That sign gives the reader a way in, a reason to use the ticket, and the sense that the people behind the door are glad to be asked. That is the whole brand in forty words. The design of a walk-up window, with hours and a laptop and a way to log every visit, is the subject of Designing the Walk-Up Window Instead of Suffering It. The sign is the window's voice, and it can be fixed in an afternoon whether or not the window is.

The same applies to every notice the desk puts in the physical world. That means the label on the loan laptop, the card left on a desk after a visit, the printed guide next to the meeting room screen. Each one is read by someone who did not ask for help and is forming an opinion anyway. A card that says "Imogen was here at 10:15, fixed the docking station, call 200 if it plays up again" is a small piece of brand left on a desk. A card that says "IT SERVICE VISIT COMPLETED" is a small piece of brand too. It is just a worse one.

A Short War Story: The Do-Not-Reply Desk at Larkspur Media

Larkspur Media's two-person desk had, for three years, sent an acknowledgement that ended "please do not reply to this email, this mailbox is not monitored". That was true, because replies went to an address nobody had opened since the tool was installed. Ana, who took over the desk, opened it in her first week and found about a hundred and forty replies. Most were people adding the one detail the desk had later spent a day asking for. A few said "never mind, it's fixed". One was from the finance director, eleven months old. It said that the problem the desk had closed as "unable to reproduce" was still happening every Monday. Ana could count one cost: the twenty or so tickets where the desk had chased for information sitting in the dead mailbox for days. That was perhaps an hour each. The cost she could not count was three years of the first sentence anyone read from IT being "go away". It was also the finance director's view of the desk, which she had formed from that sentence and the silence after her reply. Ana rewrote the acknowledgement that afternoon, pointed the replies at the ticket, and signed it with her name. The first message people read from a desk is its brand. Larkspur's had said "do not reply" four hundred times a month for three years.

The Language Guide

The guide below is one page, kept beside the tone guide. It records what the desk decided its fixed writing should say. That way, a new technician, a new tool or a reconfigured form keeps the voice. Fill it once after the afternoon spent reading everything as a requester, and give it an owner and a review date. The sections are the places the desk's words live; the last section is the list of every one of those places, so that none is missed when something changes.

THE LANGUAGE OF THE DESK — ONE PAGE
Owner: ______________   Reviewed: ____________   Tone guide this follows: ______________

OUR VOICE IN THREE WORDS
  Plain: words the requester would use.  Named: a first name on anything a person sent.
  Kind: the reader's situation acknowledged before our process is explained.

WORDS WE DO NOT USE WITH REQUESTERS, AND THE PLAIN VERSION
  escalated -> "I've passed this to ______, who looks after ______"
  resolved -> "fixed"          incident -> "problem" / "outage"      end user -> "you"
  SLA -> "we aim to ______"    pending / on hold -> "waiting for ______; expected ______"
  root cause -> "what caused it"          do not reply -> "reply to this message to add anything"
  Others we have caught: ______________________________________________

THE SIGNATURE (every reply from a person)
  ______________ (first name), IT desk, ______________
  Reply to this message to add anything, or call ______ .  We're here ______ to ______ on ______.

THE ACKNOWLEDGEMENT (sent on every new ticket; tested that replies reach the ticket: [ ])
  Hi ______. Got it, thanks. This is ticket ______.
  One of us will reply by ______ with who's looking at it and when to expect it done.
  To add anything, reply to this message; it goes straight onto your ticket.
  If it's stopping ______ (what counts as urgent here), call ______ now.
  ______________, for the IT desk.

THE FORM (labels written as questions)
  What is it about?   How many people does this affect?   When do you need it by?
  What's happening, and what did you expect to happen?
  After the button: "Thanks, that's with us. You'll hear from one of us by ______."

THE SIGN ON THE DOOR
  We're at our desks ______ to ______.  Quick question? Knock.
  Anything that needs doing properly: ______________ (address) or call ______ and we'll come to you.

WORDS THE TOOL CHOOSES (renamed where possible; explained where not)
  Status names the requester sees: ______________________ -> explained in: ______________
  Subject line on our messages: ______________________
  Satisfaction request wording: ______________________

EVERY PLACE OUR WORDS LIVE (check all of them when anything changes)
  [ ] acknowledgement   [ ] signature   [ ] form labels and help text   [ ] page after submit
  [ ] portal front page [ ] status names [ ] satisfaction request         [ ] sign on the door
  [ ] visit card        [ ] loan kit labels   [ ] out-of-hours message     [ ] ______________

Imogen rewrote Northgate's acknowledgement on the Wednesday afternoon. She tested it by raising a ticket from her own mailbox and replying to it. She sent the new version to Carl with a one-line note. He replied, to the ticket, "Yes. That one's a person." The sign on the door came down on the Thursday and went back up on the Friday in forty words with a knock in them. The number of store managers who e-mailed Imogen directly instead of the desk went down over the following quarter. This was not because anyone was told to stop, but because the desk had started sounding like somewhere you could ask.

Frequently Asked Questions

Our tool will not let us change the acknowledgement text. What then?
Most tools allow at least the body of the automatic message to be edited, so check the mail or notification settings before giving up. If the text truly cannot change, send a short personal first reply within the hour on every ticket, which is good practice anyway. Make that reply carry the voice. The automatic message then becomes a receipt and the human one becomes the acknowledgement.
Should technicians use their full names or first names?
First names in the text, in the way colleagues address each other in your organisation; the full name can sit in the signature if the organisation's style expects it. The aim is that the requester can thank, trust and refer to a person. Where two technicians share a first name, add an initial rather than switching to surnames.
Is it unprofessional to drop words like "incident" and "escalation" from replies?
No; it is unprofessional to use words the reader does not share. Keep the precise vocabulary in internal notes and in the queue, where it does real work between technicians, and translate it at the boundary. "I've passed this to Priya, who looks after the network" is more precise to the requester than "escalated", because it tells them who and why.
How do we keep the voice consistent when five people write replies?
Write the tone guide the voice series describes, keep the language guide from this article beside it, and review three replies a week together for a month. The fixed writing, the acknowledgement, signature and form, carries most of the consistency on its own because it is the same for everyone. The replies then only have to match it.
What should the sign on the door say if we genuinely cannot take walk-ups?
Say what the reader can do instead, in the desk's voice, with a reason. For example: "We're usually out at desks or on calls, so the fastest way to reach us is the portal or 200; we see both in seconds and will come to you." Give the hours when someone is reliably there if any exist. A sign that only forbids has told the reader nothing they can use.
How often should the language guide be reviewed?
Every time the tool, the form, a channel or the audience changes, and otherwise twice a year. Raise a ticket from a personal mailbox and go through the whole journey as a requester: the form, the acknowledgement, a reply, a status check, the close and the survey. Anything that does not sound like the desk goes on the list.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.