Why No Is Hard at a Help Desk, and the Three Kinds of No

Thursday, 15:40, at Tollgate Foods. Jonah has been on the desk four months. Carla from purchasing is standing beside him with her laptop open. "Can you just give me admin on this? I only need it to install the supplier's price tool. Two minutes, honestly." Jonah knows the answer. Local administrator rights are not given to user accounts. It is on the second page of the IT policy, and he agreed with it when he read it. But Carla is pleasant. She is the one who remembers everyone's birthday. The queue is quiet, and the sentence "I'm afraid we don't do that" has not come out of his mouth once since he started. He types the password. Two minutes.

The price tool needs a database driver, which takes twenty more minutes. On Monday two more people in purchasing have heard that Jonah will sort you out. In six weeks the tool is on nine laptops, none of which the desk can patch without breaking it. Purchasing has built its month-end process around it. In the autumn an auditor asks who approved it. The answer is nobody, which is the answer that gets written down.

A no, at a help desk, is a decision that the desk will not do a particular thing, said to the person who asked, in words they can act on. It sounds simple and it is the hardest sentence in support. This article is part of our Saying No Professionally series. The series covers how to decline a request without losing the requester or the rule. This article is the one about why the word is so hard to say and why there is more than one of it.

It covers the helper instinct that makes yes the default; the fear of the complaint; and the hidden cost of yes, which is the part nobody sees until it is large. It covers what a no is not; and the three kinds of no, not us, not now and not ever, and why each needs different words. It then covers how to tell them apart in the moment; a short war story; and the three-kinds card to pin beside the screen, in that order.

The Helper Instinct

People join a help desk because they like fixing things for other people, and no is the one answer that fixes nothing. Every other sentence a technician says moves a problem forward: "try this", "I have reset it", "it is with the supplier". No stops the conversation, hands the problem back, and leaves the requester holding exactly what they arrived with. For someone whose whole day is measured in problems removed, that feels like failure. The feeling arrives a good deal faster than the policy does.

The instinct is reinforced by every tool and measure the desk uses. A closed ticket is a success; a request declined is a closed ticket with a sad note on it. Satisfaction surveys ask the requester how the interaction felt, and a no rarely feels good in the moment, however well it was said. Nobody has ever been thanked in a team meeting for the thing they refused to install. The system rewards yes, quietly and every day, which is why the instinct is not a personal weakness. It is the shape of the job.

The instinct also has a structural flaw that is easy to miss. The yes is said by the person least placed to see what it costs. Jonah sees Carla, a laptop and two minutes. He does not see the nine laptops, the month-end process or the auditor, because those are six weeks away and belong to somebody else's afternoon. The person who feels the cost of a yes is almost never the person who gave it. It is usually whoever has the queue when the thing breaks.

Watch, too, for the phrase that opens most of these requests. "Can you just" is not a question about ability. It is a request to skip the part where somebody decides. It works because it frames the decision as already made and the technician as the only thing in the way. The honest reply to "can you just" is nearly always "I can, and the question is whether we should". Say that in your head before anything is said aloud. The two-second pause that sentence buys is where most good nos begin.

The Fear of the Complaint

Underneath the instinct is a plainer fear: the requester will complain, and the complaint will go to someone who outranks the technician. "IT refused to help me" is a short sentence that travels well. It reaches a manager who was not there. That manager hears a story about a rude technician and an unreasonable rule. They may well phone the desk to ask why it is making their department's life difficult. The technician who said no is now explaining a policy they did not write to a manager they have never met. The technician who said yes is having a quiet afternoon.

The fear is rational, because the complaint about a no is loud and the complaint about a yes is silent. Nobody phones a manager to say that IT installed something it should not have. The cost of the yes arrives months later, as an outage, an audit finding or a licence bill. By then it is nobody's fault in particular. The cost of the no arrives in about an hour, with a name attached. A technician weighing the two is not being cowardly. They are responding accurately to what the organisation has made expensive.

The fix for the fear is not courage; it is cover. A technician can say no comfortably when three things are true. The rule is written down somewhere the requester can read it. The manager who will receive the complaint already knows the rule and will back it. The technician has words for the no that do not sound like "because I said so". The first belongs to the scope documents described in Scope Boundaries. The second is the subject of A No the Whole Team Can Stand Behind. The third is what the rest of this series is for. Without all three, the fear wins, and frankly it should.

The Hidden Cost of Yes

Every yes the desk did not mean to give has a cost. The cost is nearly always paid later, by someone else, in a currency the desk does not count. Carla's admin rights cost Jonah two minutes and cost the desk a software estate it cannot patch. A "quick" request to keep an old server running costs nothing today and a weekend next year. A personal phone joined to the staff network "just for the conference" costs nothing until the conference is over and the phone is still there. The costs are real. They are simply not on today's ticket.

The costs come in four shapes. The first is the precedent: a yes to one person is a yes to everyone who hears about it. People talk about the technician who helped far more than about the one who declined. The second is the maintenance: anything the desk sets up, the desk now owns, whether or not it meant to. That is because the owner of a thing is whoever gets the ticket when it breaks. The third is the risk: admin rights, unapproved software and unmanaged devices are exactly the things the security policy exists to prevent. A policy with exceptions nobody recorded is a policy nobody can rely on. The fourth is the scope: a desk that says yes to everything is a desk whose job is defined by whoever asked most recently. That is the slow failure described in Scope Creep and the Expanding Catalog.

The sharpest way to see the cost is to count the tickets a yes generates. Carla's price tool produced eleven tickets in its first three months. They were two more installs, four "it stopped working after the update", three about the driver, and two from people in other departments who wanted the same thing. None of those tickets was labelled "consequence of Jonah's two minutes", which is why a desk never sees the pattern unless it goes looking. If you run QuerySolv, linking those later tickets back to the original request is the cheap way to make the cost visible. One chain of tickets hanging off one yes is an argument no spreadsheet makes as well.

None of this means the answer is always no. Most requests that reach a help desk should be granted, quickly and cheerfully, because that is the job. The point is that yes has a price. A desk that cannot say no has no way of deciding which prices are worth paying. A no, said well, is not the opposite of helping. It is how a desk keeps enough of itself to help the next person.

What a No Is Not

A no is a decision, and most of what passes for no at a help desk is not a decision at all. "I'll have a look" with no intention of looking is not a no; it is a yes that will quietly fail. A ticket closed with "not supported" and no other words is not a no; it is a door shut on someone who still has the problem. Silence, the most common no of all, is a ticket left in the queue until the requester stops asking. It is not a decision either. It is the absence of one, delivered slowly.

These substitutes are popular because each avoids the moment where the technician says the word and watches the requester's face. That moment is uncomfortable for about four seconds. The substitutes trade those four seconds for weeks of a requester who does not know where they stand. They also leave a queue carrying tickets nobody intends to work, and a desk whose answers cannot be trusted. That is because "I'll have a look" might mean yes, no, or never. The uncomfortable four seconds are the cheapest part of the whole transaction. Everything else costs more, and the most common mistake is not saying no badly. It is saying the wrong no.

Three Kinds of No

Most of the trouble with no comes from treating it as one word when it is three decisions. The first is not us: the request is reasonable. But the desk is the wrong place for it, because another team, a supplier or a different process owns it. The second is not now: the desk would do this, and will, but not today. That is because of time, approval, a part on order or a change window. The third is not ever: the desk will not do this at all, because a policy, a safety concern or a cost decision says so. More time would not change the answer.

They need different words because the requester needs different things from each. Someone told "not us" needs a direction: where do I go instead? Someone told "not now" needs a time: when, and what will I hear in the meantime? Someone told "not ever" needs a reason and, if one exists, a route to an exception. Give the wrong one and the conversation goes wrong in a predictable way. A "not now" that is really a "not ever" becomes a broken promise. A "not ever" that is really a "not us" sends somebody away from help that was one door down the corridor. A "not us" that is really a "not now" is a technician handing their own queue to a colleague.

The kinds also differ in who gets to decide. A technician can usually decide a not-us alone, because knowing who owns what is the desk's job. A not-now is usually the technician's call too, within whatever service levels the desk has published. A not-ever is a rule, and rules are decided above the desk. That is why a technician saying not-ever should be pointing at something written rather than at themselves. The decision was made before the request arrived. The technician is only the person delivering it, which is a far more comfortable place to stand.

Not Us: The Wrong Door

A not-us is the easiest no to say and the easiest to say badly. The request has come to the wrong place. The broken desk lamp belongs to facilities. The payroll question belongs to HR. The supplier's software is supported by the supplier under a contract the desk has never seen. Nothing about the request is unreasonable. It has simply walked through the wrong door, usually because the IT desk is the only door in the building that reliably answers.

Said badly, a not-us is "not our problem", or its polite cousin "you'll need to raise that with facilities". It is delivered with no name, no address and no idea whether facilities has a desk at all. The requester leaves with less than they arrived with, because they now know one place that will not help and still do not know one that will. Many of them give up, and the lamp stays broken. Some of them come back, angrier, and the second conversation is harder than the first one would have been.

Said well, a not-us has three parts: who owns this, how the requester reaches them, and what the desk has done to help them get there. "This one is owned by the facilities team. Their request address is facilities@example.com, and I have forwarded your message to them with your desk number. So you should hear from them rather than having to ask twice." Where the tool holds several departments in one help desk, each with its own queue and mailbox, a not-us becomes a transfer instead of a bounce. In that setup, the ticket moves to the team that owns it and the requester keeps the thread. That is one of the quieter arguments for putting facilities, HR and IT requests in one tool with a department each, which is how QuerySolv is arranged. The request that uses the route most, in my experience, is the broken desk lamp.

Log the not-us as a ticket even though the desk did nothing. Six broken lamps in a month is a fact facilities will want, and a request the desk routed elsewhere is still a request the desk received. A no that is not written down is a no that never happened, which is excellent for the technician's statistics and useless to everyone else.

Not Now: The Right Request at the Wrong Time

A not-now is a yes with a delay in it, and it only works if the delay is honest. The desk will set up the new starter's laptop, but not before the laptop arrives on Wednesday. The desk will move the shared folder, but in Friday evening's change window, not during month-end. The desk will look at the slow spreadsheet, but after the two outages ahead of it in the queue. Each of these is a reasonable decision. Each goes wrong the moment it is delivered without a date.

The failure word is "soon". "We'll get to it soon" is a not-now with the time removed, which makes it indistinguishable from a not-ever that is too polite to say so. Requesters know it. They have been told soon before. What they need is either a date or a trigger. Examples are "Wednesday afternoon, once the laptop arrives", "Friday after six, in the change window", or "after the two outages ahead of you, and I will update you by three today either way". A not-now with a date is a promise, and the rules for promising a time you can keep are in Honest ETAs. A not-now without a date is a hope with a ticket number.

The other failure is the not-now that is really a not-ever in disguise, said because not-ever felt too harsh. "We're not doing that right now" about a request the desk has no intention of ever doing is a kindness that costs the requester weeks. They will wait, ask again, and be told "still not right now". Eventually they work out that they were told no in the first conversation and nobody had the nerve to say it. A real not-ever, delivered on day one with a reason, is kinder than three months of soon. It is also considerably shorter.

Not Ever: The Policy No

A not-ever is a rule being applied, and the technician's job is to apply it clearly rather than defend it personally. Admin rights are not given to user accounts. Personal devices do not join the staff network. Software not on the approved list is not installed on company machines. The rule was decided by someone with the authority to weigh the risk, written down and published. The technician is delivering a decision that was made before the requester arrived.

Said badly, a not-ever sounds like the technician's opinion. "I can't do that" invites "why not?" And "why not" invites a debate the technician will lose. That is because the requester cares more about their problem than the technician cares about the rule. It is also because an argument about policy with the person in front of you becomes an argument about them. Said well, a not-ever points at the written rule, gives the real reason in one sentence, and offers whatever route exists. "Admin rights aren't given to user accounts; that's the policy on the IT page, and the reason is that one bad install on an admin account can take the whole network with it. What I can do is install the price tool for you from our side, today, once purchasing confirms it's approved."

Every not-ever should name the route to an exception, if one exists, because almost every rule has one. The route is usually a person with the authority the technician lacks. The right move is to send the decision upward rather than refuse alone, which is the subject of Saying No Upward. A rule with no exception route is a wall, and people climb walls. A rule with a door in it, even a heavy one, is a rule people use. The exception route is also how the desk finds out a rule is wrong. If the same exception is granted twelve times, the rule needs rewriting. In that case, the twelve tickets are the evidence.

Be honest about which kind you are delivering. A not-ever softened into a not-now is a lie with good manners. A not-us hardened into a not-ever ("we don't do lamps") is a door closed on someone who was one e-mail from help. The kinds are not degrees of politeness. They are different facts, and the requester is entitled to the right one.

Telling Them Apart in the Moment

The sorting takes three questions, asked in order, before anything is said aloud. Does another team, supplier or process own this? If yes, it is a not-us, and the job is to route it. Would the desk do this with enough time, approval or parts? If yes, it is a not-now, and the job is to give a date. Would the desk still decline this with all the time in the world? Then it is a not-ever, and the job is to point at the rule and the route. Three questions, under a minute, and the answer tells you which sentences to use.

The table below is the same sort as a reference. It shows the mistake each kind invites and what the requester should be holding when they walk away. The last column is the test. If the requester leaves a not-us without a destination, a not-now without a date, or a not-ever without a reason, the no was not finished, however politely it was said.

Most requests are none of the three, and that bears saying. The overwhelming majority of what reaches a desk is a plain yes: reset the password, fix the printer, order the cable. The sort is only for the minority where something in you hesitates. The hesitation is the signal to stop and ask the three questions, not to find the quickest way to make the feeling go away. The quickest way is usually yes. Jonah knows.

When the sort does not give a clean answer, say so and buy time honestly. "I want to check who owns this before I send you somewhere wrong; I will come back to you by eleven" is a complete sentence. It is better than either a guess or a yes. A no you are not sure of is a question, and a question can wait an hour. A yes you are not sure of cannot be taken back by Friday.

A Short War Story: The Server That Stayed On at Redbrook Engineering

At Redbrook Engineering, the design team lead asked a technician called Dev to keep a retired file server switched on "until the end of the month". That would let two old project folders be copied across at a quiet moment. Dev, who had a change ticket to decommission it, said yes. That was because the end of the month was three weeks away and the lead was a reasonable person. The end of the month came and went. The request was repeated twice more in the same words. Dev agreed twice more, each time meaning not-now and each time delivering it as a yes with no date and no ticket. Fourteen months later the server's single remaining disk failed on a Saturday. The server had been dropped from the backup schedule on the day it was retired. The two old folders had by then become the design team's working storage for three live projects. Redbrook lost nine days of drawings, paid a recovery firm that got half of them back, and had three engineers redraw the rest over two weeks while a client waited. The review found no decision anywhere. It was not in the change record, which said decommissioned, or in a ticket, because there was none. It was not in anyone's memory beyond "Dev said it was fine". A not-now that is never followed by a now is a yes, and the desk owns everything it says yes to.

The Three-Kinds Card

The card below is the sort as a single page, meant to sit beside the screen for the first few months until the three questions ask themselves. The "Say" lines are starting points rather than scripts; use the requester's own words for what they asked and your own for the rest. The last block applies to all three kinds. Its final two lines cover logging the request even when the answer was no and using the same words a colleague would. Those are the ones most often skipped. They are also the ones the desk will most want to have done when somebody senior asks how often this comes up.

THE THREE KINDS OF NO — DESK CARD
Before answering, ask the three questions in order. Stop at the first yes.

1. NOT US        Does another team, supplier or process own this?
   Say:   "This is owned by ______________. I have passed it to them with
           your details, and you can reach them at ______________."
   Do:    Transfer the ticket or forward the request. Name the owner.
          Log it as a ticket here even though we did nothing.
   Never: "Not our problem."  A direction with no name or address.

2. NOT NOW       Would we do this with enough time, approval or parts?
   Say:   "Yes, and not today. I can ______________ by ______________,
           because ______________. I will update you by ______________."
   Do:    Give a date or a trigger. Write it in the ticket. Keep it.
          Put the ticket in a waiting status with a follow-up date.
   Never: "Soon."  A not-now with no date is indistinguishable from never.

3. NOT EVER      Would we still decline with all the time in the world?
   Say:   "We do not ______________, because ______________. That is the
           policy at ______________. What I can do instead is ______________.
           If you need an exception, the person who can approve one is
           ______________."
   Do:    Point at the written rule, not at yourself. Offer the route.
          Note the request so repeated exception requests can be counted.
   Never: Soften it into a not-now.  Defend the rule as your own opinion.

FOR ALL THREE
   [ ] Acknowledge what was asked, in the requester's own words
   [ ] One true reason, one sentence
   [ ] One alternative, one route onward, or one date
   [ ] Ticket logged, even when the desk did nothing
   [ ] Said in the same words a colleague would use for the same request

COMMON OWNERS (fill in once)
   Facilities: ______________   HR: ______________   Finance: ______________
   Software approvals: ______________   Policy page: ______________

Print it, fill in the common owners and the policy page address once, and then stop reading it. That is because by the second month the three questions are automatic. Jonah's copy at Tollgate had "software approvals: Marta in finance" written across the bottom in pen within a week. Carla's request, run through the card, was a not-ever with a route: the desk installs approved software from its own side, and Marta approves it. It would have taken a day instead of two minutes, and purchasing would still have its price tool. It would also still have a desk that could patch it.

Frequently Asked Questions