Publishing What You Support

There is a document on the file server called IT Support Scope. It is four pages long, well written, approved by two managers, and it has a table. It lives in a folder called Policies, between the travel policy and the one about the fridge. Since the day it was approved it has been opened eleven times, nine of them by the people who wrote it. Meanwhile, in the queue, the fourth ticket this week begins "Not sure if this is you, but".

A scope document nobody reads has the same effect as no scope document, plus the cost of having written it. This article is part of our series on defining what IT supports. The service catalog article gives you the list (what IT provides, to whom, and how to ask for it). The article on scope boundaries gives you the lines around it. This article is about putting both where people will see them, in words that do not make anyone feel scolded for asking.

It covers where the page lives so that it is found at the moment it is needed. Then come the tone that makes people read to the end and the five blocks every scope page needs. We cover keeping it true when services change, then the one sentence a technician says at a walk-up. Next come how to announce a change without a four-page e-mail and how to tell whether anyone reads it. A template to copy appears near the end.

Where It Lives

A scope page lives where people are at the moment they have a problem, and that is not a folder called Policies. People look for "does IT do this?" in three places. One is the portal, where they are about to open a ticket. Another is the knowledge base search box, where they typed the name of the thing. The third is the reply from the desk, where a link in the signature is the closest thing to hand. Put the page in all three. One page, three doors.

The portal's first page is the main door. The link sits above the "new request" button, not below it. It is titled for the reader's question rather than for the document. "What IT supports, and who to ask for the rest" beats "Support Scope Policy" every time. A requester who sees that line before the form answers their own question often enough that the queue notices. The page must open without a login, because the people most likely to need it are the ones who do not yet have one.

The knowledge base is the second door. Publish the same page as an article, so that a search for "printer", "lobby television" or "home Wi-Fi" lands on it. The third door is one line in every e-mail signature from the desk: "Not sure whether IT handles it? See what we support", with the link. That line does more work than the portal link, because it arrives in the reply to the ticket the person already opened. That is exactly when they wonder whether they should have.

What goes wrong when the page lives in a folder is not that people ignore it. It is that they never meet it. A document in a folder called Policies is in witness protection. The requests keep arriving as questions, and the desk keeps answering them one at a time. And the scope lives in the technicians' heads, which is where it was before anyone wrote it down.

The Tone: Plain, Kind, Specific

The page is read by someone who already suspects they are about to be told no. So the tone decides whether they read past the first line. Three rules. Plain: short sentences, no "in scope" or "per policy", nothing a new starter would have to look up. Kind: assume the reader did not know, because they did not, and write "we" sentences rather than "you" sentences. Specific: name the thing. "The lobby television" is a line people recognize; "non-standard display hardware" is a line people skip.

Some words make a reader feel scolded, and they are the words scope documents reach for first. "Must", "not permitted", "unauthorized", "failure to", "as previously communicated" and "per policy" all say the same thing to the person reading them: you should have known. Their replacements say the same facts without the verdict.

The right-hand column is longer, and that is fine. The page is not a legal document. It is a conversation the desk is having with everyone at once, and conversations take a few more words than verdicts. The reader who finishes the page knows what to do next, which is the only measure that matters.

The Structure of the Page

A scope page has five blocks, in this order, and the order is the point. What we support comes first, so the page is not a wall of no. How to ask comes second, because the reader is probably about to. What to expect comes third. What we do not support, and who does, comes fourth; it is the block most pages lead with, and they should not. Exceptions come last, in two lines, so that the page ends with a door rather than a wall.

What we support is the catalog in short form: ten to fifteen lines, one per service. Each says what the thing is and who it is for. Accounts and access. Your work computer and phone. E-mail and calendar. The office network. Printing. File storage. The business applications we run, named. Remote access. Meeting-room equipment, if it is yours. This block links to the full catalog entries for anyone who wants the detail, and most people will not.

How to ask names the portal, the e-mail address and the phone number for something urgent, in that order. It includes a line about which to use when. The channel strategy pillar covers the reasoning; the scope page just needs the three lines. What to expect is two sentences: how soon you will hear from a person, and how you will be kept informed. If you have service levels, the response times the desk has promised, state the acknowledgment time here and link to the detail. The SLA design pillar covers how to pick a number you can keep.

What we do not support, and who does is a two-column table: the thing, and the person or team to ask. The lobby television: facilities, with their address. Your home internet: your provider. The sales team's own tool: the named owner in sales, with the vendor's support behind them. Every line in this block carries a pointer. A "no" with nowhere to go becomes a ticket; a "no, ask them" becomes a resolved question. The shadow IT article covers the supported, tolerated and forbidden list that feeds this block.

Exceptions is the shortest block: who can grant one, how to ask, and the fact that it will be written down. Then two lines of housekeeping at the top: "Last reviewed" with a date and a name, and "Not sure? Ask anyway." The second line is the most important sentence on the page, and it goes on every version.

A Worked Example: Dana Writes the Page

Dana runs the two-person desk at Meridian Parts and has a catalog of twelve services on a wiki page that nobody outside IT has visited. On a Tuesday she blocks the morning. From 09:30 to 10:15 she writes the "what we support" block by copying the twelve catalog lines and cutting each to one sentence. From 10:15 to 10:40 she writes "how to ask" and "what to expect", using the acknowledgment time the desk already keeps. That is one business hour. From 10:40 to 11:30 she writes the "who does" table: nine lines. They include the lobby television (facilities, Marcus), the warehouse scanners (the operations lead, Tomas), and home internet (your provider). At 14:00 she sends the draft to Marcus in facilities to check his three lines, and he adds a fourth, the badge readers. At 16:10 the page is published as a knowledge base article and linked above the portal's new-request button. It is four hundred and twenty words long. The old document in the Policies folder is left where it is, with a line at the top pointing to the new page.

Thirty days later Dana counts. The article has been viewed ninety-four times by people other than her. The tickets that begin with "not sure if this is you" have gone from about nine a week to four. The four remaining are mostly new starters, which gives her the next idea: the link goes in the welcome e-mail.

Keeping It Current

A scope page that says IT supports the old phone system, two years after the old phone system left, is worse than no page. It teaches people that the page lies. Keeping it true costs ten minutes a quarter if you attach it to something that already happens: the catalog review. Whoever reviews the catalog updates the page the same day and changes the "last reviewed" line. They add one line to a change note at the top: "Changed this quarter: badge readers now go to facilities."

Give the page one owner by name, not "IT". A page owned by a department is owned by whoever remembers, and nobody remembers. The owner's job is small: read the page once a quarter as if they were a new starter, and fix whatever is no longer true. A page that has not changed in a year is either describing a very stable organization or has not been read. It is usually the second.

The "last reviewed" line does more than it looks. A reader who sees a recent date trusts the page. A reader who sees nothing assumes the page is old, because scope documents usually are. The change note does the same job for returning readers: they can see in one line whether anything that matters to them has moved.

The Walk-Up Version

The page has a spoken version, and every technician should be able to say it without looking. It is one sentence in three parts: the answer, the owner, and the pointer. "That one's facilities; Marcus looks after the screens, and I'll send you the link to the page with his address." Or, for something that is ours: "Yes, that's us. Let me open a ticket while you're here so it doesn't get lost." The sentence takes four seconds and leaves the person with somewhere to go.

The sentence exists because the walk-up is where scope is decided in practice. A technician with no sentence ready says yes to keep the peace, which creates a service. Or they say "that's not really us", which creates a grudge. Neither is the technician's fault. The desk failed to give them the words. Practice the sentence with the newest technician in their first week, using the three most common out-of-scope requests. Then they will never have to improvise a no.

I keep the spoken version shorter than the written one, and I have learned to say the pointer last. People stop listening after the answer, and the pointer is the part they need. "Facilities, Marcus, here's the link" lands. A paragraph about why does not.

Announcing a Change

When the page changes, announce the one thing that changed, in three lines, and nothing else. What changed, from when, where to read more. "From Monday, the meeting-room screens are looked after by facilities. Their address is on the IT support page. Everything else is the same." Send it on whatever channel the desk already uses for announcements, and put the same three lines in the change note on the page.

Do not re-announce the whole page. An e-mail to everyone with the four-page document attached is read by the people who wrote it, as before. It trains everyone else that messages from IT are long. One change per announcement means the announcement is short, and a short announcement is read. If three things changed, that is three short messages across three weeks, or one message with three lines, and either beats a document.

The exception is the first publication, which gets a slightly longer note. It says: here is the page, here is where it lives, here is the one line to remember ("not sure? ask anyway"). Even that fits on a phone screen without scrolling, and it should.

Measuring Whether It Is Read

Four signals tell you whether the page is doing its job, and three of them are free. The first is view counts on the knowledge base article, read once a month. A page nobody views is not where people are looking, so move the link. The second is the "does IT do that?" tickets, counted per week before and after publication. Tag them as they arrive, and watch the count. The third is the search terms that land on the page, where your knowledge base shows them, because they tell you what people call things. The fourth is the walk-up test: ask five people outside IT where the page is. If three can find it, it lives in the right place.

The count that matters most is the second. View counts say the page is found; the ticket count says it is understood. A page with high views and the same number of "is this you" tickets is being found and not answering the question. That means the tone or the "who does" table needs work. A knowledge base that shows which published articles are read most makes the first check a glance. QuerySolv's does, with view counts on each article. And the habit is the same in any tool that keeps them.

Without any measurement, the page becomes the document in the Policies folder with a better address. Someone wrote it, someone approved it, and nobody knows whether it changed a single ticket. Ten minutes a month with two numbers is the difference.

A War Story: Bluewater Bank's First Link

Bluewater Bank's branch desk supported forty branches. About a fifth of its tickets each week were some form of "who do I ask about this?" They concerned screens, badge readers, the queue display, the phones at the counter. Priya put the scope page as the first link on the portal, above the request form. Its "who does" table named facilities for the screens and badges and the phone vendor for the counters. Within two months the "who do I ask" tickets had fallen by about half. The ones that remained were mostly things the table had not yet listed, which went on the table. Facilities noticed that branch managers were now writing to them directly and asked for their own inbox on the same page. So by the end of the quarter the page carried two tables, one for IT and one for facilities. A branch manager had one place to look. Nobody was told anything twice, and "check the support page" had become a sentence people said to each other.

The Scope Page Template

Copy the template below into your knowledge base, replace every bracketed item, and delete anything your desk does not do. Keep it under five hundred words. If it is longer, the catalog detail has leaked in; link to it instead.

WHAT IT SUPPORTS, AND WHO TO ASK FOR THE REST
Last reviewed: [date] by [name].   Changed this quarter: [one line, or "nothing"].
Not sure whether something is ours? Ask anyway. We'll point you to the right place.

WHAT WE SUPPORT
- Accounts and access: sign-in, passwords, permissions, new starters and leavers.
- Your work computer and work phone: setup, repair, replacement, updates.
- E-mail and calendar.
- The office network and Wi-Fi.
- Printing and scanning on office printers.
- File storage and sharing on [the shared drive / the document system].
- Business applications we run: [name], [name], [name].
- Remote access from home or on the road.
- [Meeting-room equipment, if yours.]
Full details for each: [link to the catalog].

HOW TO ASK
- Portal: [link]. You get a ticket number straight away. Best for everything.
- E-mail: [address]. Also makes a ticket.
- Phone: [number], for something that is stopping work right now.

WHAT TO EXPECT
A person replies within [one business hour / your figure]. We tell you the next
update time in every reply. If it will take longer than a day, we say so.

WHAT WE DON'T SUPPORT, AND WHO DOES
Thing                               Ask
----------------------------------  -----------------------------------
The lobby television and signage    Facilities: [address]
Badge readers and door locks        Facilities: [address]
Your home internet or home Wi-Fi    Your internet provider
Your own phone or laptop            We set up work e-mail on it; the maker's
                                    support handles the device itself.
[Department tool not run by IT]     [Owner name], [department]; vendor support
Desk phones at [location]           [Vendor or team]: [address]
A tool your team bought itself      Tell us here: [form link]. Nothing is
                                    switched off for being on the list.

EXCEPTIONS
Need something that isn't listed? Your manager and the IT manager can agree an
exception. Ask through the portal; we write every exception down with a date.

The template ends with the exception door on purpose. A scope page that ends with a "no" is remembered as a "no". One that ends with "ask anyway" is remembered as a page you can go back to. That is what you want from a page that will be found at the worst moment of someone's day. It sits above the request button, doing its one job: telling them, kindly, whose problem this is.

Frequently Asked Questions