Writing Like a Person, Not a Policy: Six Rewrites

Wednesday, 11:20, at Ashgrove Housing. Farah, a housing officer, forwards a reply from the IT desk to the colleague at the next desk. She puts one line on top: "Can you translate this?" The reply reads, in full: "Further to your recent correspondence, please be advised that the aforementioned issue has been escalated to the relevant team for investigation. We will endeavour to provide an update in due course. We apologise for any inconvenience caused. Please do not hesitate to contact the IT Service Desk should you require further assistance." Farah's colleague reads it twice and says, "I think it means they've given it to someone." Nobody knows who, or when Farah will hear, or whether she should keep trying to print.

Sam wrote it. Sam is a good technician who had, in fact, passed the ticket to Tomas, who looks after the printers. Sam expected to hear back by the afternoon. Asked why none of that was in the message, Sam said, "That's how you're supposed to write to people, isn't it?" He had learned it somewhere, at school or at the bank he worked at before, and nobody at the desk had ever told him otherwise. Every fact Farah needed was in Sam's head. The message was written to keep them there.

Corporate filler is any phrase that takes up room in a sentence without giving the reader something they can use. Examples include "please be advised", "at this time", "going forward", "as per", "endeavour", "reach out", "any inconvenience caused". Writing like a person means writing a reply that a competent colleague could have said out loud across a desk. It gives the same facts, in the same order a listener would want them. This article is part of our Support Tone & Voice series, and it is the practical one. It takes six messages every desk sends and rewrites each one.

It covers why replies come out sounding like policies, then plain words, with a swap table. Next come short sentences that carry one thing each, followed by the filler phrases and why each one is empty. It covers who did what, and why the passive voice hides it, then the sign-off and the subject line. It finishes with a short war story and the six before-and-after rewrites to copy, in that order.

Why Replies Come Out Sounding Like Policies

Nobody decides to write like a policy. It happens because formal language feels safe. A technician writing to a stranger about a problem they have not solved yet wants to feel safe. "The issue has been escalated" commits nobody to anything. "I have passed this to Tomas and he will call you by two" commits Sam, Tomas and a clock. The formal version is a hedge dressed as politeness, and most people who write it do not know that is what they are doing. They think it is professional. It is only the sound of professional.

The second cause is the tool. Most help desk tools ship with default acknowledgements and templates written by someone who was trying to offend nobody in any industry. That text sets the register for everything the desk writes afterwards. A technician who reads "Your request has been received and will be processed in accordance with our service levels" every morning starts to believe that is what the desk sounds like. Filler breeds in templates. One "going forward" and by spring the auto-reply has a mission statement.

The third cause is the news. When a reply has to say something the requester will not like, the sentence grows passive and long. It might say that it is delayed, that it cannot be done, or that the desk got it wrong. That happens because a long passive sentence is a place to hide. "It has been determined that the request cannot be accommodated at this time" has no person in it. Nobody determined anything; it was determined. This is understandable, and it is also the reason requesters distrust formal replies. They have learned that the formal ones are where the bad news lives. The way to carry bad news without hiding is the subject of tone in hard moments. The way to stop hiding in the routine ones is the rest of this article.

Plain Words

A plain word is the one the requester would have used. Not the shortest word, not the most casual word, the one they would say. Farah would not say "correspondence"; she would say "my ticket" or "my e-mail". She would not say "the aforementioned issue"; she would say "the printer". The test is to read the sentence aloud and ask whether you would say it across a desk to a colleague. If you would not say it, do not type it. The ear catches what the eye has stopped seeing after years of reading corporate text.

The swap is nearly mechanical once you have the list, and a list is below. Most of the formal words have a plain twin that means the same thing and is shorter. "Utilise" is "use", and "endeavour" is "try". "Prior to" is "before", and "in the event that" is "if". Some formal words have no twin because they mean nothing. "Aforementioned" is pointing at a thing you could just name. "Accordingly" is a word that joins two sentences while adding nothing to either. Jargon is the technical words that are precise to the desk and opaque to the requester. It is a different problem with its own article in skipping the jargon. Filler is worse than jargon in one way. Jargon at least means something to somebody.

Do not treat the table as a banned list to enforce. Treat it as a list of the places where a reply is hiding, so that a technician rereading their own draft knows where to look. Each phrase in the left column marks a spot where the writer could have said who, what or when and chose not to. The replacement in the middle column is rarely the clever part. The clever part is noticing that there was a who, what or when to say.

Short Sentences, One Thing Each

A support reply is read on a phone, in a corridor, by someone who has eleven other things to do. They want to know one thing: what happens to my problem now. Long sentences fight that reader. A sentence that carries two facts and a condition will be read for one fact. And the one the requester keeps is not reliably the one that mattered. Keep sentences to one idea. Fifteen words is a good average. Twenty-five is where a reader on a phone starts skimming. Forty is a sentence that is going to be forwarded with "can you translate this?" on top.

Order the sentences the way a listener would want them. What happened to the ticket. What happens next, who does it, by when. What the requester should do in the meantime, if anything. Then stop. Sam's reply to Farah, in that order, is three sentences: "I have passed your printer ticket to Tomas, who looks after the printers. He will call you before 14:00 today. Until then, the printer by the kitchen on the second floor is on the same network and will take your jobs." Every fact Sam had is now where Farah can use it, and the reply is shorter than the one that said nothing.

Cut the sentence that announces the next sentence. "I wanted to let you know that" is followed by the thing you wanted to let them know; start there. "Just a quick update on this one:" is followed by the update. "I hope this e-mail finds you well" is followed, usually, by news that will not. Each of these costs the requester a line of reading before the message starts. On a phone a line of reading is a thumb movement. A reply that starts with the fact respects the thumb.

Filler, and Why Each Piece Is Empty

"Please be advised" is a sentence clearing its throat. Nothing follows it that would not have been clearer without it. It carries a faint tone of warning, as if the reader were about to be served a notice. "We apologise for any inconvenience caused" apologises to nobody for nothing. It has been doing so on out-of-order signs for as long as there have been lifts. The word "any" admits that the writer does not know whether there was an inconvenience. The requester, who does know, reads the sentence as proof that nobody looked. If the desk caused a problem, name it and apologise for that. If it did not, do not apologise, for the reasons laid out in empathy without being a doormat.

"In due course", "at this time", "currently" and "going forward" are all the same word, and the word is "when?", left unanswered. Each of them sits where a date should be. A technician who writes "we will update you in due course" almost always knows roughly when. They have chosen a phrase that cannot be held against them over a time that could. The requester notices the choice. "Endeavour" is the same move applied to effort: "we will endeavour to" means "we might not", said in a way that sounds like commitment. I wrote "endeavour" in support replies for two years. I was not endeavouring. I was waiting for a part.

"Please do not hesitate to contact us" is a sentence that describes a hesitation the requester was not having. It invites them to a conversation the desk would rather they did not start. It is also the most copied sentence in support writing, which is why it means nothing. The reader has seen it at the bottom of every message from every organisation they have ever dealt with. They have learned that it is where messages end. Replace it with the actual instruction. "Reply here if the printer stops again." "If you have not heard from Tomas by two, reply to this and I will chase him." Those sentences tell the requester what to do, and they are shorter.

Who Did What

The passive voice removes the person from the sentence, and in a support reply the person is the point. "The ticket has been escalated" is a thing that happened to a ticket. "I have passed this to Tomas" is a thing Sam did, with a name the requester can hold onto. The difference is not grammatical fussiness. A requester who knows a named person has their problem stops worrying about whether anyone does. A requester who knows their ticket "has been escalated" has been told that it moved, and nothing about where.

Use the active voice for anything the desk did, is doing or will do, because those are the sentences where ownership lives. "I have reset your password." "Tomas will call you." "We ordered the part on Friday." Use "I" for things you did and "we" for things the desk did as a desk. Do not use "we" to avoid saying "I" when the thing was yours. The passive is fine for things that happened without an actor worth naming: "the server restarted at 03:00", "your mailbox was migrated overnight". Nobody needs to know who pressed the button. They need to know who to ask if it did not work, and that is a name.

The place where technicians most want the passive is the mistake. "An error occurred during the migration" is easier to type than "I migrated the wrong folder". It is also the sentence requesters trust least, because they have read it before, from organisations that were hiding something. The desk's own mistakes are a different article. The rule here is simple: if a sentence has no person in it, ask whether one was removed. If one was, put them back.

The Sign-Off

The sign-off is a first name and the desk's name, on two lines, and nothing else. "Sam" on one line, "IT desk" on the next. No job titles, because the requester does not need to know Sam is a Service Desk Analyst II. The title makes the message feel like it came from an organisation chart. No taglines, because "Making IT work for you!" under every message turns into wallpaper by the second week. It turns into a small irony on the day the e-mail is down. No "Kind regards" if the desk would not say it aloud; "Thanks" is fine, and so is nothing, if the name is there.

The first name matters because it is the difference between a reply and a notice. A notice comes from a department. A reply comes from a person who can be asked a follow-up question. And the name is the handle the requester uses to do that. The desk's name on the second line is what keeps the reply from being personal. Farah is writing to the desk and Sam is answering for it. If Sam is away tomorrow, the next reply will come from the same desk under a different first name. The whole mechanism of five people sounding like one desk is laid out in one voice across five people; the sign-off is where it is most visible.

Resist the corporate signature block. Somewhere in most organisations is a communications team that would like every outgoing message to carry a logo and three lines of legal text. They would like a social media icon and the words "valued colleague". The desk's replies are outgoing messages. Make the case once. A support reply is a message between colleagues about a broken thing, and it is read on a phone. A signature block longer than the reply is the reason requesters stop scrolling before they reach the next step. Most communications teams will accept a plain sign-off for internal support replies when they see one beside the alternative.

The Subject Line

The subject line is the only part of the reply the requester reads before deciding whether to open it. On most desks it is written by nobody. The tool copies the original request, so the message that says "your laptop is ready to collect" arrives under "laptop broken AGAIN". The message that says "we need you to confirm which account" arrives under "RE: RE: RE: access". It sits in a list on a phone, between a newsletter and a calendar invitation. The requester does not open it. The desk waits three days for an answer to a question the requester never saw.

Change the subject line when the news changes. Write what happened, in the requester's words, and nothing else. Examples are "Your laptop is ready to collect from reception" and "Printer ticket: Tomas will call you before 14:00". Another is "One question before I can set up your access". A good subject line says what happened, who it is for, and nothing else. Keep the ticket number in it if the tool needs that to thread the reply, but put it at the end. A line that starts with a number is read as a notice. Not every tool lets you change the subject on a reply. Most do, some only on the first reply, a few not at all. Check yours, and if it cannot be changed, put the news in the first line of the body so that the preview shows it.

Where the subject line cannot change, the first sentence does its job. Most mail clients show the first few words of the body under the subject. And a body that starts "I wanted to let you know that" shows the requester nothing. A body that starts "Your laptop is ready at reception" shows them the news without opening it. Write the first sentence as if it were the subject line, and the preview does the rest.

A Short War Story: The Notice at Bellweather Logistics

Bellweather Logistics' desk sent a planned-maintenance notice three days before the dispatch system went down for an upgrade. It read, in its entirety, "Please be advised that scheduled maintenance will be performed on the dispatch application during the specified window, during which the service may be unavailable. We apologise for any inconvenience caused." Nadia, the desk lead, had approved it because it was accurate. The specified window was not in the message. And the message looked like every other notice the drivers' depot had ever ignored, so it was filed with them, unread. Fourteen drivers arrived at six on the morning of the upgrade and found the dispatch screens blank. They waited ninety minutes with their engines off while the depot manager rang a desk that did not open until half past seven. The rewrite Nadia sent for the next upgrade was four lines. It said what was going down, from when to when, what the drivers should do instead, and her own name. Every driver had read it, because for the first time it had been addressed to someone. A message that sounds like a policy is filed with the policies, and nobody reads the policies.

Six Rewrites, Before and After

The six messages below are the ones every desk sends most, each shown as it commonly arrives and as it reads when written by a person. They are the template for this article: copy the "after" versions into the desk's style guide or template library and change the specifics. Each "after" is shorter than its "before". It contains a name, a next step and, where there is a wait, a time. It could be read aloud across a desk without embarrassment. The pairs are deliberately plain; the point is the gap between them.

SIX REWRITES — BEFORE AND AFTER

1. THE ACKNOWLEDGEMENT
Before:
  Your request has been received and logged under reference 5209.
  It will be processed in accordance with our service levels. Please
  do not hesitate to contact the IT Service Desk should you require
  further assistance.
After:
  Thanks, Farah. Your printer ticket is 5209. A person will reply
  before 11:00 this morning. Reply to this e-mail if anything changes.
  IT desk

2. THE "WE'RE LOOKING INTO IT" UPDATE
Before:
  Please be advised that the aforementioned issue has been escalated
  to the relevant team for investigation. We will endeavour to provide
  an update in due course.
After:
  Hi Farah, I have passed your printer ticket to Tomas, who looks
  after the printers. He will call you before 14:00 today. Until
  then, the printer by the second-floor kitchen will take your jobs.
  Sam, IT desk

3. ASKING FOR INFORMATION
Before:
  In order to progress your request, kindly provide the required
  details at your earliest convenience.
After:
  Hi Farah, one question before I can set this up: which of your two
  accounts should have the access, the housing one or the repairs one?
  Reply here and I will do it the same day.
  Sam, IT desk

4. TELLING THEM IT IS DONE
Before:
  The issue has been resolved. This ticket will now be closed. We
  apologise for any inconvenience caused.
After:
  Hi Farah, the printer is working again. The cause was a jammed
  roller, which Tomas has replaced. Print something today to check;
  if it fails again, reply here and this ticket comes straight back
  to us.
  Sam, IT desk

5. TELLING THEM IT IS DELAYED
Before:
  Unfortunately, due to unforeseen circumstances, the resolution of
  your request has been delayed. We will endeavour to provide an
  update as soon as possible.
After:
  Hi Farah, the replacement part did not arrive today as promised.
  The supplier now says Thursday. I will tell you here by 15:00 on
  Thursday either way. The second-floor printer is still yours until
  then.
  Sam, IT desk

6. PASSING THE TICKET TO SOMEONE ELSE
Before:
  Your ticket has been reassigned. The new assignee will be in touch.
After:
  Hi Farah, I am on leave from tomorrow, so Priya is taking over your
  ticket. She has everything from this thread and will reply to you
  by Monday lunchtime. Nothing is needed from you.
  Sam, IT desk

Two of the six deserve a note. The fourth, the done message, tells Farah that a reply reopens the ticket, and that sentence is only honest if the tool does it. Most tools reopen a resolved ticket when the requester replies to it, and some do not, or only within a window. If you run QuerySolv a requester's reply to a resolved or closed ticket brings it back. That is what makes "reply here and this ticket comes straight back to us" a true sentence rather than a hopeful one. Test yours by replying to a closed ticket from a personal address before you put the sentence in a template. The sixth, the handover, says what the requester needs to do, which is nothing. A handover that does not say so produces a requester who re-sends everything to the new name, just in case.

Sam rewrote his own replies at Ashgrove for a week with the table beside him. By the Friday the second-floor printer sentence had become a habit and "please be advised" had gone. Farah did not forward any more of his messages for translation. She did forward one to her manager, the done message, with "this is what IT should sound like" on top, which Sam has kept. He still writes formally to the bank. He no longer writes to Farah like one.

Frequently Asked Questions