Writing Clearly Under Pressure: The Reply Read in a Corridor

Friday, 16:40, at Penrose Architects. The file service has been dropping connections on and off since two o'clock. Dana has forty-one tickets about it, and she is typing replies as fast as she can. Across town, Kemi, a project architect, reads Dana's reply on her phone. She is walking from a site meeting to the car park with a roll of drawings under one arm. The reply is eleven lines long. Line one says "Thank you for reaching out regarding your issue." Line two says "We are aware that some users are currently experiencing intermittent difficulties accessing network resources." The one thing Kemi actually needs to do is to save her drawings locally and copy them back after six when the fix is in. That is in line nine. Kemi reads lines one and two, concludes that nothing has happened yet, and puts the phone back in her pocket. At six she loses the afternoon's work.

Writing clearly under pressure means producing a reply that still works when the writer has no time and the reader has less. That means a message that puts the state of things in the first line, and says what has been done. It gives the one next step and whose it is, says when the reader hears again, and stops. "Under pressure" applies to both ends. Dana is writing with forty tickets behind her. Kemi is reading with a roll of drawings under her arm, on a screen the width of her hand, in the thirty seconds between one thing and the next. A reply that needs a desk, a large screen and a quiet minute is a reply written for a reader who does not exist. This article is part of our Soft Skills for Technicians series. Clear writing is the fourth skill, the one that carries the other three to a reader who was not in the room.

It starts with who reads a support reply and how, then structure first, the five parts. Next come the first line that carries the message, plain words without dumbing down, and one next step and whose it is. Then it covers the apology that is not grovelling, writing fast without writing badly, and the internal note as a different document. A short war story and the reply structure to copy finish the article.

Who Reads a Support Reply, and How

The reader of a support reply is on a phone, in a corridor, between two other things. They will read the first two lines and decide from those whether to read the rest. That is not a criticism of the reader; it is how everybody reads e-mail on a phone, technicians included. The first two lines are visible without scrolling and without opening the message fully, in the preview, on the lock screen. That is where the message either lands or does not. Everything the writer needs the reader to know goes above that fold, and everything below it is a bonus.

The reader also does not share the writer's context, and this is the harder thing to hold in mind at 16:40. Dana knows the outage, the cause, the fix in progress and the timing, because she has lived inside it since two. Kemi knows that her drawings will not save and that she has a deadline on Monday. The reply has to be written for Kemi's context, not Dana's. The test is whether a reader who knows nothing but their own problem would know, from the first line, what is true now. "We are aware that some users are experiencing" tells Kemi what the desk knows. It does not tell her what is happening to her drawings.

Finally, the reader is probably anxious, and anxious readers skim for the word they fear and the word they hope for. They are looking for "fixed", "lost", "when", and "you need to". A reply that puts those words in a sentence that begins "Thank you for reaching out" has hidden them behind a pleasantry. Pleasantries are not wrong. They are simply in the way, at the one point in the message where nothing should be.

Structure First: The Five Parts

A reply written under pressure needs a structure decided in advance, so that the writer does not have to design the message while writing it. Five parts in a fixed order do the job for almost every reply a desk sends. First, what is wrong or what has happened, in one plain sentence. Second, what has been done. Third, the one next step, and whose it is. Fourth, when the reader hears from you next. Fifth, a name. The order is not negotiable, because the order is what makes the message survive the phone. The first two parts are above the fold, and they are the two that tell the reader the state of things.

The picture below draws the structure as a reply on a phone, with each of the five parts marked and the fold shown where the screen ends. The example is a resolved ticket, which is the easiest case. The same five parts work for a ticket that is still open. In that case, part one says what is wrong, and part two says what has been checked. Part three is "nothing for you to do" or one thing, and part four is a time. Notice what the example does not contain: an explanation of why the disk filled, a second request, or any apology longer than the fault deserved. Those are left out on purpose, and the rest of this article is about why.

Structure is what lets a tired writer produce a clear message, because it removes the decision about what to say first. On a quiet Tuesday a technician can compose a reply from scratch and do it well. At 16:40 on an outage Friday nobody composes anything. They type, and what comes out is the order in which the thoughts arrived. That is usually the order in which the technician experienced the fault rather than the order the reader needs. The five parts are a reader's order, fixed in advance so that the writer's state of mind cannot rearrange them. (It will try. The urge to begin with the backstory is strong and must be resisted every single time.)

The First Line Carries the Message

The first line of a support reply does the work of the whole reply, and it is the line most often wasted. "Thank you for contacting the service desk." "I hope this e-mail finds you well." "Further to your ticket." "Apologies for the delay in getting back to you." Each is a line that could be deleted without the reader losing a single fact. Each is sitting in the one place where a fact was needed. The first line says what is true now: "The file service is dropping connections and we are fixing it; save your work locally until six." That is the message. Everything after it is detail.

The quickest edit any technician can make to their writing is to delete their first sentence and see whether the message got better. It nearly always does, because the first sentence that comes to mind under pressure is a warm-up, a clearing of the throat before saying the thing. The reader on the phone has no time for warm-ups. Write the reply, delete the first sentence, and read what is now first. If it is a fact about the reader's situation, stop. If not, delete again. I have never deleted a third time and regretted it.

The first line is also where the repeat-back lives in writing. Listening for the problem behind the request made the case for saying the problem back in the user's own words before acting. In a reply, that is the first clause of the first line. "Your export is failing because the report server ran out of disk space" repeats the problem (your export is failing) and adds the one fact the user did not have (why). The user knows they were heard and knows what is wrong, in sixteen words, before they have scrolled.

Plain Words Without Dumbing It Down

The rule for jargon in a reply is simple to state and hard to keep. Use only terms the reader used first, and for everything else use the plain words. If Kemi wrote "the drive", the reply says "the drive", not "the file service" or "the share" or "the mapped network resource". If a technical term is genuinely needed because the user will meet it again, give the plain words first and the term after, once. For example, write: "the server that holds the reports, the report server, ran out of space". After that the term can be used alone. Skipping the jargon without dumbing it down is the full method, and this article borrows it rather than repeating it.

Plain words are not the same as fewer facts, and this is where "dumbing down" is a fair worry. "There was a problem with the server" is plain and useless. It tells the reader nothing they can act on and quietly implies they could not understand more. "The report server ran out of disk space overnight" is just as plain and contains the cause, the place and the time. The reader does not need less information. They need the same information in words they already own. Shortening the vocabulary is the skill; shortening the truth is the failure.

The table below sets a typical first draft against its rewrite, part by part, using Dana's outage reply. The left column is what came out at 16:40. The right is the same message in the five-part order, with the pleasantries removed and the one action moved to where Kemi would have seen it. Nothing has been added to the right-hand column except a time. Most of what has been removed was true, polite and in the way.

One Next Step, and Whose It Is

A reply carries one next step, never two, and it says plainly whose step it is. The reader on the phone can hold one instruction in their head between the corridor and the car park. They cannot hold "save locally, and also check whether your mapped drive letter is still showing, and let us know either way, and if you have any files open please close them". Each of those is reasonable. Together they are a list the reader will not act on, because a list on a phone is something you deal with later, and later is after six.

Whose step it is matters as much as what it is. "Save your drawings to your laptop" is the reader's step and is written as an instruction to them. "I will e-mail everyone at six" is the writer's step and is written as a promise. A reply where the two are muddled, "the user should save locally and the desk will update", has told the reader nothing about what to do with their own hands. Write "you" for their step and "I" for yours. If there is genuinely nothing for the reader to do, say so in those words: "nothing for you to do; I will come back to you by four." A reader told there is nothing to do stops worrying. A reader told nothing at all starts.

The trigger belongs with the step. "If it fails again today, reply to this message and I will ring you" has a step (reply), a trigger (if it fails again) and a consequence (I will ring). Without the trigger the reader does not know when the step applies; without the consequence they do not know what the step buys them. Three clauses, under twenty words, and the reader knows exactly what happens in every case. This is also where a reply stops being a message and becomes a small contract, which is what the user wanted all along.

The Apology That Is Not Grovelling

An apology in a support reply is one sentence, specific, with no reasons attached, placed after the fact and before the fix. "I am sorry; this has sat with me for three days and it should not have." Then the next sentence is what is being done about it. The grovelling apology runs to a paragraph. It apologises for "any inconvenience this may have caused", explains the queue and the leave and the vendor, and apologises again at the end. It has three faults. It is longer than the fault, it makes the reader responsible for forgiving, and it pushes the fix below the fold. Tone in hard moments covers apologies at length. This article takes only the structural point, which is that an apology is one of the five parts at most and never a sixth.

Specific beats general, and "I" beats "we". "I am sorry this took three days" names the thing and takes it on. "We apologise for any inconvenience" names nothing and takes on nothing, and readers can tell. The word "inconvenience" in particular has been so thoroughly used by recorded announcements that it now signals the opposite of an apology. If the reader lost an afternoon's work, say "I am sorry you lost the afternoon's work". If they did not, do not apologise for it. An apology for the right thing, in plain words, once, is received as sincere because it is.

The apology is also not a place for the reason, however good the reason is. The reader does not want to know that the queue was at forty-one; they want to know that the thing is being fixed and when. The reason goes in the internal note for the desk lead, where it is useful. It stays out of the reply, where it reads as an excuse. There is a kind of honesty in explaining, and I understand the urge. The reader has not got time for it, and the reasons never sound as good written down as they did in the technician's head.

Writing Fast Without Writing Badly

Writing fast is a matter of not composing, and the two tools for it are the template and the two-pass edit. A template is a reply already written in the five-part order with blanks where the facts go. A desk should have one for each kind of message it sends often. The series Templates and Canned Responses Done Right covers that from the library down to the ten-second personalisation. The template's job under pressure is to hold the structure so that the technician only has to supply the facts. Dana's forty-one replies, with a template, would have been forty-one fills of five blanks rather than forty-one small essays.

The two-pass edit is for the reply with no template. First pass: type the whole thing as it comes, badly, in whatever order the thoughts arrive, and do not stop to fix anything. The second pass takes about thirty seconds. Delete the first sentence. Find the one next step and move it to the third position if it is not there. Find the time and make sure it is a time of day rather than "soon". Check for any word the reader did not use first. Sign it with a name. The second pass is mechanical and that is the point. Under pressure nobody can judge their own writing, but anyone can run a checklist against it.

Length follows from structure and does not need a separate rule. But for the record, a reply that fits on one phone screen without scrolling is the target. Five short parts usually do. The outage reply to many people at once has its own discipline. That is because it is read by people with different problems and different patience. Outage Communication owns that discipline. The five parts still apply, with "what is wrong" widened to everyone it affects and "the one next step" chosen to be true for all of them. Dana's reply would have been the same five parts in either case. That is the useful thing about a structure: it does not care how many tickets are behind it.

The Internal Note Is a Different Document

The reply and the internal note are two documents with two readers. The technician under pressure writes both, in different styles, on the same ticket. The reply is for Kemi: five parts, plain words, one step, a time. The internal note is for the next technician and the desk lead. It says what was checked, what the cause was, what was ruled out, which server, and what the vendor said. It also gives the reason the reply took three days if it did. The note can use every piece of jargon the desk owns, because its reader owns it too. The two must never be confused. The commonest confusion is the reply that contains the note. In that case, Kemi is told the name of the disk volume and the vendor case number and still not told to save her drawings.

Most help desk tools separate the two, with a public reply the requester sees and an internal note they do not, on the same ticket. QuerySolv does. The separation lets a technician write "waited on the vendor for two days, chased twice" in the note. They can write "I am sorry this took three days" in the reply. Both are honest, each for its reader. The standard for what goes in the note, and what never goes in it, belongs to a one-page ticket note standard for the whole team. This article's only addition is that writing the note first, badly and fully, often makes the reply easier. That is because the technician has emptied their head of the backstory before trying to write the five lines the user needs.

A Short War Story: The Eleven-Line Reply at Stonebridge Insurance

At Stonebridge Insurance a claims handler called Marta raised a ticket on a Thursday morning because the claims portal was rejecting her document uploads. A technician called Owen replied within the hour with eleven lines that opened with thanks for her patience. The reply explained that the portal's upload service was being restarted by the vendor and apologised twice for the inconvenience. It said in the third paragraph that documents uploaded before the restart would need to be re-attached after six that evening. Marta read the first two lines on her phone between client calls. She understood that the desk knew about the fault and was dealing with it. She did not re-attach anything, because she never reached the third paragraph. The claim missed its submission deadline on Friday, and the client complained. Marta spent most of Monday rebuilding the submission with a manager's apology attached. The claims director costed that at a day of a handler's time and a conversation with a client the firm would rather not have had. Owen's reply had contained everything Marta needed. It had put the one thing she had to do in the one place she would never see it.

The Reply Structure

The structure below is the five parts as a fill-in sheet, with the second-pass checks underneath. It is meant to be the skeleton of every reply template a desk owns and the checklist for every reply written without one. The parts are in reading order and should stay that way. The checks are what to run in the thirty seconds before sending. Kept beside the keyboard for a fortnight, it becomes a habit. Kept on the wall after that, it is for the Friday afternoons, which is what it is for.

THE REPLY STRUCTURE — FIVE PARTS, IN THIS ORDER
Ticket: ________   Reader: ______________   Read on a phone? assume yes

1. WHAT IS WRONG, OR WHAT HAS HAPPENED (one plain sentence; the reader's problem in their words)
   ____________________________________________________________

2. WHAT HAS BEEN DONE (past tense; the cause if known, in plain words)
   ____________________________________________________________

3. THE ONE NEXT STEP, AND WHOSE IT IS (one only; the reader's step or the writer's; trigger if any)
   You: _______________________________________   or
   I:   _______________________________________   or
   "Nothing for you to do."

4. WHEN YOU HEAR FROM ME NEXT (a time of day or a date; never "soon")
   ____________________________________________________________

5. A NAME (a person, then the desk)
   ______________________, ______________________

IF AN APOLOGY IS DUE (one sentence, between 1 and 2; specific; no reasons)
   "I am sorry ______________________________; it should not have."

BEFORE SENDING (thirty seconds)
   [ ] Deleted the first sentence; what is now first is a fact about the reader's situation
   [ ] Parts 1 and 2 fit above the fold of a phone screen
   [ ] Exactly one next step; it says who does it
   [ ] A time of day, not "as soon as possible"
   [ ] No term the reader did not use first, unless given in plain words once
   [ ] No reasons, no backstory, no vendor case numbers: those are in the internal note
   [ ] Signed by a person

Dana rewrote her outage reply at 17:05, after a colleague read it on his phone and asked where the bit about saving locally was. The rewrite was five lines, took ninety seconds, and went to the forty-one people who had raised tickets and to the whole practice besides. Kemi did not see it, because she was already in the car, and the afternoon's drawings were gone. The next Monday the desk wrote the five-part structure into its three outage templates. Dana, who had written the original, wrote the sheet above and put it on the wall beside her screen. The sheet has stayed there through every Friday since.

Frequently Asked Questions