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…

How to Provide Support for VIPs

One of the outcomes of IT Service Management is the regulation, consistency and predictability in the delivery of services.

I remember working in IT before Service Management was adopted by our organisation and realising that we would over-service some customers and under-service others. Not intentionally but we didn’t have a way of regulating our work and making our output predicatable.

Our method of work delivery seemed to be somewhere between “First come first served” and “She who shouts loudest shall get the best service”. Not the best way to manage service delivery.

Chris York tweeted an interesting message recently;

It’s a great topic to talk about and one that I remember having to deal with personally in previous jobs.

I have two different views on VIP treatment – I think it’s a complex subject and I’d love to know your thoughts in the comments below.

if your names not down you're not getting support
if your names not down you're not getting support

The Purist

Firstly IT Service Management is supposed to define exactly how services will be delivered to an organisation. The service definition includes the cost, warranty and utility that is to be provided.

Secondly, there is a difference between the Customer of the service and the User of the service. The Customer is characterised as the people that pay for the service. They also define and agree the service levels.

Users are characterised as individuals that use the service.

There are loads of great analogys to reinforce this point – from local government services that are outsourced (The local Government is the customer, the local resident is the user), to restaurants and airports. The IT Skeptic has a good discussion on the subject

It’s also true to say that the Customer might not also be a user of the service, although in organisations I’ve worked in it is usually so.

This presents an interesting dilemma for both the Provider and the Customer. Should the Customer expect more from the service than they originally negotiated with the Provider? I think the most common example that this dilemma occurs is end-user services – desktop support.

The people that would “sign on the dotted line”for the IT Services we used to provide would be Finance Directors, IT Directors, CFOs or CIOs. Very senior people with responsibility for the cost of their services and making sure the company gets a good deal.

Should we be surprised when senior people that ultimately pay for the service expect preferential treatment? No – but we should remind them of the service warranty that they agreed would be supplied.

Over-servicing VIPs has to be at the cost of someone else – and by artificially raising the quality of service for a few people we risk degrading the service for everyone.

The Pragmatist

The reality is that IT Service Management is a people business and a perception business, especially end-user services.

People call the Service desk when they want something (a Request) or they need help (an Incident). Both of these are quite emotional human states.

The performance and usability of someones IT equipment is fundamental to their own productivity and their own success. It feels very personal when your equipment that you rely on stops functioning.

Although we can gather SLA and performance statistics for our stakeholder meetings we have the problem that we are often seen as being as good as our last experience with that individual person. It shouldn’t be this way – but it is.

I’ve been to meetings full of good news about the previous months service only to be ripped to pieces for a request submitted by the CEO that wasn’t actioned. I’ve been to meetings after a period of general poor service and had good reviews because the Customer had a (luckily) excellent experience with the Service desk.

Much as we don’t like it prioritising VIP support it has an overall positive effect when we do.

The middle ground (or “How I’ve seen it done before”)

If you don’t like the Pragmatist view above there are ways to come to a compromise. Stephen Mann touched on an idea I have seen before:

Deciding business criticality is obviously a challenge.

In my previous role, in the advertising world, the most important people in an agency are the Creatives.

These guys churn out graphical and video content and work on billable hours. When their equipment fails the clock is ticking to get them back up and running again.

So calculating the financial cost of individuals downtime and assigning a role is a method of designating those that can expect prioritised support.

As a Service Provider in that last role our customer base grew and our list of VIPs got longer. We eventually allocated 5% of each companies headcount to have “VIP” status in our ITSM tool.

I think there are ways to write VIP support into an IT Services contract that allows the provider to plan and scale their support to cater for it.

Lastly, we should talk about escalated Incidents. This is a more “formal” approach to Service Management (the Purist would be happy) where a higher level of service is allocated to resolving an Incident if it meets the criteria for being escalated.

When dealing with Users it is worth having a view of that persons overall experience with the Service Provider. If a user already has one escalated Incident should she expect a better service when she calls with another? Perhaps so – the Pragmatist would see that although we file each Incident separately her perception of the service is based on the overall experience. With our ITSM suite we use informational messages to guide engineers as to the overall status of a User.

Simon Morris
Simon Morris

In summary…

I think everyone would agree that VIP support is a pain.

The Purist will have to deal with the fact that although he kept his service consistent regardless of the seniority of the caller he might have to do some unnecessary justification at the next review meeting.

The Pragmatist will have to suffer unexpected drain on her resources when the CEOs laptop breaks and everything must be focussed on restoring that one users service.

Those occupying the middle ground will be controlling the number of VIPs by defining a percentage of headcount for the Customer to allocate. Hopefully the Customer will understand the business well enough to allocate them to the correct roles (and probably herself).

The Middle Ground will also be looking at a users overall experience and adjusting service to make sure that escalated issues are dealt with quickly.

No-one said IT Service Management was going to be easy!