The Service Catalog Idea, Without the Platform

"Does IT do that?" Priya from sales asked it on Monday, about the badge printer at reception. Marcus from the warehouse asked it on Wednesday, about getting work e-mail onto his own phone. Lena from finance asked it on Friday, about the projector for the quarterly all-hands, which was in forty minutes. The desk said yes to the first, "sort of" to the second, and "ask Tomas" to the third. Three people asked the same question about one department and got three different answers. Each answer was given by someone who believed it.

Nobody was wrong, exactly. There was no list. When there is no list, every answer is an opinion, and every opinion becomes a precedent the moment someone repeats it in a corridor. This article is the first in our What IT Supports series. It is about the list: what a service catalog is in plain words, and why a page on the wiki counts as one. It covers the ten services most small organizations actually run, how to write an entry, and what does not belong on the list. It also covers how to write the first version in an afternoon and how to keep it true after that. There is a ten-service starter near the end to copy.

What it is not about is the platform. A service catalog is a document, and the software some vendors sell under that name is a place to keep it. You can buy the place later. You cannot skip the document.

What a Service Catalog Is

A service catalog is the written list of what IT provides, to whom, and how to ask for it. That is the whole definition. A service is something the organization relies on and IT keeps running: e-mail, the file shares, user accounts, the laptop on the desk. The catalog names each one and, for each, says who can have it, how to request it, what you get, and how long it takes.

Each entry answers five questions: what is it, who is it for, how do you ask, what do you get, and how long does it take. If the entry answers those five, the question "does IT do that?" has an answer that is the same on Monday, Wednesday and Friday. In that case, it is also the same whether Tomas is in the building or not. A catalog is less a document than a promise with a table of contents.

A catalog is not the desk's charter, and the two are often confused. The charter says why the desk exists and what it is for, and it belongs to the Helpdesk Fundamentals series. The catalog says what the desk does, in enough detail that a person can ask for one of the things on it. The charter is a paragraph. The catalog is a list.

One page is enough. A small organization runs ten to fifteen services. A reader who wants to know whether IT does something should find the answer in under a minute. The eighty-entry catalog exists, and I have seen one; it had a row for "advice". Nobody read past row twenty, which meant nobody reached the row that said what to do about the badge printer.

Why a Wiki Page Counts

The platform is optional; the list is not. A service catalog is a document. Any place that holds a document and lets people find it will do. That could be a page on the wiki, an article in the help desk's knowledge base, a shared document with a short link, or the first page of the request portal. What makes it a catalog is that it is written, findable and current, not that a product calls it one.

Service management frameworks gave the catalog its name and a great deal of machinery around it. ITIL, the published library of good practice for running IT services, describes a catalog with business views and technical views, and a catalog manager. It also describes a review process and links to a database of every component. All of that is sensible at a scale most of us never reach. How much of it a small team should borrow is the subject of the Pragmatic ITIL for Small Teams series. The borrowable idea is the list.

What the platform adds, when you eventually get one, is a request form behind each entry and a workflow behind each form. That is useful. It is also the second step, and taking it before the first produces a very expensive page with nothing on it. Write the list in whatever you have.

I wrote my first catalog in a text file on a file share. It was better than the service management platform that replaced it three years later, because people could find it. The platform had a search box. The search box had opinions.

The Ten Services Most Small Organizations Run

Most small organizations run the same ten services, whatever they call them. The names below are plain on purpose; your users will search for "printing", not "output management". Start with these, cross off the ones you do not run, and add the one or two that are specific to your business.

• Accounts and access: creating, changing and removing user accounts and the permissions attached to them; starters, movers and leavers.
• Devices: the laptops, desktops and company phones IT issues, repairs, replaces and takes back.
• E-mail and calendar: mailboxes, shared mailboxes, distribution lists, calendar sharing, and mail on company devices.
• The office network and Wi-Fi: the connection at every desk and in every room, the guest network, and the link to the internet.
• Printing: the shared printers and copiers, their drivers, and the print queue.
• File storage and sharing: the shared drives and team folders, who can see what, and restoring a file that was deleted on Thursday.
• Business applications: the systems the organization runs on (finance, payroll, the customer database, the warehouse system), with IT as the owner of some and the contact for the rest.
• Remote access: working from anywhere other than the office; the client, the account, and the rules.
• Meeting rooms: the screen, the camera and the cable on the table, to the extent IT owns them.
• Phones: the desk phones, the softphone, the main number, and voicemail.

Two of the ten deserve a second look before they go on the page, because they are where the arguments live. Meeting rooms and phones are shared with facilities and with whoever bought the conferencing service. The entry has to say which part is IT's. Business applications are shared with the departments that use them. The entry has to say whether IT runs the application or helps people reach it. Those two sentences settle more disputes than the other eight entries combined.

What is missing from the ten is also deliberate. There is no "advice", no "projects", and no "anything with a plug". Those are not services; they are things that happen.

Writing an Entry

An entry is a short answer to the five questions, in the same order every time. Keep the fields fixed so that the reader learns the shape once and skims after that. Here are the fields, with one entry written out for the accounts service at Meridian Parts.

The worked entry earns its keep the first time a request arrives through it. On a Tuesday at 09:10, Dana in HR at Meridian Parts submits the form for a new starter, Tomas, who begins the following Monday. She includes name, start date, manager, role "stores clerk", and access to match Marcus. Sam picks it up at the 09:30 triage and builds the account and the laptop on Thursday. Tomas signs in at 08:30 on Monday with everything working. The form took Dana four minutes. Without the entry, the same request arrives as an e-mail saying "new person starting Monday". Then the desk spends twenty minutes finding out the four things the form would have asked.

Write the "how long" field as a promise you can keep in a bad week, not a good one. The number in the catalog becomes the number people plan around. A promise of one day that takes three is worse than a promise of three that takes one. If the desk has formal response and resolution targets, the catalog's numbers should match them. The SLA Design series covers how to choose numbers that survive contact with a Monday.

The "not included" field is optional and valuable. It is where you write down the misunderstanding the entry has caused before, so that it does not cause it again. Most entries collect one within a month. Some collect them like a windshield collects insects.

What Is Not a Service

Projects, favors and the lobby television are not services, and the catalog should not pretend they are. A service is repeatable: many people ask for the same thing, and the desk delivers it the same way. A project is done once, has a start and an end, and needs a decision about priority and time. A favor is something a person did because they were nearby and kind, which is admirable and not a commitment.

Projects go on a different list. When a department wants a new system, a migration, or the warehouse Wi-Fi extended to the new mezzanine, that is work with a scope, a cost and a sequence. That work belongs on the project list with an owner and a date. The catalog can say "new systems and larger changes are requested as projects; here is how". That single line stops the project arriving as a ticket on Friday afternoon.

Favors are the hardest, because every favor looks like a service to the second person who hears about it. Someone fixed the lobby television once. Now the lobby television is in the catalog, in the sense that everyone believes it is, and nobody wrote it there. The catalog's job is to make the difference visible. If it is not on the list, it is not a thing we do. Whether it should be is a real question with a real answer. How a favor becomes a service, and how to stop it, is the subject of Scope Creep and the Expanding Catalog.

The lobby television deserves its own sentence because it is the purest example of the problem. It is not a computer. It has no account, no owner and no entry. It is also the first thing a visitor sees. When it shows "No signal" at ten to nine, the phrase "IT handles that" is said with great confidence and no evidence. Where the line goes for things like it, and how to hold the line without being unhelpful, is covered in Scope Boundaries and the Gray Areas. For the catalog, the rule is short. Write what you do. Say where the rest goes.

The First Version in an Afternoon

The first version takes an afternoon, and it should not take longer. Block three hours. Open the ticket history for the last ninety days and sort it by category, or by subject if there are no categories. The services are the things people actually asked for. The list is already there in the tickets, unlabeled. Write one line per service: its name and one sentence saying what it is. Then fill in the other fields for the five services with the most tickets, and leave the rest until next month.

Resist two temptations during the afternoon. The first is to write the catalog you wish you ran, with the automated onboarding you are planning to build. Write the one you run today, and add entries when they become true. The second is to settle every argument in version one. If nobody can agree whether meeting rooms are IT's, write "shared with facilities; split to be agreed" and move on. A catalog with one honest gap is worth more than a catalog that has been in review for six weeks.

Publish it where people already look, which is almost never a folder called Policies. The portal's first page, the knowledge base, or the wiki page everyone has bookmarked for the holiday calendar. Announce it in one short message: if you want to know whether IT does something, this page says. Where to put it and what tone to use is its own article, Publishing What You Support.

Then stop. Version one is done when it is published and findable, not when it is complete. Completeness arrives by itself, one awkward ticket at a time.

Keeping It True

A catalog goes stale in about a quarter, so read it every quarter. Services change: the phone system moves to the cloud, the warehouse system gets a new owner, remote access changes its client. Each change makes one line of the catalog a small lie. Small lies accumulate until someone follows the catalog, hits the lie, and decides the page is not worth reading. The quarterly read is twenty minutes with the page and last quarter's ticket categories side by side.

The read asks three questions of every entry. Is this still true? Is the "how long" still what we deliver? Has anything arrived in the tickets that is not on the page and should be? The last question is where new services are found and where favors are caught early, before they have a following. Put a "last reviewed" line at the top so that readers can judge whether to trust the page without asking you.

I do the read on the first Monday of each quarter, with the first coffee. I have never finished it without finding one entry that had quietly stopped being true. Usually it is the "how long" field. Occasionally it is the service itself, which retired without telling anyone.

A Short War Story: Eleven Lines at Acme

Acme's first catalog was eleven lines on a wiki page, written by Lena in one afternoon. It followed a week in which three people had asked whether IT supported their personal phones and had received three answers. Ten of the lines named services: accounts, laptops, e-mail, the network, printing, file shares, the finance system, remote access, the meeting rooms, phones. The eleventh said: "We do not support personal devices beyond setting up work e-mail." That one line ended an argument that had run, in corridors and in tickets, for the better part of two years. That was because for the first time the answer was written where anyone could point at it. Nobody had been wrong before; there had been nothing to be right about. The page has been rewritten twice since, and the eleventh line has never changed.

The Ten-Service Catalog Starter

Copy this table, cross off what you do not run, and fill the blanks from your own tickets. The "how long" column holds deliberately ordinary numbers. Replace them with the ones you can keep. The "how to ask" column assumes one route into the desk. If you have several, name the one you want people to use.

A tool can make the "how to ask" column do more than hold a link. When each department behind the desk has its own request form with its own custom fields, the catalog entry for accounts can point at a form that asks for the start date and the role. In that setup, the entry for remote access can point at one that asks for the device and the hours. QuerySolv's departments each have their own form and custom fields for that reason. The request arrives with the details the entry promised, first time. The list, though, comes first. The form only asks the questions the list already decided.

When the next person asks "does IT do that?", the answer is a link, and the link says the same thing to everyone. Priya gets the badge printer's owner. Marcus gets the e-mail setup and nothing more. Lena gets the meeting-room entry, which says the projector is IT's and an event needs a day's notice. She will have that next time. Three questions, one answer. It is a small thing to want, and it takes an afternoon.

Frequently Asked Questions