#SMFlashbook My top tip for building a service catalogue

This post is part of a worldwide flashbook or flashblog, where many contributors simultaneously publish on the topic of "My top tip for building a service catalogue".

Here is my contribution to it:

Know the difference between service catalogue and request catalogue
(Join me for a twitterchat and webinar on service catalogues)

I know ITIL isn't some omnipotent authority, or even a standard*. But it provides a generally agreed set of practice for the industry, to try to get us all on the same page. ITIL is clear[pdf] on what a service catalogue is:

A database or structured document with information about all live IT services, including those available for deployment. The service catalogue is part of the service portfolio and contains information about two types of IT service: customer-facing services that are visible to the business; and supporting services required by the service provider to deliver customer-facing services.

Here we must be careful to distinguish between the customer who commissions and/or pays for a service, and the user who consumes it.
A service catalogue defines the services to the customer(s), not what a user does with them. The user's view is the request catalogue not the service catalogue.

    Customer service: email
    User request: new email account

A menu is not a service catalogue: Please can we desist with this awful analogy. It makes people think that a tool for automated service requests is an "actionable service catalogue". It's not. It's an actionable request catalogue. I wrote about menus and service catalogues at The ITSM Review, using railways as an example.

I dislike the analogy of a menu because a restaurant is not a good analogy for most business situations. The service catalogue describes services provided to customers. Request catalogue is what the user can request. These are not even similar unless user = customer, which is mostly not the case. Remember: customer pays, user consumes. The customer is only ever the same as the user in retail contexts, not business or public sector or not-for-profit or any other organisational context - what I call Real IT.

Folks in IT are constantly confusing their own personal digital retail experience with Real IT. Amazon and Apple are not examples of Real IT any more than a MacDonalds menu is.

A service catalogue is much much more than a portal to ask for stuff.

catalogue centre of the ITSM world
The service catalogue is the central common agreed definition of what we provide.
It is fundamental to all aspects of delivering a service.
The service definitions provide a common view of what we do, in order to align all those aspects.


  • A change or an incident impacts which service(s)?
  • Who owns those services? Who cares about the impact?
  • What services are we currently running? What services do we want to add? if we add them, what will be the impact on the overall portfolio?
  • If we decide to invest in a service that the customer wants better quality from, how do we ensure infrastructure and operations and support all invest in the same thing?
  • What do we measure and report the availability of, that will be meaningful to the customer?
  • How do we articulate IT's value to the business?
  • How do we charge back the operating costs of our core systems? (As distinct from charging for change, request and support?)
  • If the organisation asks IT to cut costs, how shall we decide where to cut? What can we use to have a meaningful discussion with the business about where to cut and why?
  • What shall we use as our top-level taxonomy when doing so many things in IT: capacity planning, asset grouping, incident categorisation...
  • What is it we talk about to customers?

None of that stuff is answered by a request catalogue. You need a service catalogue to find the answers.

If you are working on any catalogue initiative, you will get involved in confusing conversations (even failed outcomes) where people are thinking of entirely different things, such as:

  • service catalogue vs request catalogue
  • customer-facing service catalogue vs internal technical catalogue (I still maintain there is no such distinction as different services for customers and internally, but there are different views and purposes)
  • the concept of a catalogue vs the informational content vs the tool to display it


A service catalogue defines what your services are. It can be as simple or complex as business requirements dictate. A piece of paper with a list of the names of your services is a service catalogue.

A request catalogue lists what requests can be made against your services. It can be as simple or complex as business requirements dictate. In the simplest case this can be a drop-down box of request types on a service desk tool, or a list of request types on a piece of paper. The simplest request types are to provision or de-provision a service to a user or group of users. Ideally, request can be thought of as the user front-end to changes. There will be standard (routine) requests that link to standard changes or work orders that don't need to go through change control; and unfamiliar requests that lead to non-standard (normal) changes. See my response model called Standard+Case for more on standard vs non-standard.

You can have requests without knowing what your services are - many organisations do. Just as you can have requests without even knowing what your requests are. That happens often enough too - all requests are handled ad-hoc. But with increasing sophistication all organisations will need both a list of services (service catalogue) and a list of requests (request catalogue) at some point.

Bonus tip: All the many contributors to ITIL from both sides of the Atlantic agreed that it is spelt "catalogue" not "catalog". Stick to the convention, will ya?

There is lots more content in the comments below.
More on service catalogue vs request catalogue
Other posts on catalogues from the IT Skeptic
Please Like this blog

* There is a standard: ISO/IEC 20000. It doesn't define a service catalogue in the base 2007 standard, but the accompanying code of practice says "A service catalogue should define all services. It can be referenced from the SLA and should be used to hold material considered volatile for the SLA itself". It doesn't mention requests in the context of service catalogue.

Syndicate content