Declining Out-of-Scope Requests: Point at the Page, Not Yourself

Monday, 10:05, at Northgate Retail. Hannah, who manages the Harbor Street store, has e-mailed the desk: "The music system has gone silent and customers keep asking if we're closing. Can IT come out today?" Marcus reads it twice. The music system is a consumer streaming box the store bought from a high-street shop two years ago. It was plugged into the store's network by whoever was there that afternoon. IT has never seen it, never approved it, and it is not on the list of what the desk supports. Marcus has three choices. He can drive forty minutes and poke at a box he does not understand. He can reply "not supported" and close the ticket. Or he can do the thing this article is about, which takes about four minutes longer than the second option and saves the rest of the year.

An out-of-scope request is a request for something the desk has said, in writing, that it does not do, or for something nobody has ever said it does. The list itself, what the desk supports, what it does not and why, is scope. Deciding it is the subject of our Defining What IT Supports series. This article is part of our Saying No Professionally series. It is about the conversation that happens when a request from outside the list arrives at a desk that has one.

It covers why the page says no and not the person. It covers pointing at the published scope; routing the request to whoever does own it; and logging it anyway, so the pattern gets counted. It covers the gray-area call, when the request is half in and half out; and the quiet yes and why it costs more than a no. It ends with a short war story and the out-of-scope reply to copy, in that order.

Why the Page Says No, Not the Person

The single most useful fact about an out-of-scope no is that somebody else already made the decision. The scope was written by the desk lead, agreed with management, and published. The technician reading Hannah's e-mail is not deciding whether IT supports consumer music boxes. That was decided when the list was written. The technician is reporting a decision, the way a receptionist reports that the clinic closes at six. Nobody argues with the receptionist about the opening hours, because the receptionist plainly did not choose them.

This changes the sentence. "I can't help with that" is a statement about the technician. It invites "why not?", "can't you just?", and "who can, then?" Each puts the technician on trial for a rule they did not write. "That's outside what the desk covers; the list is at the address below" is a statement about a document. The argument, if there is one, is with the document. The document does not mind. The technician, who has nine other tickets, does. Pointing at the page is not hiding behind it. It is standing beside it, which is where the technician actually is.

It also makes the no the same from every technician. If Marcus declines the music box and Dana, on Thursday, drives out and fixes it, Northgate now has two desks. In that case, the stores will learn which one to ask for. A scope that lives on a page is a scope every technician can read aloud in the same words. A scope that lives in each technician's judgement is a scope that depends on who picked up the phone. The team-wide version of this problem has its own article, A No the Whole Team Can Stand Behind. For the single conversation, the rule is enough: the page says no. You say where the page is.

Pointing at the Published Scope

Pointing only works if the page exists and the requester can reach it. "Published" means somewhere a store manager can open from her own screen without asking IT how. It does not mean a document in the desk's shared folder that the desk has agreed amongst itself. Most desks keep it in the knowledge base, on the portal, or on the intranet page where the request form lives. Where the knowledge base can hold articles visible to everyone rather than only to technicians, as QuerySolv's can, the scope page sits beside the how-to articles. In that setup, the reply can carry a link to it. What matters is that the link works for Hannah, on a Monday, in the store.

Point at the specific line, not the whole document. "The list of what we support is on the IT page" sends the requester to read three screens of text looking for the word "music". Most will not. "Store audio and music systems are listed under 'not supported, store-purchased equipment', about halfway down the page" takes them to the line in one click and one scroll. It shows that you looked, which matters more than it should. If the page is well organised, the line will also say who does own the thing. That is the next part of the reply.

Give the reason the page gives, in one sentence, even though the page says it too. People read a reason in a reply and skim a reason on a page. "It's outside our scope because the stores buy these themselves from retail, so IT has no access, no documentation and no spare, and anything we did would be guessing" is a sentence Hannah can repeat to her regional manager. "Please see the scope policy" is not. The one-sentence reason is the third part of every good no. The article The Anatomy of a Good No covers why it has to be true and why it has to be short.

When the page does not have a line for the request, say so honestly rather than inventing one. "It's not on our list either way, which usually means nobody has asked before" is true. It leads naturally into the gray-area call later in this article. A technician who claims the page says something it does not will be found out by the first requester who reads it. The page's authority, which is the whole point of the page, goes with them.

Routing to the Right Place

An out-of-scope request is nearly always in somebody's scope, and the second half of the reply is finding out whose. The music box belongs to the store that bought it, and after that to the shop it came from. The broken desk lamp belongs to facilities. The supplier's stock-ordering software belongs to the supplier, under a support contract that lives in purchasing. The question the technician asks is not "is this ours?", which the page has answered, but "whose is it?" A desk that has been running for a year can answer that for most things from memory.

Routing has a weak form and a strong form, and the strong form is the one worth doing. The weak form is a direction: "you'll need to contact facilities". The strong form is a handover: "I've sent this to facilities with your store number and the fault description, and their request address is facilities@example.com if you need to chase it". The strong form costs the technician a forwarded e-mail or a transferred ticket. It saves the requester from explaining the problem twice, and it saves the desk from the second ticket a week later that begins "I contacted facilities like you said and nobody replied". Where facilities, HR and IT share one help desk with a department each, as QuerySolv is arranged, the handover is a transfer. In that case, the requester keeps their ticket and its history. That is the quietest possible version of a not-us. Where they do not, a forwarded message with the requester copied in does the same job.

Be careful with suppliers. Routing a requester to a vendor's support line is correct when the organisation has a contract with the vendor and someone knows the account details. It is a brush-off when the requester is being sent to a public help page to queue behind the world. Check which one you are doing. If the supplier relationship is managed by someone inside the organisation, route to that person, not to the supplier. That person has the contract number and the technician does not. The mechanics of passing work to vendors and to other internal teams without losing it are in the article on escalating to vendors and other internal teams.

Sometimes nobody owns it, and then the honest reply is to say so. "I don't know of anyone in the organisation who supports this, and I would rather tell you that than send you somewhere that won't help." Follow it with what you have done. You have logged the request so the gap is visible, and flagged it to whoever decides what the desk covers. A requester told plainly that there is no owner can go and make a case for one. A requester bounced between three teams that each say "not us" gives up, and the problem stays, usually until it becomes somebody's incident.

Logging the Request Anyway

Every out-of-scope request is logged as a ticket, even though the desk did nothing. The reason is that the count is the only evidence anyone will ever have that the scope is wrong. One request to fix a store's music box is an anecdote. Fourteen in a year, from nine stores, is a fact: the stores have a need, nobody owns it, and either the scope changes or someone is appointed to own it. Without the tickets there are fourteen anecdotes, each in a different technician's memory, and a scope review that says "we don't get asked about that much".

Logging is a minute's work if the desk has decided in advance how to mark these tickets, and an afternoon's archaeology if it has not. Agree one way of marking an out-of-scope request so they can be counted together. It could be a fixed phrase in the resolution note, a tag, a type, whatever the tool offers that a filter can find. Write the agreed marker on the scope page itself so nobody has to remember it. Then, once a month, pull the list and sort it by what was asked. The monthly review of declined requests is twenty minutes. It is where scope gaps, missing owners and candidates for a new service all surface. That makes it one of the better-spent twenty minutes on the desk's calendar. It is also, in my experience, the review most often cancelled, because nothing in it is on fire.

Logging also protects the technician. When a store manager's complaint reaches a regional director as "IT refused to help", the ticket tells the story. It shows what was asked, when, what the technician said, where the page was pointed, and who the request was routed to. A declined request that exists only in an e-mail reply from Marcus's own mailbox is Marcus's word. A declined request in the queue, with its history, is the desk's record. The difference is who gets phoned.

The Gray-Area Call

A gray-area request is one the scope page does not settle. It is not listed as supported, not listed as unsupported, and a reasonable person could argue either way. The store's music box is half gray, because it uses the store's network, which IT does support, to do something IT does not. The personal phone that receives work e-mail is gray. The spreadsheet macro the finance team wrote themselves and now cannot fix is gray. The gray area is where most bad nos and most bad yeses happen. That is because it is where the page goes quiet and the technician is alone with the request.

The first rule of the gray area is that the newest technician does not decide it alone. Not because they would decide badly, but because a gray-area decision sets a precedent, and precedents belong to the desk lead. The technician's job is to recognise the gray, hold the request for an hour, and ask. "I want to check whether this is something we cover before I send you anywhere; I'll come back to you by midday" is the right reply. It is better than either a guess in each direction. Most gray-area calls take the lead thirty seconds, because the lead has seen the shape before.

The second rule is that the call gets written down twice: once in the ticket, as the reason, and once on the scope page, as a new line. That way, the gray area shrinks by one every time it is visited. A gray area decided and not written down is a gray area that will be decided again next month, possibly the other way. The table below gives the common shapes and a sensible default for each, which is not the same as the right answer for your desk. The right answer is whatever your lead decides and writes on the page.

The one-time favour deserves a word, because it is the gray area's most tempting corner. Doing a small thing once, with a deadline, for a person who asked politely, is often the right call. The reply should say so plainly: "I've done this one because of the deadline, and I've logged it as outside our scope, so if it comes up again we'll need to find it a proper home." The sentence costs nothing and prevents the favour becoming a service. A favour that is not named as a favour is a precedent, and the next requester will cite it by name.

The Quiet Yes and Why It Costs More

The alternative to all of this is the quiet yes. Marcus drives to the store, finds the music box has lost its wireless password, types it in, and drives back. Forty minutes each way, five minutes of work, a grateful store manager, no ticket worth mentioning. It feels like service. It is, for the desk, the most expensive outcome available, and the costs arrive in the order that makes them hardest to see.

The first cost is ownership. The desk has now fixed the music box, so when it fails again the store will ask the desk. The desk will have no grounds to refuse that it did not already waive. The second is fairness: nine other stores have music boxes. The one that got a visit was the one whose manager e-mailed Marcus. That is a service model based on who knows a technician. The third is the hidden hour and a half, which appears nowhere, because the ticket, if one was raised, says "music system, resolved". The desk's capacity figures quietly lose a morning. The fourth is the page: a scope that says one thing while the desk does another is a scope nobody will believe, including the technicians. Unsupported equipment that the desk supports anyway is the subject of Unsupported Software and Shadow IT. The short version is that every quiet yes adds a line to the list of things the desk owns without having chosen to.

None of this makes Marcus wrong to want to help, and the proper reply helps more than the drive would have. Hannah needs music in the store today. The out-of-scope reply, done well, tells her within ten minutes that IT does not cover the box and why. It says that the store's own retailer does, and that the network port is confirmed working so the fault is in the box. It also says that if the stores want IT to take these on, the route is a request to the regional manager. In that case, the desk will log this one as the first piece of evidence. She can act on all of that by eleven. The drive would have had Marcus there at twelve.

A Short War Story: The Door-Entry System at Ashgrove Housing

At Ashgrove Housing, the door-entry intercom on a block of twenty-four flats began failing intermittently. Over eleven months tenants and housing officers raised it with the IT desk eleven times. That was because the intercom had a network cable and the IT desk was the only desk that reliably answered. Each time a technician replied, correctly, that intercoms were not IT equipment. Each time the ticket was closed without being logged as out of scope, without being routed, and without anyone noticing it was the same intercom. That was because four different technicians took the eleven tickets and none of them wrote "intercom" in the same place. The system belonged to a facilities contractor whose contract had lapsed. Nobody discovered that until a housing officer called Nadia pieced the eleven conversations together from a tenant's complaint. By then an elderly tenant had spent an evening in the cold waiting for a neighbour. The complaint had been upheld, and the emergency call-out fee was three times what the lapsed contract would have cost. The desk had said no correctly eleven times and achieved nothing. That is because a no that is not logged and not routed is a request that disappears. The problem it described does not.

The Out-of-Scope Reply

The template below is the reply as a fill-in-the-blanks message, with the internal note that goes underneath it. The top three lines are the check before writing. The second one asks whether the page actually lists the thing or whether this is a gray area. That decides which block to use. The reply itself follows the five parts of a good no, with the page doing the work of the no. The internal note is the part that gets the request counted at the monthly review. It is the part most often skipped when the queue is busy. That is also when the desk can least afford to lose the evidence.

THE OUT-OF-SCOPE REPLY — CHECK, WRITE, LOG
Ticket: ________   Requester: ______________   Asked for: ____________________

CHECK FIRST
   Scope page says:  [ ] listed as not supported   [ ] not listed (gray area: ask the lead)
   Owner:            [ ] known: ______________     [ ] nobody known
   Been asked before:  ____ times (search the marker below)

REPLY (when the page lists it)
   Thanks for raising ______________.
   This is outside what the IT desk covers. The list of what we support
   and don't is at ______________, under "______________".
   It's outside our scope because ______________.
   It's owned by ______________; I have passed your request to them with
   your details, and you can reach them at ______________.
   If you haven't heard from them by ______________, reply here and I'll chase.

REPLY (when nobody owns it)
   Thanks for raising ______________.
   This isn't something the IT desk covers, and I don't know of anyone in
   the organisation who does. I've logged it so the gap is visible and
   flagged it to ______________, who decides what the desk takes on.
   In the meantime, ______________ may help with the immediate problem.

REPLY (one-time favour, with a deadline)
   I've done this one because of the ______________ deadline. It's outside
   what the desk normally covers, so I've logged it as such; if it comes
   up again we'll need to find it a proper home.

INTERNAL NOTE (not sent to the requester)
   Marker for the monthly count: OUT-OF-SCOPE
   Kind:  [ ] listed   [ ] gray area, decided by ________ on ________
   Routed to: ______________   Scope page updated:  [ ] yes  [ ] not needed

Marcus sent the first block to Hannah at 10:14, with the network port confirmed working from his desk. The retailer's support line was in the "owned by" blank. Marcus wrote "OUT-OF-SCOPE" in the internal note. At the monthly review the marker found six more music boxes from four stores. The desk lead took the count to the retail operations manager, who had not known the stores were buying them. Retail operations bought a supported model for every store and put it on the scope page as theirs. The desk never fixed a music box. It did get them fixed, which is not the same thing and is considerably more useful.

Frequently Asked Questions