Most organisations have a service catalogue somewhere. It might be a spreadsheet on a shared drive, a set of intranet pages, or a module in the ITSM tool that someone filled in during the original implementation. Ask the service desk when they last opened it, though, and the answer is often a shrug.
That is a shame, because a catalogue people actually use does a lot of quiet work. It sets expectations, routes requests to the right team first time, gives service level management something concrete to measure against and helps the business see what IT really provides. A catalogue nobody uses does none of that. It slowly drifts out of date until it becomes a liability.
Here is what tends to separate the two.
Start with the people who will use it
The most common mistake is building the catalogue from IT’s point of view. Teams list their applications, platforms and technical components, and call each one a service. The result is accurate, but it reads like an asset register.
A user does not want “Exchange Online” or “Citrix farm 2”. They want access to a shared mailbox, a new starter set up or a laptop ordered. Before you write a single entry, spend some time with the people who will use the catalogue: end users, service desk analysts and business relationship managers. Ask what they come to IT for, in their own words. Those words become your service names.
It also helps to accept early on that there are usually two audiences. Users need a short, plain list of what they can ask for. IT teams need the detail behind it: supporting services, owners, dependencies and targets. ITIL has long described these as the business view and the technical view. You do not need two separate documents, but you do need to be clear which view each piece of information belongs to.
Keep the first version small
There is a strong temptation to catalogue everything before going live. In practice, that means months of workshops and a launch that arrives after everyone has lost interest.
A better approach is to look at your request data. In most organisations, a small number of request types make up the bulk of the volume. Start with those. A catalogue that covers the twenty things people ask for most often, and covers them well, is far more useful than one listing two hundred services with half the fields left blank.
Once the first version is in use, the gaps show themselves. Requests logged as “other” or “general enquiry” are a good signal of what is missing.
Make every entry answer the same questions
Consistency matters more than detail. For each service, a user should find the same handful of things in the same place:
- What the service is, in a sentence or two
- Who can request it, and whether approval is needed
- Any cost or budget impact
- How long it normally takes
- How to request it, ideally with a direct link to the form
Behind the scenes, each entry also needs an owner. Not a team, but a named person responsible for keeping the entry accurate. Without one, nobody notices when a process changes and the catalogue quietly becomes wrong.
Connect it to the way work actually flows
A catalogue that sits apart from the ITSM tool will always struggle. If users read about a service in one place and log a ticket somewhere else, many will simply skip the first step.
The catalogue works best as the front door. Each entry should lead straight to a request form that captures the right information up front, routes the ticket to the correct team and applies the right workflow and targets. With that link in place, the catalogue stops being documentation and becomes part of how the service desk runs. It also gives you clean data: demand by service, fulfilment times by service and a clear view of where the bottlenecks are.
This is where tool configuration matters. Most modern platforms, whether Marval, Jira Service Management or ServiceDesk Plus, can support this well, but only if the catalogue structure, request models and workflows are designed together rather than bolted on one after another.
Agree what good looks like for each service
An entry that promises a laptop “as soon as possible” helps nobody. Where it makes sense, each service should carry a realistic target that the teams behind it have agreed to. That target then feeds into service level reporting and any underpinning operational level agreements.
Be careful not to overreach. Not every service needs a formal SLA on day one. It is better to publish a sensible typical timescale and measure against it than to commit to targets nobody has tested.
Treat it as a living thing
Catalogues decay. New services appear, old ones are retired, approval rules change and prices move. The organisations that keep their catalogues useful tend to do a few simple things:
- Review each entry on a fixed cycle, usually every six or twelve months, with the owner signing it off
- Make catalogue updates part of change management, so a new or changed service cannot go live without its entry being updated
- Watch the data, especially requests that bypass the catalogue or land in the wrong queue
- Ask users and analysts what confuses them, and fix the wording
None of this is complicated. It just needs someone to own it.
A quick check on your own catalogue
For a rough sense of where you stand, try three questions. Could a new starter find out how to request software without asking anyone? Do your ten most common request types each have an entry linked to a form? And does every entry have a named owner who has reviewed it in the last year? If the answer to any of these is no, there is probably some easy value waiting.
Is your service catalogue gathering dust, or are you starting from scratch? Book a free scoping call and we will help you design one that people actually use.
