An ITIL 5 service catalogue is only as honest as the kitchen behind it.
There’s a restaurant near where I used to live with 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 say they hadn’t had duck in for three weeks. I tried the risotto. Also gone. The lamb shank, gone the week before. By the third attempt I asked what they actually had, and it turned out to be about six dishes, cooked well, from a kitchen nobody had ever consulted about the other thirty-four.
That menu is most ITIL 5 service catalogues I get asked to fix. If you’ve ever sat in a catalogue sign-off meeting and quietly wondered whether anyone in the room could actually deliver what was being approved, you already know where this is going.
The catalogue looks complete: every service listed, categorised, colour-coded, signed off by someone senior eighteen months ago. Then a real person makes a real request, and the kitchen, the team actually fulfilling it, either can’t deliver, doesn’t know the item’s on the menu, or delivers something that only vaguely resembles what was promised.
In this blog, I’ll walk you through the client catalogue that looked genuinely excellent and still collapsed within a month of go-live, why service catalogues fail quietly rather than loudly, and the three checks I now run before I’ll tell anyone theirs is ready to launch.
Built From a Workshop Isn’t Built From Evidence
Most failing catalogues weren’t built lazily. They came out of a workshop: a room of stakeholders listing every service they could think of, in good faith, from memory, with a facilitator writing furiously on a whiteboard. Memory is a rotten data source for this particular job. It over-represents whatever got discussed last quarter and under-represents the unglamorous, high-volume requests nobody thinks to mention, because they’re not interesting enough to bring up in a strategy session.
Ask a room how many password resets went through last month and you’ll get a shrug. Ask them to list every strategic service the business might someday need, and you’ll get forty minutes and a whiteboard covered in Post-its. That imbalance is exactly how you end up with thirty-four dishes nobody’s kitchen has cooked in months, all beautifully laminated and none of them checked against what the kitchen was actually sending out.
You might be looking at a menu-shaped catalogue rather than a working one if:
✓ Nobody can point to the ticket data the catalogue was checked against, only the workshop it came out of
✓ The “service owner” column is a department name, not a person
✓ The fulfilment team has never seen the request form the catalogue assumes people use
The Client Whose ITIL 5 Service Catalogue Looked Perfect
One client brought me in after their catalogue had already passed every internal review anyone could think of. Properly maintained. Clearly owned. Sensibly categorised. On paper, it was one of the better catalogues I’d been handed, and the programme board had signed it off without a single dissenting voice.
It collapsed within a month of go-live. Not because the services were wrong, and not because nobody wanted them. It collapsed because the fulfilment team had built their entire workflow around a formal request form, and almost nobody used it. Real requests arrived as a chat message to a line manager, the way they always had. The catalogue and reality had quietly diverged before the project even launched, and nobody had thought to check.
I pulled three months of actual request data (chat logs, email threads, the handful of tickets that had gone through the “proper” channel) and mapped it against what the catalogue assumed people would use. The gap wasn’t subtle once you looked: roughly seven in ten requests were arriving through a channel the catalogue had never accounted for. Fixing the paperwork wouldn’t have touched that. What fixed it was rebuilding the fulfilment path around the channel people were actually using, then tidying the process document to match reality instead of the other way round. Demand was real. Ownership was clear. The channel was wrong, and that’s the one thing an internal review will never catch, because reviewers read documents, not chat logs.
Six weeks after the rebuild, the same requests that had been bypassing the catalogue entirely were being logged and fulfilled through it, because the catalogue had finally caught up to how people actually asked. That’s the real difference between a catalogue that’s correct on the day it’s approved and one that’s still correct the day someone needs it.
Ownership Is the Ingredient Most Catalogues Skip
Every dish on a real menu has a chef 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 explain, on a bad day, why the thing isn’t working.
That gap matters because ownership is what keeps a catalogue entry from rotting. I once asked a “service owner” field that read “IT Operations” to explain a two-week fulfilment delay, and got passed between four people before finding someone who’d even heard of the service. Without a named person attached to an entry, it decays exactly the way a restaurant’s duck supply decays: quietly, until a customer finds out the hard way.
The Three Checks I Run Before Sign-Off
Before I’ll tell a client their catalogue is ready, I want to see:
✓ A fulfilment path tested against the channel people actually use to ask for the thing, not the one the process document assumes they use
✓ A named owner per entry who could explain a failure without checking with someone else first
✓ Demand evidence: the last three months of real requests, checked against the catalogue, not against the workshop that approved it
None of the three is expensive to run. 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.
None of this is really about the paperwork. ITIL 5 splits a service’s life into distinct Design and Deliver and Support activities within its Product and Service Lifecycle, and the space between what an organisation designs and what it can actually deliver and support is exactly where catalogues like this one die.
So here’s the question worth asking about your own service catalogue: when did you last check it against a real request, rather than against the meeting where it was approved? If the honest answer is “I can’t remember”, you may be running a beautifully designed menu for a kitchen that stopped stocking half of it months ago.
To find out more about PDCA Consulting’s expert consulting services either:
Connect with me on LinkedIn
Book 30-minute conversation directly: here
Get in touch via the contact form here
