An ITIL 5 service catalogue, like a menu, is only as honest as the kitchen
There’s a restaurant near where I used to live that had a menu the size of a small newspaper. Forty dishes, beautifully photographed, laminated within an inch of its life. I ordered the duck. The waiter came back five minutes later, slightly apologetic, to tell me they hadn’t had duck in for three weeks. Then I tried the risotto. Also gone. By the third attempt I asked what they actually had, and it turned out to be about six dishes, cooked well, from a kitchen that had never been consulted about the other thirty-four.
That menu is most ITIL 5 service catalogues I’ve been asked to fix.
The catalogue looks complete. Every service is listed, categorised, colour-coded, and signed off by someone senior at a steering meeting eighteen months ago. Then a real user makes a real request, and the kitchen — the people actually fulfilling the service — either can’t deliver it, doesn’t know it’s on the menu, or delivers something that bears only a passing resemblance to what was promised.
In this blog, we’ll explore why service catalogues fail quietly rather than loudly, what ITIL (Version 5) actually asks you to build instead of a laminated wish list, and the three checks I now run before I’ll tell a client their catalogue is fit to launch.
A Catalogue Built From a Meeting Isn’t a Catalogue Built From Evidence
Most failing catalogues I see weren’t built maliciously or lazily. They were built from a workshop: a room of stakeholders listing every service they could think of, in good faith, from memory. The problem is that memory is a terrible data source. It over-represents whatever’s been discussed recently and under-represents the unglamorous, high-volume requests that never come up in a strategy session because nobody finds them interesting enough to mention.
ITIL 5 frames this squarely as a demand management problem, not a documentation problem. A service catalogue is meant to reflect actual, observed demand and confirmed fulfilment capability — not aspiration, and not the political priorities of whoever chaired the workshop. If your catalogue was built in a single afternoon and never checked against ticket data afterwards, you don’t have a catalogue. You have a menu nobody’s checked against the kitchen.
Ownership Is the Ingredient Most Catalogues Skip
Every dish on a real menu has a chef who’s accountable for it turning up as described. Most catalogue entries I audit have no equivalent — the “service owner” field is either blank, or filled with a department name rather than a person who could actually explain, on a bad day, why the thing isn’t working.
This matters more than it sounds, because ownership is what turns a catalogue entry from a static description into something that gets maintained. Without a named owner, a catalogue entry rots exactly the way a restaurant’s duck supply rots: quietly, until a customer finds out the hard way.
Request Fulfilment Has to Match How People Actually Ask
Here’s the part that trips up otherwise well-built catalogues. The catalogue can be accurate, owned, and demand-checked, and still fail if the request-fulfilment path doesn’t match how people actually ask for the thing. If your catalogue assumes a formal request form and your users actually ask via a chat message to their line manager, the catalogue and reality have already diverged, no matter how good the paperwork looks.
One client I worked with had exactly this gap. The catalogue was, on paper, one of the better ones I’d reviewed — properly maintained, clear ownership, sensible categorisation. It collapsed within a month of go-live because the fulfilment team had built their workflow around a request format almost nobody used. The demand was real. The channel was wrong. That’s an easy thing to miss and an expensive thing to fix after the fact. you can learn more with the Monitor, support and fulfil qualification
The Three ITIL 5 Service Catalogue Checks I Run Before Sign-Off
Before I tell a client their catalogue is ready, I want to see:
✓ Demand evidence — pull the last three months of tickets and check the catalogue against what people actually asked for, not what the workshop remembered
✓ A named owner per entry who could explain a failure without checking with someone else first
✓ A fulfilment path tested against the channel people actually use, not the one the process document assumes they use
None of these three checks are expensive. All three get skipped, routinely, because a finished-looking catalogue feels like a finished project, and nobody wants to be the person who reopens it.
So, the question I’d ask if you’re staring at your own service catalogue right now: when did you last check it against a real ticket, rather than against the meeting where it was approved? If the honest answer is “I can’t remember”, you may well be running a very well-designed menu for a kitchen that stopped stocking half of it months ago.
To find out more about PDCA’s training or consulting services either:
- Get in touch via the contact form here
- Connect with me on LinkedIn
- Book a 30-minute conversation directly: here
