Rob England: What is a Service Catalogue?

"The menu analogies we see all the time when talking about service catalogue are misleading. "
"The menu analogies we see all the time when talking about service catalogue are misleading. "

We are looking at railways (railroads) as a useful case study for talking about service management.

What is the service catalogue of a railway?

If you said the timetable then I beg to differ.  If you said one-trip, return and monthly tickets I don’t agree either.

The menu analogies we see all the time when talking about service catalogue are misleading.

A menu (or timetable) represents the retail consumer case: where the customer and the user are one.  In many scenarios we deal with in business, the one paying is not the one consuming.

The service catalogue describes what the customer can buy.  The request catalogue is what the user can request.  Consider a railroad cook-wagon feeding a track crew out in the wilds: the cook decides with the railroad what to serve; the staff get a choice of two dishes.

The cook’s services are:

  • Buying and delivering and storing ingredients
  • Mobile cooking and eating facilities
  • Cooking food
  • Serving food onsite

That is the service catalogue.  The railway can choose to buy some or all of those services from the caterer, or to go elsewhere for some of them.

The menu is a service package option to the “cooking food” service.  The railroad chooses the options based on cost and staff morale.  The menu gives staff the illusion of choice.

First and foremost, a service catalogue describes what a service provider does. How often and what flavour are only options to a service or package of services.  A railway’s service catalogue is some or all of:

  • Container transport
  • Bulk goods transport (especially coal, stone and ore)
  • Less-than-container-load (parcel) transport
  • Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
  • Door-to-door (trucks for the “last mile”)
  • Dangerous goods transport (the ethanol delusion generates huge revenues for US railroads)
  • Large loads transport (anything oversize or super heavy: huge vehicles, transformers, tanks…)
  • Livestock transport
  • Rolling-stock transport (railways get paid to deliver empty wagons back their owners)
  • Finance (a railway can provide credit services to customers)
  • Ancillary freight services: customs clearance, shipping, security…
  • Passenger transport
  • Luggage
  • Lost luggage
  • Bicycles
  • Pet transport
  • Food and drink services (onboard and in stations)
  • Accommodation (big Indian stations all have dormitories and rooms)
  • Tours and entertainment (party trips, scenic trips, winery trips…)
  • Land cruises (just like a cruise ship but on rails)
  • Travel agency
  • Bulk goods storage (railroads charge companies to hold bulk materials in wagons for them awaiting demand: they provide a buffering service)
  • Rolling stock storage (in the USA railroads make money storing surplus freight wagons for other railroads)
  • Rolling stock repair (railways repair private equipment for the owners)
  • Private carriage transport (in many countries you can own your own railroad carriage and have the railway carry you around; a fantasy of mine)
  • Property rental (many large railways are significant landlords)
  • Land sales

Where’s the timetable or ticket pricing now?  It has such a small part in the true scope of a railway’s services as to be trivial.  More to the point, it is not a service: tickets are request options associated with one of many services.  Users don’t request a service: “I’d like an email please”. No, they make a request for an option associated with a service: provision email, increase mailbox, delete account, retrieve deleted email etc…

People confuse their personal consumer experience with business: they try to apply consumer experience models to business processing.  Most customers don’t want a service catalogue “to look like Amazon”.  They want meaningful business information.  The best vehicle for that is usually a text document.  The users/consumers of a service(s) may want to see the requests associated with that service(s) in an Amazon-like interface.  Sometimes there may even be a valid business case for building them a groovy automated request catalogue, but it is not the service catalogue.

The service catalogue defines what we do.  It is not simply an ordering mechanism for customers.  That is that personal/business thing again.  A service catalogue has multiple functions.

  1. Yes it is a brochure for customers to choose from.
  2. It also provides a structure to frame what we do as a service provider: availability planning, incident reporting, server grouping… Once we have a catalogue we find ourselves bring it up in diverse contexts: “we see the list of services show up in the table of contents”.
  3. It is a reference to compare against when debating a decision
  4. It is a benchmark to compare against when reporting (especially the service levels, but not only the service levels)
  5. It becomes a touchstone, a rallying point, an icon, a banner to follow.  It brings people back to why we are here and what we are for as an organisation.

You don’t get that from Amazon.

Then we come to that endless source of confusion and debate: technical service catalogue.  That deserves a whole discussion of its own, so we will look at it next…

21 thoughts on “Rob England: What is a Service Catalogue?”

  1. Hmm. Do not really like the model, it describes a very old business model.

    The local railway has been split to different companies or divisions. One of those does only passanger transport.There is not even a luggage car.  They do not own the rails or stations. The definitely do not serve food on stations.The restaurant services on the trains are provided by a different company. Rob’s model would make their service catalog look very short. Just one or two lines.

    I would say that their services are the trains between two places at specific times. Then there are options, you can book a place for a bicycle or car. You can get a seat in a pet section etc but these are additional service options which are only sold along the basic service.

    1. I don’t see how citing one extreme use-case invalidates a model.  It’s a valid model for many railroads around the world.
      In the case you cite, yes they may well want to have a different meta model for their catalogue that better suits there business.   Or perhaps they do have only one service.
      My key point is that a request-type usually doesn’t equate to a service and we shouldn’t confuse the two, but folk often do, hence the overworked menu analogy.

      1. Our old VR (State Railways) extreme, no way;) The Brits have the extreme model and I sincerely hope our politicians don’t follow that.

        But I see your point. The menu analogy has some good points, the best being that customers and workers see things differently. You are absolutely right in that service catalog is not the same as a menu of things to order. One of my customers proudly presented to me their service catalog which had services like: Memory stick, Mouse. Yes as services, true story. I think they even used an certified ITSM consultant to create the catalog.

        What I don’t like in the model is that is a 3rd world model. I can believe that a lot of companies may use such primitive models in countries like USA (railways are not the thing in USA) or India, but they are not a good model to use for modern IT. The problem with ITIL is that describes past world, just like your model.

        1. OK I’ll bite.

          The model applies to the majority of railways i am aware of.  In fact it applies to all of them  – as discussed above – but some railways are public transport only and therefore only have a few services with many options.

          In your first comment you mentioned “The restaurant services on the trains are provided by a different company” as if that would remove them from the railway’s service catalogue.  of course ti doesn’t: it just means supply is outsourced.  You know that.

          then you suggest that the service of transporting me form A to B is a different service depending on what time of day it is.  that is absurd.  The IT analogy would be that email at 10am is a different service to email at 11am.

          Please explain what is “3rd World” or “primitive” about the model.  Because you haven’t.

          By using the railway example perhaps we can then understand what is meant by “modern IT” and its different needs for a model.

          1. Rob
            I really appreciate that you actually read and think about the comments you get. It makes discussion so much more interesting.

            The VR list is their corporate structure. Yes they do all those things, but for example Transpoint Oy is a separate company (Oy =Ltd). The business units have their own service catalogs. Here you can find the Passanger service and you are quite right that it is not a timetable

            For example the restaurant services are provided by Avecra Ltd (, only in Finnish). Avecra is also a separate company and I see there a difference to outsourcing, VR transports and Avecra feeds.

            The time aspect depends on the type of service. Email and commuter trafic are continuous services. From my station there are 12 trains per hour to the center, so that is a continuous service, but to Kajaani there are only three trains per day and therefore the time is more important. Actually a timed email might be interesting, less disruptions if the emails came in one or a few batches per day.

            The 3rd world model is “We do everything” l with a single, long and complicated service catalog. The modern business model finds the core business and concentrates on that.

            Translated to IT it means that in the old model the IT is a large department which does everything from maintaining data centers to writing code. ITIL V3 is written to to this type of IT. Modern IT has specialized to doing just some specific things. One framework does not serve all types of IT services.

        2. P.S. Service catalogue of Finnish State Railways VR Group:
          Commuter servicesIntercity and international expressesCar transportFreightFreight logistics (Transpoint Oy Ab)TruckingRoad transport (buses)

  2. I see the point here re the complexity of running a railway and that the menu analogy doesn’t answer everything – however all analaogies break down at some point. I like the menu one as it speaks directly to people and clarifies the need for defined services. As Service Management is a ‘supply chain’, the menu is only part (the front end) of the ‘Service Catatlogue’ which to me includes recipies, kitchen work instructions, food procurement etc – all the activities run ‘behind the scenes’. So there is no separate ‘technical’ or ‘business’ service catatlogue – its all part of the same process – these are just different views and outputs.

    O do think we are in danger of over complicating and mystifying this topic (a la CMDB) – which is certainly difficult to do and involves some complexity. However the idea (talk to your customers and deliver them services not just systems, report on value delivered) is still a fairly strightforward one. 

    1. Many things in IT are simple in concept.  Almost none of them are simple in execution.  Railway service catalogues are much simpler than IT ones.  And yet 
      railway service catalogues are more complex than restaurant ones.  I think 
      we are in danger of over simplifying and demystifying this topic with the menu analogy 🙂

      As to Tech service catalogue being just another view of the catalogue, I completely and utterly agree  ITIL doesn’t.  V2 was vague. V3 has firmed up its position that a TSC catalogues “technical services” which underlie “business services” as components of them. See Service Design figure 4.4 and section 

      1. Good to hear your ageement re the multi-view point – its definitley a regular source of confusion.

        On the over-simplification point I agree we might be over-simplifying with these anlalogies, and that this is not an easy thing to do. However I think people are already confused so the value here is to get some clear messages out there to help people get started…:-)

  3. Again, I think we’re not emphasising the reason we deliver services, and that’s to help customers achieve an outcome.  Services can be subjective, and it’s the customer’s view that is important, whether they are the type of customer who consumes the service or not.  One customer may see the service as being the journey from one place to another – why would they be wrong if they see if this way?  In order to decide what the services are, you need to identify who the customers are and what outcome they want to achieve – without this, you can debate as much as you like about what is and isn’t a service, frankly it’s the customer’s view that’s most important.
    The cooks services you describe sound like services to the railway management, but not to the traveller who is wanting a specific dish from the menu.  The cook is part of the service provision to the traveller, and the reason why the cook has to do all of these things is because there is a customer willing to part with their money for a meal – that context must be acknowledged, because without it there is no need for the cooks services which you described.

    1. Agree and disagree.

      Every customer has their own VIEW of the service catalogue.  it is the role of CRM, or as ITIL calls it: BRM, to provide that custom view to each customer.  but if we have 476 customers we don’t have 476 catalogues.   there is one service catalogue.  I’ve mapped 8 different types of service catalogue views, customer is one of them.

      A brochure describing passenger services is a customer view of the service catalogue.  A timetable on a station wall is a request catalogue.  A request catalogue is a customer-specific view (actually a consumer/user-specific view) of the service catalogue for one (or more) service.

      Re-read that bit of the article: it says “a railroad cook-wagon feeding a track crew out in the wilds”.  The cook’s customer is indeed the railroad management, not the consumers of the food.   I cited this as an example of a food menu where the customer is not the consumer.  A hundred years ago the railroad management didn’t give a flying fox what the gangers thought of the food, so long as they didn’t riot or starve to death.  Nowadays we’ve gone soft 🙂

      1. Rob

        As always, a good debate.

        I definitely agree that you don’t have 476 catalogues.  Personally I try to standardize as much as possible, obviously not going to the point of any risk to value or quality, and I tend to go with one service catalogue with categories as a way of grouping certain types of services.  User-requestable services is one such category, and I’d go with your view of the timetable to a certain extent – I think the journey from A to B is likely to be thought of as the service by the majority of users/customers and they would probably see the timetable as detailing some options – i.e. “what time do I want to travel?”.  They are also likely to see the class of travel as an option too, however, if the majority of customers saw the services in a different way, maybe the catalogue should be updated so that it resonates with the majority of people.

        Again, I agree that the brochure gives a view of the service catalogue, and there’s nothing wrong with publishing a view to a certain customer type, for example having a service request catalogue online in a portal – it doesn’t show all the services in the catalogue, just the user-requestable ones.

        You are right that you very clearly state the scenario where the railroad cook is delivering service to the railroad management.  However, you also seem to be agreeing that the consumers of the food are also a customer receiving a service – a user-requestable service.  Do you agree that the cook is also delivering a service to these consumers?  The railroad management, who fund it, don’t care too much about quality and customer satisfaction, but they care enough to want to ensure there is no rioting or starvation.

  4. Hiya,

    let’s step back a bit and think first. What are the problems the a service catalog should solve? Any definition should be measured in terms of how good it helps to solve a problem. I like Rob’s article because it helps shaping our mental model of a service catalog.

    This list of different offerings (like the railway’s service catalogue above) is indeed what my customers wants to see. I think there is a matching problem: How does a customer find the right IT offering for his problem? Most of the time the service catalogue is too techy and the important details are always not mentioned. So, most of my time I’m busy with re-writing my service offerings due to increased understanding (or technical changes).

    Another problem I see is the following: How does a service provider defines a list of offerings if does not really know, what the business function of a service is and if he does know not which service elements have to be stated explicitely. When confronted with cheaper offerings of competitors I find out that our offering has a lot more functions and value included than those of the competitors.

    Though I know the technical infrastructure, the processes and the clients’ needs I always discover information gaps. I’m missing a systematic approach to discover the offerings and service elements which are really relevant. With the timetable or restaurant menu card analogon you discover only that there is passenger transport between Kaikoura and Christchurch or that there are dishes for fish or pasta. (And of course it’s only the personal consumer=user view) (see note 1). But you never discover the “Rolling stock storage” offer or the party service a restaurant offers, too.

    So, timetable and restaurant menu card are not well suited to be a service catalog.

    Bye, Jan F@42a38f57ee3e332b384f15fdac82f08d:disqus schbach (

    Note 1:

    What helped me so far is the business model matrix in the MIT Process Handbook (, the business model canvas of Alex Osterwalder ( and a very special working paper of Pratim Datta ( Maybe with these matrices I can discover my blind spots or implicit offerings. If you know some other matrices, drop me a line.

  5. Folks – consider taking a marketing class with someone like Pragmatic Marketing, or discussing this with a professional marketer.  I agree a service catalog is a brochure.  It can also present itself in any format and guise required to convey information to its intended audience (M3 anyone?).  

    You don’t start with developing a service catalog – thats inside-out thinking.  As those who know the USMBOK will recognize, you start by asking:

    “What business are we in?” (thanks to Ted Levitt)
    “Who do we serve?”
    “What activities do they perform in pursuit of their success?”
    “How do we help them with these activities?”… and so on

    The service catalog is something you look to develop AFTER you have gone through the process of what many might recognize as building a Service REQUEST catalog and understanding the customer (service) 4Es (including experience), and designed service request pathway through the provider organization.  You start with why not what and how.

    Customer actions, desired outcomes and acceptable range of experience, and the service request we use to encapsulate the response, help shape the service request system which is effectively an unbundled set of service capabilities.  Marketing and specifically product management skills are applied to bundle subsets of these into services for a deliberate purpose.  Along the way, and near the very beginning, you’ll need to craft a ‘positioning statement’.  All skills taught in product management…

    Respect the marketing and product management profession – please.  Yet again I fear we are trying to (re)invent stuff as ITSMers.

    1. Ian
      Your list of questions is very much the way I would start (re-)doing a service catalog. But… 

      Usually the situation is that the services have been running for years but for some reason people are not happy with the catalog. If we are talking about an internal service it is not a marketing approach. IT is working WITH business to help business to reach their outcomes. Internal IT is NOT marketing products to business.

  6. Matthew – some sanity from you again – thank you.  Yes – customers care most about outcomes.  They perform activities in their pursuit (as per my previous post).  Nowadays, and as part of the ‘next generation’ service management conversation I’m encouraging, customer don’t care about ‘services’ per se, and this entire discusion on yet another ‘not required yet’ artifact such as the service catalog is another massive indicator of inside-out thinking that fails the customer.

    Once and for all please, forget building stuff.  Go grab coffee and doughnuts and go on a ‘service safari’ and observe your customers in their natural habitat and understand what they do and why they do it and how you help or hinder them…. please… think and act outside-in – its long overdue in ITSM circles.

    1. There is a risk we patronise and offend the readers of this article if we assume they don’t already have a working relationship with their customers, if we berate them for not doing basic stuff without any knowledge of their current state.  Nowhere does this article or its comments say “the first thing you do is build a service catalogue before talking to anyone”.  In fact the article talks about what business are “you” in, implicitly assuming the understanding and unity is there.  You are addressing a different issue which may or may not be present; customer relations.  I completely agree about establishing it first if it isn’t present.
      What I don’t agree with is “stop building stuff”.  You can’t run a business without building stuff.  If ALL we do is grab a doughnut we won’t be in business for long.  And if ALL we think about is the outside of IT, we won’t build much: we will end up gazing at our own navel (something I haven’t been able to do for a number of years now).Outside-in is a useful perspective that we must factor in.  it isn’t the be-all and end-all of designing and operating IT.  It is one view of service catalogue, probably the most important one: the customer view.  But there are other views for other consumers of the catalogue: – CRM “account manager” view- IT operations view- support view- IT management/reporting- governance viewetc

      Sometimes your message comes across as “stop doing everything that IT normally does and start being a marketing and product management department”.  Or perhaps it is aimed specifically at ITSM: “stop worrying about the lifecycle and value chain/network of the service and concentrate only on the pointy end of it”.  I’m sure those are both wrong interpretations: I’m just sayin’.

  7. A few final comments from me on this.

    SLM/Service Catatlogue/SLAs/Portfolio management – to me this is all part of a process that can and does truly revolutionise and improve the way IT organisations work – for and with their customers. Of course it has to be done well and the internal IT culture / ITIL approach has in many cases not been helpful. To me I usually get these projects done in spite of more than because of what’s in ITIL.

    However I also get weary of hearing that everything that the industry is doing is wrong. I personally (and many others) have used a business-savvy version of common sense applied to these ITSM projects for 20+ years – and that’s constantly evolving. Most of the points in this debate are good ones and of course we need to clarify who the customers are, what business we are in and what are the key outcomes – that’s the whole point of this process.

    The difficullty is in trying to apply too much of a single standard format to that since every organisation is at a different level of maturity.  The mechanics aren’t that important compared to the process of working closely together and developing understanding and clarity of purpose on both sides. Thats’ the skill of the project and implementation team – which will of coruse vary.

    I agree absolutely we are all in Marketing – but everyone now also uses IT. Once again we’re navel-gazing about stuff that the world cares zip about – they just want IT to get on and deliver.

  8. Thank you for a great article and very interesting comments, just want to share my view as a rookie and quite inexperienced in ITSM. When I first read the article I suddenly understood a lot more and some of the issues I’ve had with wrapping my head around the service catalogue was clarified and straightened.

    And when I returned to the comments some time later and read what the very experienced ITSM people had to say my first thought was “My god, how can they not get the point?!”. And, of course, moments later when my mind caught up with my thoughts it’s quite clear to me that we are quite different as audience and read the article very different.

    Since the point I got from the article and the knowledge I felt I gained reading it is so obvious and long known by experienced people, it’s quite natural to look beyond that to get some value even though you already know all the basics.

    I learned a lot, both from the article and the comments. And I’m humbly looking forward to becoming both smarter as well as more experienced 🙂

    That was my somewhat “off-topic” two cents…


Comments are closed.