A menu is not a service catalogue

A menu is not a service catalogue. Please can we desist with this awful analogy. It makes people think automated service requests is an "actionable service catalogue". It's not. It's an actionable request catalogue.

I dislike the analogy because a restaurant is not a good analogy for most business situations. Service catalogue describes services provides to customers. Request catalogue is what the user can request. These are not even similar unless user = customer, which is often not the case. Remember: customer pays, user consumes. That's true mostly in retail contexts, not business or public sector.

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. Choices are (generally) not distinct services. They are requests to be fulfilled. There is a many-to-many relationship between service and request: one service has many requests and one request can involve many services, e.g. provision a new staff member. I recall from my data modelling days that this is a clear indicator of distinct logical entities.

A restaurant's services are some or all of:

  • food a la carte
  • buffet
  • drinks
  • BYO
  • takeaways
  • deliveries
  • toilet
  • private functions
  • catering
  • cooking lessons
  • ...

THAT is their service catalogue

Railway timetables

I wrote about service catalogues at The ITSM Review, using railways as an example. Check out that article. As part of the comments on that article we got into this debate, but not over menus, rather we debated timetables for train services, which are just another kind of menu. I said a timetable on a station wall is a request catalogue. A request catalogue is a consumer's view of their available choices for one or more services. If a timetable is a service catalogue rather than a request catalogue then the service of transporting me from 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.

Actionable catalogue

In the long tradition of IT solving everything with technology, there is a fad right now for "actionable service catalogue" "like Amazon". The vendors are beating this drum. It is automation of request entry or all of request fulfillment. Following on from the argument above, we can see that this is not service catalogue that is being made interactive; it is request catalogue.

If a full service catalogue were automated, a new customer could request a new service, with agreement of contractuals, costs and SLAs. This does happen with cloud providers, and in some cases even deals with service fulfillment where the customer is distinct from the user(s), e.g Google Apps.

But this is bleeding edge, and I'm tired of all the excitement over bleeding edge when most of the world is still trying to come to terms with the new millennium. In the vast majority of cases right now where the vendors have got a client excited about "actionable service catalogue", they are talking about automating service requests for in-house users.

That's nice (if there really is a business case for automating it and we're not succumbing to the usual IT infatuation with automation), but it isn't service catalogue. It is one subset, one use-case, one limited view of service catalogue: a request catalogue.

Let's get that clear. Several times I've raised service catalogue only to be told "Oh we're getting a tool to automate that". No you're not.

Starting with requests and working bottom-up to service catalogue is a fine approach (personally I prefer top-down from services to requests but that's a different debate), but let's be clear that service catalogue is a different thing and developing and maintaining and using it are different tasks. By all means build a request catalogue: you'll still have your service catalogue to do.

More on this from me in this article for The ITSM Review


A Menu is NOT a Service Catalogue

The menu in a restaurant is used by all, i.e. the users. Therefor it more resembles the Request Catalogue (something sadly missing in ITIL).

After all, the meals on the menu are merely the products delivered (comparable to an application). And it is not the product the customer wants, but the value he or she derives from this.

For instance a bowl of chips is the same product whether it is obtained in the drive-through of a fast food restaurant -with screaming kids in the backseat-, in a pub during the Sunday-session -with mates and a beer-, or as part of a romantic dinner-for-two in a seaside a-la-carte restaurant; same product but the value is completely different (convenience, atmosphere, privacy,view, ...).

Thus the ‘real’ Service Catalogue of a restaurant is the style, location, opening hours, interior, ambience etc.etc. ... All those things that make someone (i.e. the Customer) decide to go to that particular restaurant in the first place, rather than pick a specific dish of the menu.

Objectionable Service Catalogue

Thank God someone's said that out loud. I'm going to share this article with a colleague or two.

You know I think the US ITSM tool market has screwed this one for us, servicecatalog.com for a start. Not that ITIL helps. Menu indeed.

Anyway, I have used [part of] a tool to present the service catalogue data in a nice way for business consumption. Service catalogue management looked after the data, the tool automated nothing more than its presentation. A request catalogue was built alongside it, and where it made sense requests were associated with services. Nice, simple, intuitive - amazing how much stuff just works when you take the BS out of it.

Service catalogue step 1


I don't doubt a nice service catalogue can be presented in a tool. It's a glossy brochure, which is useful marketing for any org.

The vendors and their victims need to understand it's not step 1. (actually vendors understand it is not step 1 but they can't sell step 1)

Step 1 is to define a list of services if you take the top-down approach as I do
(or define a list of requests that users can make, if you take the bottom-up approach).

The first technology I use for defining and documenting is Word. Excel can be good too though we usually need lots of narrative to get useful info.

Once we have consensus from stakeholders on what the services are, we can then start adding
- packages
- service-to-customer relationships
- service levels
- options
- requests
- configuration: CI relationships to service

...in about that order unless business needs rearrange it.

Somewhere in there it gets too complex for Excel to be cost-effective.

And at some point we want to present it in a pretty way to customers. Word is good for that too :) but of course an HTML webpage is easier to keep current and accurate.

At a high level of maturity in complex environments, i can see that it would be effective and efficient to build an interface that customises the view according to the customer or does other clever interactive things. in those few cases the vendors finally get to make some money off me.



Using your example of a restaurant's service catalog above would an IS/IT provider's service catalog be something like (or contain):

Electronic Messaging (to include EMail and IM)
Telephony (POTS or VOIP/IPT)
Common Desktop Environment (to include Word Processing, Spreadsheet, Presentation Program)
Identity and Access (Password, rights/access management)
HR Technology/Software?
Sales Technology/Software?
Accounting Technology (Bills Receivable/Bills Payable, Payroll?)
Core Business Technology (Whatever is core/crucial tech/software to the company)
Accessory Business Technology (could be other items that "help" the business but are not actually core to the business - like maybe SharePoint, or Remedy)

But not really "exposed" to the 'customer' but required to provide other services are things like:

Data Center Power/Cooling/Space
Computing (physical/virtual)
Operating Systems

Would that stuff be listed at all or is that like your restaurant listing that they have ovens, grills, knives, microwaves, power, a dishwasher, and stuff like that?

I put "technology/software" because I'm not really sure which it should be. Or maybe it is neither of those things - I don't think it is "service" because IS/IT is not actually providing the HR Service - just the tools used by the HR Service...

And by "packages" are you meaning something like:

Telephony package 1 = Virtual phone, Physical phone, Voice Mail and Email Integration, Call waiting, Caller ID, other stuff

Telephony package 2 = Physical phone, Voice Mail, Call waiting, Caller ID, maybe other stuff

And does "service-to-customer relationship" describe how it is consumed or something else? Would this be something like the Service Blueprint (http://en.wikipedia.org/wiki/Service_blueprint)



Sample service catalogues

Hi Stephen

I think you need to take that list of IT services up a level: that's an inward-looking list. The catalogue should see IT from outside, as a black box. Technology on its own is not a service. it is a thing. the services we provide are (a) to host and nurture that technology on behalf of the organisation, or (b) to steward the underlying corporate data (in which case the technology is just a tool we use) or (c) to facilitate organisational activities which use the technology and data. Which one depends on your organisation's role for IT as a service provider.

I provide some (old) samples here. The spreadsheet provides a starter list of IT services. Note that

  • Application Services: you could call it "Information Services' or "Business Services" or...
  • Application Services will almost always include some industry-specific services. For example, my hospital clients provide the following services specific to their industry, along with all the usual generic ones like desktop provision, connectivity/communications, and productivity tools: clinical systems, ward management, outpatient services...
  • Services are about what we DO, not what we HAVE or GIVE. Actions not objects. So we PROVIDE desktop, we HOST apps, we STEWARD data, we ENABLE transactions, and we PROVIDE advice and consultancy
  • Network access is a service. The network is not. it is a component (CI) of services.

The "service-to-customer relationship" is the SLA. This can be one or many at either end of the link depending on your business model: one SLA per customer-service pair; one SLA per customer for many services; one SLA per service for many customers; or other variants.

Service Blueprints are about "service" in the old-fashioned sense of something performed over a counter, the activity of touching the user. It does have the outside-in perspective, but it is a lovely example of how limiting that persective is if it is all we have. We need to be much more holistic about a service, e.g advisory services, intergity protection...

All of the above is my opinion. It may or may not correlate to the holy books, or to mainstream opinion (often two different things).


Thank you for the link back to an earlier post. I must have missed that one.

I think most of the things I listed you have listed as well (some like for like) but you did break them up into those different "categories" (my word) which is interesting. Would the "Application Services" line up more with what would be in the Brochure Catalog(ue)?

Also, I realize this is not a final product or anything so you may not be much bothered - you have "Standard desktop" listed 2x - once under App and again under Technical and you also have "Desktop Management" under Technical - is this on purpose or is it due to the nature of this just being filled with examples of various sorts?

I ask because I wonder if it is good to list a service under the different categories - can a service be both Application and Technical? Is that what you are indicating?

I like this concept. But it all still is not crystal clear


That comment really makes me wonder - is "Send Mail" really the Service Catalog(ue) entry? I like your much better at "Communication" but the issue is then under that you'll have:

DR Communication System
System Ops Alerting System

Would those services be captured under the Technical Category? And then related to "Communication" in the App Category?

More on service catalogue

Hi Stephen

I'm a philosopher not an expert, and a sloppy one at that :) thanks, I'll fix the inconsistencies.

Standard desktop is either an Application service or a Technical service: depends on attitudes. Desktop management is a different thing: standard desktop provides a work environment; desktop management keeps it working. Standard desktop delivers "Generic Productivity Suite" (Office etc) possibly as a SOE. Desktop management provides updates, upgrades, onsite field support, hardware MACs etc. the spreadsheet could use explanatory notes, I know. You get what you pay for :)

Brochure Catalogue is a view of the catalogue. there is only one set of services for an organisation, one catalogue. the differing views of a catalogue (brochure, technical) list subsets of the services, and list subsets of their attributes, depending on the audience. I work with up to eight views and there are potentially more. But there is only one set of services. I'm very clear on that, ITIL isn't.

I've listed broadly the same things as you, yes. But you use the phrase "Technology" in service names. That's not the service, it's only one part of how we deliver the service.

yes request catalogue is definitely a different animal. I'm talking here about service catalogue. Requests come later if you follow a top-down approach, or earlier if you follow a bottom-up approach.

I've never been entirely happy with "Application Services" as a name. it is a sop to IT folk who think that way. "Business Function Services" might be better. Communication is a technical capability we provide which underpins all business activities: it is not a business function in its own right as a hospital Labs or Wards function is. it belongs in Technical. One of the things we need to be careful about is granularity: a 300-service catalogue is useless. It needs to be something people can engage with. i try to create a catalogue with a few dozen services. Hence Communication, not breaking it down. We provide various mechanisms to allow users to communicate. period.

I'd love to upgrade those examples; it has been on my task list for a long time :(

Many thanks for your questions and feedback - you are bringing out good points.

Syndicate content