The Anatomy of a Good No: Five Parts in Four Sentences

Tuesday, 09:20, at Harbourview Clinic. Lena is reading ticket 5118 from Samir, one of the doctors. He wants his personal tablet set up to open the clinical records system. Then he can review notes from home in the evenings. The answer is no. Patient records do not go on unmanaged devices. The clinic's information governance lead would say so in one breath. Lena types: "Unfortunately due to policy we are unable to accommodate this request at this time. Please let us know if you have any other questions." She reads it back. It is polite, it is complete, and it says nothing: not which policy, not why, not what Samir could do instead. "At this time" even suggests there might be another time. Samir replies within ten minutes. "What time, then?"

A good no is a refusal the requester can understand, act on and repeat to their manager without making the desk sound unreasonable. It has five parts. They fit in four or five sentences: acknowledge what was asked, state the no plainly, give the real reason once, offer an alternative, and leave the door open. This article is part of our Saying No Professionally series. It is the one about the sentences themselves.

It starts with why the shape matters, with a picture of the five parts as one message. It covers each part in turn and the mistake each one prevents. Next come the words that ruin a no and six nos rewritten from bad to good. Then it compares saying it aloud with writing it down. A short war story and the no skeleton to copy finish the article.

Why the Shape Matters

A no fails in one of two directions, and the shape exists to stop both. It fails soft when the technician cannot bear to say the word. The message hedges, apologises and trails off into "at this time". The requester hears a maybe. It fails hard when the technician says the word and nothing else. The requester hears "go away" and does, usually to a manager or to a consumer-grade workaround. Lena's reply managed to fail in both directions in two sentences, which takes a certain talent.

The five parts are a sequence, and the sequence is the point. Acknowledging first proves the request was read by a person. Stating the no second means the requester knows the answer before they read the reason. They read the reason as an explanation rather than as a wind-up to bad news. The reason third, in one sentence, is what they will repeat to their manager. The alternative fourth is what they will actually do. The door fifth is what stops the no becoming a grievance. Move the parts around and each one does a worse job. Leave one out and the message reads as either evasive or cold.

The picture below shows the five parts as one short message to a warehouse team about a label printer. A note beside each part says what that sentence does for the reader. Read the left column top to bottom as the requester would, then the right column as the writer should. The whole message is five sentences. Nothing in it is a policy number, nothing in it is "unfortunately", and the requester finishes it knowing the answer, the reason, what happens next and how to come back.

Part One: Acknowledge the Ask

The first sentence shows the requester that a person read what they wrote, and it does so by using their words. "Thanks for asking about the label printer for the warehouse" tells the warehouse that the desk knows it is a label printer. The desk knows it is for the warehouse. It is about to answer that question rather than a general one. "Thank you for contacting IT" tells them nothing except that a template exists. The difference is one clause. It is the clause that decides whether the rest of the message is read as a reply or as a form letter.

Acknowledging is not agreeing, and the sentence should not pretend to. "I can see why you'd want this" is honest when it is true and poison when it is not. In that case, the requester will hear the "but" coming from the far end of the corridor. Prefer a plain restatement of the need: "You need the notes from home in the evenings", "You want the plug-in for the design work on Thursday". Naming the need also sets up the alternative later. The alternative has to meet the need, not the request. The two are often different. Samir does not need his tablet on the records system. He needs to read notes in the evening.

Keep it to one sentence. Two sentences of acknowledgement before a no reads as stalling, and three reads as an apology for what is about to happen. The requester can feel the no approaching, and a long run-up makes it loom. Say the kind thing once, then say the answer.

Part Two: State the No Plainly

The second sentence contains the word no, or not, or won't, and does not contain a hedge. "We won't be installing it on the dispatch PC." "Admin rights aren't given to user accounts." "That isn't something the desk does." Each is short and unmistakable. A tired person on a phone at the end of a shift can read each without wondering whether it means maybe. Plainness here is a kindness. The requester asked a question and is owed an answer before anything else.

The hedges to avoid are the ones that soften the no until it disappears. "We are unable to" implies a technical impossibility when the truth is a decision. The requester will reasonably ask why you cannot simply become able. "At this time" implies a later time. "I'm not sure we can" implies a negotiation has opened. "It might be difficult" implies it is possible for someone who pushes. Every one of these is written out of kindness. Every one of them costs the requester a second conversation, because they leave the first one unfinished. The brief guidance for a desk's house style on hard sentences like this one lives in Tone in Hard Moments. The short version is that clarity is the kind option, and softness is the kind-looking one.

Say no to the request, not to the person. "We don't give admin rights to user accounts" is about a rule. "I can't give you admin rights" is about you and them, and it invites "why not me?" The grammatical subject of the no sentence should be the desk, the rule or the thing. It should never be the requester, and preferably not the technician either. The no was decided before the ticket arrived. The sentence should sound like it.

Part Three: Give the Real Reason, Once

The third sentence is the reason. The test of a reason is that it is the one you would give your own manager if they asked. "Because one bad install on an admin account can reach the whole network" is a reason. "Due to security policy" is a reference to a reason, stored somewhere else, which the requester is invited to go and find. "As per IT policy section 4.2" is a reference with a filing number. People accept decisions they understand far more readily than decisions they are told exist, and the understanding fits in one sentence nearly every time.

One sentence, and only one. A reason that runs to a paragraph reads as a defence, and a defence invites a prosecution. The requester will pick the weakest clause and argue with it. Now the technician is debating network architecture with a doctor who wanted to read notes in bed. The longer reasoning exists and belongs in the ticket, where colleagues can read it, but it does not belong in the reply. If you run QuerySolv, the public reply and the internal note sit on the same ticket. The one-sentence reason to the requester and the three paragraphs of reasoning for the next technician can live side by side. Only the first one leaves the building.

The reason must be true. Not plausible, not official, true. "Because the licence doesn't allow it" will be exposed as false when the licence does allow it and the real reason is that nobody has time. Usually the requester discovers it by reading the licence. From then on every reason the desk gives is suspect. If the real reason is embarrassing ("because nobody here knows how to support it"), say a dignified version of it ("because it was never approved and nobody on the desk is trained on it, so I can't promise you a fix"). A true reason the requester dislikes is survivable. A false reason they catch is not.

Part Four: Offer the Alternative

The fourth sentence gives the requester something to do, and it is the sentence that turns a refusal into help. The alternative comes in four kinds. It can be a workaround that meets the need another way, or a partial yes that grants the safe part of the request. It can be a later yes with a date, or the name of who else can help. Samir cannot have records on his tablet. But the clinic has a managed laptop he can borrow or a secure remote desktop he can sign into. It also has a reading room that is open until eight. Any one of those meets the need he actually has. The full set of alternatives and when each applies is the subject of Offering an Alternative Instead of a Wall. Here the rule is only that there is one, and that it is concrete.

Concrete means it has a who or a when attached. "I can put it on the spare desktop by Thursday" is an alternative. "There may be other options" is a shrug in a suit. "You could try the guest network" is halfway, and becomes an alternative when it says what the guest network will and will not give them. If the alternative involves another person, name them and say what you have done to connect the requester to them. If it involves a date, give the date and intend to keep it. An alternative the technician does not mean is worse than none, because it fails later, in a second ticket, with the first no attached as evidence.

Sometimes there is no alternative, and then the honest sentence is to say so. "I don't have another way to get you this, and I'd rather tell you that than send you round in circles." Requesters forgive a straight no with no alternative far more readily than they forgive a fake one. The skill is in making sure there really is none before you say it, which usually means asking a colleague first.

Part Five: Leave the Door Open

The last sentence names a way back, so the no is a decision rather than a dismissal. "If that doesn't work for you, reply here and we'll look at it again." "If you need an exception, Priya in information governance is the person who can approve one." "If Thursday moves, tell me and I'll re-plan." Each of these says: this conversation is not over because I ended it. It is over because the question is answered, and you can reopen it from your side.

The door has to be real, which means the route it names has to work. "Reply here" only works if a reply to a resolved ticket actually reaches someone. Most tools reopen a resolved ticket when the requester replies. A few leave the reply attached to a closed record nobody will look at. Test yours by replying to one of your own resolved tickets from a personal address and seeing what happens. Where a requester's reply reopens the ticket, as it does in QuerySolv, "reply here" is a genuine door. In that case, the whole history is waiting behind it when they walk through. Where it does not, name a person or an address instead.

Leaving the door open is not reopening the question. The no stands. The door is for new information, a changed situation, or an exception from the person who can grant one. The sentence should make that plain. Say what would change the answer rather than inviting another round of the same request. "If the records team approves remote access for your role, we'll set it up the same day" opens a door with a named handle. "Let me know if you have any questions" opens a door onto the same corridor the requester just walked down.

The Words That Ruin a No

Certain words appear in bad nos so reliably that you can grade a reply by counting them. They are not rude; they are worse than rude, because they sound professional while removing every piece of information the requester needed. Most of them were learned from other bad nos, and most desks have a template somewhere that contains all of them in a row. The table gives what each one actually says to the person reading it, and what to write instead. None of this is about tone for its own sake. It is about whether the requester can act on the message.

Read your own last ten nos against the table and count. Most technicians find four or five of the phrases in every message, arranged in the same order, because they were all copied from the same place. Removing them does not make the message blunt. It makes the message say something, which is a different thing and takes some getting used to.

Six Nos Rewritten From Bad to Good

The table below takes six requests a small desk sees every month. It shows the no as it is usually written beside the same no in five parts. None of the bad versions is rude. Each is polite, short, and useless, and each generated a second conversation that the good version would have prevented. Read the right-hand column for the pattern rather than the wording: acknowledge in their words, the no in plain words, one reason, one concrete alternative, one door. The wording will be yours. The pattern should not change.

Notice that the good versions are longer, and that none of them is long. Four or five sentences is the natural size; the bad versions are short because they left out the parts that take thought. Notice also that three of the six good versions include a yes. The plug-in gets installed, the chat program goes on the laptop, the deck gets done by Wednesday. A good no is frequently a yes to the need and a no to the method. That is why acknowledging the need in the first sentence matters so much. You cannot say yes to something you have not named.

Saying It Out Loud and Writing It Down

The five parts are the same in person, on the phone and in a ticket. The order matters more when speaking, because the requester can interrupt. A spoken no that opens with the reason gets interrupted at the reason, and the technician never reaches the no, let alone the alternative. Say the acknowledgement, say the no, and then pause. The requester's first reaction belongs to them. Then the reason, the alternative and the door, in that order, and shorter than you would write them. In person the whole thing takes about twenty seconds, which feels like a very long time while you are standing there.

Whatever was said aloud goes in the ticket afterwards, in the same five parts, as a public reply the requester can see. Partly this is for the requester, who may not remember the alternative by the afternoon. Mostly it is for the desk. A no that exists only in a hallway conversation cannot be defended when the manager phones. It cannot be counted when the rule is reviewed. It cannot be matched by the colleague who gets the same request on Thursday. A spoken no that is not written down was, for every purpose except the requester's feelings, a yes that happened not to be done.

Writing a no takes longer than writing a yes, and the time is well spent. Five minutes on a good no saves the second ticket, the manager's phone call and the week of the requester quietly working around the desk. If a request comes in often enough that the same no is written every week, it is a candidate for a saved reply. Leave the acknowledgement and the alternative blank to be filled in by hand each time. How to write one that does not read like a form is in Writing a Template That Does Not Sound Canned. The reason, in a saved reply, is the one part that must never be shortened into a policy number to save typing. It is the part the requester came for.

A Short War Story: The External Drive at Stonebridge Insurance

At Stonebridge Insurance, a claims handler called Tom asked the desk to exclude his team's shared folder from the storage quota. Scanned claims correspondence was filling it faster than the quota grew. A technician called Ruth closed the ticket with "Not possible, policy." Tom read "not possible" as a technical fact. He bought a large consumer drive out of the team's stationery budget. He kept the overflow of scanned claims on it under his desk for seven months. Nobody at the desk knew. The drive failed on a Monday; it had never been backed up, because nothing under a desk is. Stonebridge had to ask around three hundred customers to resend documents they had already sent. It notified its regulator of the loss and had two handlers spend a fortnight doing nothing else. The quota decision had been correct, and so had Ruth's no. But the alternative had existed the whole time. The records team ran an archive store for exactly this and would have taken the scans in an afternoon. A no without its reason and its alternative is heard as "find your own way", and people do.

The No Skeleton

The skeleton below is the five parts with blanks. Keep it where you write replies and use it until the shape is habit. That takes a few weeks. Fill it from the top: tick the kind of no first, because the sorting in Why No Is Hard at a Help Desk decides which alternative lines apply. Use the requester's own words in the first blank. Pick one alternative line, not three. The checklist at the bottom is the one to run before sending, and the first question on it catches most of what the others would.

THE NO SKELETON — FOUR OR FIVE SENTENCES
Ticket: ________   Kind of no:  [ ] not us   [ ] not now   [ ] not ever

1. ACKNOWLEDGE  (one sentence, in their words; name the need, not just the ask)
   "Thanks for asking about ______________."
   "You need ______________ for ______________."

2. THE NO  (one sentence, plain; the word no, not or won't appears)
   "We won't be ______________."
   "We don't ______________."
   "That isn't something the desk does."

3. THE REASON  (one sentence, true; fit to be repeated to a manager)
   "...because ______________."
   Not: "due to policy"  "as per"  "for security reasons"  "at this time"

4. THE ALTERNATIVE  (pick one; it has a who or a when)
   Workaround:   "What you can do now is ______________."
   Partial yes:  "I can do ______________, which covers ______________."
   Later yes:    "I can do this by ______________ and will update you on ______________."
   Who else:     "______________ owns this; I have passed it to them with your details."
   None:         "I don't have another way to get you this, and I'd rather say so."

5. THE DOOR  (one sentence; a named way back)
   "If that doesn't work for you, reply here and we'll look again."
   "If ______________ changes, tell me and I'll re-plan."
   "If you need an exception, ______________ can approve one."

BEFORE SENDING
   [ ] Would I say this, in these words, to their face?
   [ ] Is the no one sentence, with no hedge in it?
   [ ] Is the reason one sentence, and true?
   [ ] Is the alternative something I will actually do, by the date I gave?
   [ ] Does the longer reasoning live in an internal note, not in the reply?

Lena rewrote 5118 from the skeleton on the Tuesday. "You need to read clinical notes from home in the evenings. We don't put the records system on personal devices, because a lost or unpatched tablet would carry patient data outside the clinic. What I can do is set you up on the secure remote desktop, which works from your home computer and takes about fifteen minutes to configure; I can do it this afternoon. If remote desktop doesn't suit how you work, reply here and we'll look at the managed-tablet option with the governance team." Samir replied in six minutes. "Yes please, this afternoon." It was the same no. It was simply finished.

Frequently Asked Questions