How to Build a Service Catalog Without Hiring a Consultant

Say the words "service catalog" to most small IT teams and you will get a slight eye roll. It sounds like something a large enterprise IT department invented to justify a team of process people, complete with approval chains and a glossary nobody reads. In practice it is far simpler than the name suggests, and considerably more useful.

A service catalog is a written-down list of the requests your team already handles, organized clearly enough that people can help themselves instead of messaging you every time. You do not need a consultant to build one. You need about a week, a willingness to start small, and the discipline not to overthink it.

The five steps a request moves through once a service catalog is in place.

Why It Earns the Week It Takes

Most people would rather solve a problem themselves than open a ticket and wait on somebody. Every request that resolves without a human getting involved costs your team nothing beyond the time it took to write the entry once.

The arithmetic is worth doing plainly. A request handled through self-service takes none of your day. The same request over chat takes yours and theirs, plus the context switch on both sides, plus the two clarifying questions because the first message did not include the department or the start date. Multiply that by the number of times a week somebody asks where to get a monitor. For a one or two person team, that gap is the difference between firefighting all week and having time for work that compounds.

Step One: Write Down What People Ask You For

Before building anything, spend five to seven days logging every request that arrives, however it arrives. Email, chat, somebody stopping at your desk with a laptop under their arm. Do not organize any of it yet. Just capture it.

By the end of the week you have a real list rather than a remembered one, and it is usually more repetitive than anyone expects. New laptop, password reset, software access, new starter setup. A handful of request types tend to account for most of what you handle.

Step Two: Group It Into a Few Categories

Sort the raw list into a small number of buckets, somewhere around five to eight for a small team. Hardware, access, software, joining and leaving, and general troubleshooting covers most of what comes up at a typical small business.

Resist getting granular straight away. A catalog with sixty hyper-specific entries is harder for you to maintain and harder for everyone else to navigate than one with a dozen clear categories. You can always split something out later, once real usage shows you where the split belongs.

Step Three: Decide What Happens for Each One

For every category, pin down three things. What does the person asking need to give you up front? Who handles it, even when the honest answer today is "IT", meaning you? And how long does it take?

 Be honest on that last one. If password resets usually take four hours, write four hours. Do not write "immediately" because it reads better, because the estimate you publish becomes the expectation you are then judged against, and an accurate four hours generates far fewer chasing messages than an aspirational ten minutes.

This step is what turns a list into a catalog. It sets expectations for whoever is asking, and it gives the team a written standard rather than something that lives in one person's head. The head is the problem: it becomes a liability the first day that person is out sick.

Step Four: Build Forms, Not a Free-Text Box

Once you know what each request type needs, build a short form for it, rather than leaving people to type a paragraph into an email and hope they included everything. A hardware request that asks for the start date, the department and the equipment type up front saves you a round of clarifying questions every single time.

This is usually where small teams hit a wall without a tool built for it. A dozen structured forms maintained in a spreadsheet or a shared inbox gets messy quickly, and it tends to come apart exactly when volume picks up. Worth knowing if you are already looking at software for other reasons, and worth ignoring if you are not: the forms matter more than where they live.

Step Five: Publish It, Then Keep It Alive

A catalog nobody uses may as well not exist. Put it somewhere obvious: a self-service portal if you have one, a pinned link in whatever chat tool the company already lives in, a line in the onboarding pack for new starters. The rule is simple. Make the catalog easier to use than messaging you, or people will keep messaging you out of habit, and they will be right to.

Then keep it alive, because this is the most common way these projects quietly fail. Not a bad catalog, but a good one that nobody touched again after the initial burst of enthusiasm. Once a quarter, check for request types that have appeared, confirm the turnaround estimates still match reality, and retire anything that has gone stale. Fifteen minutes, four times a year, and somebody's name against it.

What a Starter List Looks Like

It helps to see this made concrete. A first pass for a fifty-person company might be:

• New equipment requests
• Equipment repair or replacement
• New software or license requests
• Account and password issues
• New starter setup
• Leaver and access removal
• General help, for anything that does not fit cleanly yet

 Seven categories, each with a short form and an honest turnaround estimate. Notice what is absent: nothing about specific laptop models, nothing department-specific, nothing hyper-detailed. Those details belong inside the form, as questions the requester answers, not as separate categories. Keeping the top-level list short is what keeps it usable six months later.

Mistakes Worth Avoiding

A few patterns show up repeatedly in catalogs that do not work:

• Writing categories the way IT thinks about them internally, rather than the way an employee describes the problem when they are stuck
• Publishing turnaround times nobody on the team agreed to or can hit
• Building it once, in a burst of motivation, and giving nobody ownership of keeping it current
• Making the catalog harder to find, or slower to use, than messaging a person

When You Do Not Need One Yet

We sell request management, so treat this as the section where we argue against ourselves.

If you are fielding three requests a week from fifteen people who all sit within earshot, a catalog is process for its own sake. A pinned document listing what to ask for and what it takes will do everything a catalog would, at a fraction of the effort, and you will know when you have outgrown it. The signal is not headcount. It is the week you answer the same question four times, or the week somebody says they did not know they could ask.

When that arrives, the catalog is the first piece of structure worth putting in, mostly because so much else gets easier afterwards. Access control becomes a matter of writing down who already handles what, which is the hard half of role-based access control. Reporting becomes possible, because requests arrive sorted rather than in one undifferentiated inbox. And the next person who joins the team reads a document instead of learning by oral tradition.

On our side, the catalog is not a separate product: it is part of request management, which is on every plan, because an ITSM platform whose entry tier cannot take a service request is not a credible one. The portal that publishes the catalog to employees is included from our middle tier upward and can be added to the entry tier, and the whole ladder is on the pricing page so you can work out where you land without asking us.