A No the Whole Team Can Stand Behind: The Common-Nos List

Tuesday, 11:30, at Acme, a packaging manufacturer with a four-person desk. Dana has just declined ticket 8206, from Ben in sales. He wants his work e-mail forwarded to his personal address so he can read it on his own phone. The policy says no, and Dana said so, with the reason and an alternative. Ben's reply arrives in four minutes: "Leo set this up for Priya last week. Why is it different for me?" Dana checks. Leo did. Priya in sales has had her mail forwarding to a personal address for eight days, and there is a ticket, closed, that says "forwarding set up as requested". Dana now has three problems. One is Ben, who is right that it is unfair. Another is Leo, who will be hurt if she undoes it. Then there is the policy, which as of last week applies to people who happened to get Dana.

A no the whole team can stand behind is one that is the same whichever technician answers. It is said in the same words, pointing at the same page, with the same alternative. The lead backs it when it is challenged. Consistency is the whole of it. A desk where the answer depends on who picked up the phone does not have a policy. It has a timetable, and the requesters will learn it faster than the technicians will. This article is part of our Saying No Professionally series, and it is the one for the lead, about the desk rather than the conversation.

It starts with why the same answer matters and how a desk ends up with four policies. Next is the common-nos list, which is the fix, and writing it from the tickets rather than from the rulebook. Then comes backing the technician who said it, and what backing is not. After that comes what to do when a no keeps being overturned, and keeping the list alive. It ends with a short war story and the common-nos list to copy.

Why the Same Answer Matters

A no that differs by technician fails three people at once. It fails the requester who got the no, because they can see that the answer was not a rule but a person, and a person can be got round. It fails the technician who said it, because they are now explaining why they were stricter than their colleague, which is a conversation nobody wins. And it fails the technician who said yes, because they are about to be told, in front of a requester, that they were wrong. Ben is not being difficult. He has noticed that the desk gives two answers, and he would like the better one.

Consistency is also what makes a no cheap. A rule every technician applies the same way is said once per request, in a sentence, with a page to point at. A rule applied differently is argued every time, because every requester knows someone who got the other answer, and the argument lands on whichever technician is holding the ticket. The time a desk spends defending inconsistent nos dwarfs the time it would take to agree them. The argument is also unwinnable, because the requester is right. The desk did say yes last week.

Consistency does not mean rigidity. The same desk can grant exceptions, and should, through the route described in Saying No Upward. The point is that an exception is granted by the rule's owner, on the record, with conditions. It is not granted by whichever technician felt generous on Thursday. A consistent desk says the same no and offers the same door. What goes through the door is decided somewhere else.

How a Desk Ends Up With Four Policies

No desk decides to have four policies. It ends up with four because the rule was never written in words a technician could say aloud, so each technician wrote their own. The policy document says "e-mail forwarding to external addresses is not permitted except where approved". Leo read "except where approved", decided Priya's manager had approved it by asking, and set it up. Dana read "not permitted", and declined. Both were reading the same sentence. The sentence was the problem.

The second cause is that nobody told the team what the common nos are, so each technician learned them by being caught. Dana knows the forwarding rule because a lead once corrected her on it. Leo was never corrected, so he does not know it is a rule at all; he knows it as a thing the document says something about. New technicians inherit whatever the person who trained them happened to have been corrected on. That is how a desk of four can hold three different understandings of one rule and one person who has never heard of it.

The third cause is the quiet override. A technician said no, the requester complained to the lead, and the lead, busy and wanting the complaint gone, said "just do it this once". Nothing was written down. The technician learned that the no was negotiable, and the requester learned that the lead was the route. Every technician who heard about it learned that saying no was a way to be overruled in public. From then on the desk's nos got softer, not because anyone decided they should but because nobody wanted to be the next one overruled. (Nobody announced this. Nobody needed to.)

The Common-Nos List

The common-nos list is one page, kept where the technicians work, listing the dozen or so requests the desk declines most often. It gives the exact sentence to say for each, the one-line reason, and the alternative or the route. It also gives the page it points at and who can grant an exception. It is not the policy; the policy is the long document the list points at. It is not a template library either, which is the subject of the Templates & Canned Responses series. The list holds one sentence per no, and the full saved replies live wherever the desk keeps those. The list is the thing a technician reads in the ten seconds between recognising the request and starting to type.

Each line has the same five parts, which are the five parts of a good no from The Anatomy of a Good No, pre-filled for that request. The sentence for the no itself is written out word for word, because the words are the point. "We don't forward work mail outside the organisation" is what every technician says, not a paraphrase of it. The reason is the one sentence the desk has agreed is true and sufficient. The alternative is the one that actually exists. The page is the specific line on the policy or scope page. The exception route is a named role. A line missing any of the five is a line that will be said five different ways.

Keep it short. Twelve to fifteen entries covers the common nos on most small desks, and a list of forty is a policy document wearing a disguise, which nobody will read in ten seconds. If a request is declined less than once a month, it does not need a line. The technician can then run the three-kinds sort from the first article in this series and write the reply from the skeleton. The list is for the requests that arrive weekly, where the cost of five different answers is highest and the cost of agreeing one is a sentence each.

Keep it where the technicians already look, and keep it from the requesters. The list contains the desk's reasoning and its exception routes, which are for the technician, not for the person asking; the requester gets the sentence, the reason and the page. A knowledge base with articles visible only to agents is the natural home. If you run QuerySolv that is one of the two kinds of article the knowledge base holds. The other kind consists of the public pages the sentences point at. A pinned document in the team's shared folder does the job where there is no knowledge base, as long as it is the one folder everybody opens.

Writing It From the Tickets

Write the list from what the desk actually declined, not from what the policy document covers. Pull the last three months of tickets that were closed with a no, however the desk marks them, and sort them by what was asked. The top dozen piles are the list. This is the only reliable way to find the common nos, because the policy document lists every rule and the desk declines a handful of things over and over. Examples include forwarding to personal addresses, admin rights, personal devices on the staff network, and store-bought equipment. Add software without approval, access to someone else's files, and a second monitor outside the role allocation. That is seven already, and most desks will recognise most of them.

For each pile, read how the no was actually worded across the tickets, and notice how many ways it was said. That spread is the problem the list solves, and seeing it is usually what persuades a sceptical team that the list is worth an hour. Then write the agreed line together, in a meeting of the whole desk. A sentence the technicians wrote is a sentence they will say, and a sentence handed down is one they will paraphrase. The meeting takes an hour for a dozen lines, and most of the hour goes on the reasons, which is the part worth arguing about.

The pile may reveal that the desk has been saying yes and no to the same request, as Acme's forwarding pile did. The meeting is then also where the desk decides which it is. Or the desk discovers that nobody on the desk can decide, and the question goes to the rule's owner. Either way the line gets written, and from the day it is written there is one answer. The requesters who got the other answer before that day are not re-litigated. The lead writes to them, says the rule is now applied consistently from a date, and offers the alternative. Priya's forwarding was switched off with a week's notice and delegated web mail set up instead, and Ben got the same, on the same day, from Dana.

Backing the Technician Who Said It

The list only works if the lead backs it, and backing has a precise meaning. A technician who says a no in the list's words, points at the page, and offers the alternative is supported, in front of the requester, every time. That applies even when the lead would privately have granted an exception. The lead's reply to the complaint is "Dana gave you the desk's answer, and it's the right one; if you'd like an exception, the route is the one she gave you." Not "let me look into it". Not "I'll have a word with her". The requester hears that the desk has one answer, and the technician hears that saying it was safe.

Backing is not agreeing that the line was right. Sometimes it was not; the line was badly worded, or the situation was one the list never considered, or the rule has quietly changed. The lead fixes that on the list, in the next review or that afternoon, and tells the team, and the next technician says the corrected sentence. What the lead does not do is correct the line in front of the requester, because the requester does not learn that the line was wrong. They learn that complaints work. The list is amended in private and applied in public, and the order matters more than it looks.

Backing also means the lead takes the exception conversation, not the technician. When a requester wants to argue the rule rather than their case, the technician's line is "the person who can decide that is the lead, and I've passed it over". The lead picks it up the same day. A technician left to argue the rule alone will eventually stop saying it, and the desk will not notice until the next ticket audit finds a year of soft yeses. The lead's job is to be the wall the technician can stand in front of. It is not a glamorous job, and it is most of the job.

When a No Keeps Being Overturned

A no that is overturned once is an exception. A no that is overturned three times in a quarter is a rule that is wrong, or a rule whose owner does not believe in it. Or the route to exception has become the standard route. The list should say so. The lead counts overturned nos, by line, every quarter, and the count is the review. It is not a count of technicians who said no badly; a technician who said the line and was overruled did nothing wrong. It is a count of lines that keep losing, and a line that keeps losing is telling the desk something about the rule.

The table below gives the signals and what each one usually means. The thresholds are a starting point rather than a rule; a desk of three with thirty tickets a week will have smaller numbers than a desk of ten. What matters is that the lead looks at the count against the list, every quarter, with the rule owners in the room. The outcome must be a change to the list or to the rule, written down. It must not be a quiet understanding that line four is optional.

When the review decides a rule should change, change the rule first and the list second. Tell the requesters who were declined under the old line if the change would have helped them. A desk that overturns its own no publicly, with a reason, earns more trust than one that was never wrong. The requesters can see the rule is a decision and not a reflex. The requesters are not the enemy of consistency. Surprise is.

Keeping the List Alive

The list is reviewed quarterly, in the same hour as the overturned count, with three questions per line. Has anyone said it? Has it been overturned? Is the alternative still real? Lines are added from two sources, the out-of-scope count described in Declining Out-of-Scope Requests and the exception count from the upward decisions. Those two piles are where new common nos first appear. Lines are removed when the request stops arriving, which happens when the alternative becomes the standard way or the rule changes. A list that has not changed in a year is a list that stopped being read against the tickets.

New technicians read the list in their first week and say three lines aloud to the lead, which sounds faintly ridiculous and is the most effective training on the desk. A line read is a line understood; a line said is a line the technician can say to a requester without the hesitation that invites argument. The list is also where a new technician learns, in one page, what the desk has decided it is not. That is a thing most desks never say out loud and most new starters spend six months guessing at. The wider question of how five people write and speak as one desk, in nos and everything else, is in One Voice Across Five People. The common-nos list is that article's idea applied to the sentences the desk least wants to say.

A Short War Story: The USB Stick at Calder Valley Council

At Calder Valley Council, the IT desk had no common-nos list. The rule about copying resident data to removable drives lived in a nine-page policy that said "not permitted except where encrypted and authorised". A technician called Bea declined a councillor's request to copy a housing case file onto an ordinary USB stick for a meeting, in words of her own. The councillor replied that a colleague on the desk had done exactly that for the planning team the previous week. The councillor complained to the desk lead. With the meeting an hour away and no agreed line to stand on, the lead apologised to the councillor in front of Bea and overturned her. The lead had the file copied to the stick, unencrypted, with nothing written in the ticket beyond "done". The stick was lost on a train that evening with the case details of forty-one households on it. The council reported the breach, and the local paper carried it. The review spent a fortnight establishing that the policy had been applied three different ways by four technicians in a single month. That happened because nobody had ever written down what the desk said. Bea left within six months, and said why. A lead who overturns a technician in front of a requester has not changed one decision. They have told every technician that the rule is optional and every requester that the route to a yes is a louder complaint.

The Common-Nos List

The template below is the list as a one-page form, with three blank entries to copy for each common no and three worked entries to show the shape. Replace the worked entries with your own, because the wording must be the desk's and the alternatives must be ones your desk actually has. The lead's block at the bottom is the part that makes the list a policy rather than a suggestion, and its second line is the one to read twice. Fill it in a meeting of the whole desk, from the tickets, in an hour, and review it quarterly against the overturned count.

THE COMMON-NOS LIST — ONE PAGE, FOR THE DESK ONLY
Desk: ______________   Owner: ______________   Reviewed: ________   Next review: ________
Use: find the line, say it in these words, give the reason, point at the page,
     offer the alternative or the route, log the ticket.

1. REQUEST:   ____________________________________   KIND: [ ] not us [ ] not now [ ] not ever
   SAY:       "_____________________________________________________________________"
   BECAUSE:   "_____________________________________________________________________"
   INSTEAD:   ____________________________________   ROUTE / OWNER: ______________
   PAGE:      ______________   EXCEPTION BY: ______________   OVERTURNED THIS QUARTER: ____

2. REQUEST:   ____________________________________   KIND: [ ] not us [ ] not now [ ] not ever
   SAY:       "_____________________________________________________________________"
   BECAUSE:   "_____________________________________________________________________"
   INSTEAD:   ____________________________________   ROUTE / OWNER: ______________
   PAGE:      ______________   EXCEPTION BY: ______________   OVERTURNED THIS QUARTER: ____

3. REQUEST:   ____________________________________   KIND: [ ] not us [ ] not now [ ] not ever
   SAY:       "_____________________________________________________________________"
   BECAUSE:   "_____________________________________________________________________"
   INSTEAD:   ____________________________________   ROUTE / OWNER: ______________
   PAGE:      ______________   EXCEPTION BY: ______________   OVERTURNED THIS QUARTER: ____

WORKED ENTRIES (replace with your own)
A. REQUEST:   Admin rights on a user account                KIND: not ever
   SAY:       "We don't give admin rights to user accounts."
   BECAUSE:   "One bad install on an admin account can reach the whole network."
   INSTEAD:   The desk installs approved software from its side, same day.
   PAGE:      IT policy, 'Accounts'   EXCEPTION BY: security lead   OVERTURNED: ____

B. REQUEST:   Forwarding work e-mail to a personal address   KIND: not ever
   SAY:       "We don't forward work mail outside the organisation."
   BECAUSE:   "Once it leaves, we can't protect it, recall it or know who read it."
   INSTEAD:   Web mail from any device; delegated access for cover.
   PAGE:      IT policy, 'E-mail'   EXCEPTION BY: information governance   OVERTURNED: ____

C. REQUEST:   Support for equipment a team bought itself    KIND: not us
   SAY:       "That's outside what the desk covers; the list is on the IT page."
   BECAUSE:   "We have no access, documentation or spares for it."
   INSTEAD:   Confirm our network port works; route to the team that bought it.
   PAGE:      Scope page, 'Not supported'   OWNER: the buying team   OVERTURNED: ____

THE LEAD'S PART
   [ ] Every technician has read the list and said three lines aloud
   [ ] A no said in these words is backed in front of the requester, every time
   [ ] A wrong line is fixed on the list, in private, never in front of the requester
   [ ] Overturned nos counted by line each quarter; three or more means a review with the owner
   [ ] New lines added from the out-of-scope and exception counts; stale lines removed

Acme's desk wrote its list on the Wednesday after Ben's ticket, in fifty minutes, from eleven weeks of declined tickets. Those turned out to contain nine common requests and, for three of them, both answers. Forwarding became line two, in Dana's words, with Leo's agreement and a line for the exception route that nobody had known existed. Ravi, the lead, wrote to Ben and Priya the same afternoon with the same message. Ben's reply was one line: "Fair enough, as long as it's everyone." It was, from that Wednesday, and that was the whole of what he had wanted.

Frequently Asked Questions