I have a couple of stand-out points to make based on my experiences across building service catalogues. In the ongoing evolution of IT service management, the conversation around the service catalogue vs request catalogue remains a misunderstood one. Too often, people treat them as interchangeable, or worse, prioritise one while disregarding the other. That’s a misstep. Both have value, and their importance depends on your organisation’s current state and business goals.
Let’s clarify the distinction. A service catalogue (SC) defines what services you offer. It’s your mission statement in practical terms, a structured view of the services you provide, from the perspective of the business. Even a simple document listing in excel named services qualifies as a service catalogue.
The request catalogue (SRC), by contrast, outlines what people can request against those services, add a user, reset a password, provision a new laptop, and so on. While ITIL doesn’t explicitly define this as a separate entity, any ITSM practitioner worth their salt knows it exists and has worked with one. It’s the user-facing front end to change or fulfilment processes, often connecting directly to standard changes or work orders.
From a data modelling perspective, it’s a one-to-many relationship, one service, many request types. This separation matters. Confusing or merging the two leads to unclear reporting, poor service communication, and chaotic operations.
DON’T BE FOOLED!, I had a big 4 consultancy group (so say experts on catalogues) basically claim to senior management we could skip the service catalogue and start with requests. That works in less mature environments, but it’s like steering a ship with no rudder in a large enterprise environment. You may move forward, but not efficiently. Without service definitions, it becomes harder to report availability, monitor true service performance, or carry out impact assessments for incidents and changes.
A defined service catalogue lays the foundation for everything from portfolio management and capacity planning to accurate SLA reporting. It clarifies scope, aligns IT outputs with business expectations, and gives you a shared language for service discussions.
That doesn’t make the request catalogue less important, it’s critical for enabling user self-service, automation, and structured fulfilment. But dismissing the service catalogue as old-fashioned misses the point. The goal is not to chase trends or adopt shiny tools. It’s to solve real problems with the right level of sophistication.
Every organisation is on its own journey. For some, a basic paper-based list of services is a good start. For others, automation and integration with request fulfilment workflows might be necessary. The key is to start with business needs, not technology preferences.
In the end, both SC and SRC are essential. The order in which you tackle them depends on what outcomes you’re aiming for. Maturity brings clarity—and that means knowing when to use which tool for the job.
🔗 Further Information.
I’ve been here & done this. Where i worked, we were told the request catalogue was good enough to represent our services mainly because it was already built into the ITSM tool. But when we started trying to align with finance and track SLAs, nothing matched up. In fact we had few agreed definitions of what the services actually were.
What helped us move forward was working with business stakeholders to define just 10 high-level services nothing fancy, just a shared language. That gave us the clarity we needed to clean up reporting and redesign requests properly. Completely agree that skipping the service catalogue leads to chaos down the line. Thanks Jess
Hey Jess, Ive seen the same issue where the request catalogue becomes a workaround, especially when it’s pre-set in a tool. But without that foundational service lens, reporting and planning quickly fall apart to the extent I often wondered why the hell are we reporting on some of this stuff. We could clearly see no decisions could be made around the reports.