Ken Turbitt Blog
Aidan Lawes Blog
Paul Gostick Blog
Dr Jenny Dugmore Blog
Shirley Lacy Blog
Alim Ozcan Blog
Juan Jimenez Blog
Ian Clayton Blog
Nas Ozcan Blog
Aidan Mills Blog

Quarterly Report on Global Venture Capital Trends
Global venture capital market achieves new quarterly record with over US$69.8 billion invested...

Ten Strategic Technology Trends for Government
Technologies that enable new service models for digital government must be at the top of the list for government organizations as they prioritize technology investments...


The Robots are Coming: Are CEOs Ready for the Era of Automation?
CEOs agree that robotics is going to make their companies more efficient, with 94% of those who've already adopted robotics saying that it's increased productivity in their business...


The 2015 Chief Digital Officer Study
More companies are appointing a Chief Digital Officer to join their C-suite - but are they doing it quickly enough?...


18th Annual Global CEO Survey
The United States has overtaken China as top target for growth for the first time in five years...

31 March 2010 | Ian Clayton Blog
Send to a colleague | Add to MY ITP

Dead Animals, Pizza and Five 'Service Catalog' Myths
This week Ian looks at five common myths related to the service catalog and guides you on a path to delivering a successful list...

  Ian Clayton

Recently, I had cause to call my local council and request a dead animal be removed from the driveway.  The local government office’s answering system directed me to a website and their recently implemented ‘Citizen Request Management’ system. 

There, I was presented with a categorized list of available help, and a service request form with three mandatory fields.  The titling was intuitive enough that I was able to easily find and select my specific request.  All they needed to know was my type of problem and the approximate location (which was translated into a global positioning system pinpoint location).  That was it. 

Next day, the animal was gone.  I presumed as a result of my request.   At no point did I have to speak with a person, nor did I have to disclose any personal information.  I didn’t even have to describe what type of animal; presumably they offer a one size fits all takeaway service.  Crude - but effective.

Between requesting the removal of the dead animal, and its actual removal, I ordered pizza online, checked my bank balance, refilled my wife’s prescriptions, ordered three books, booked a flight to visit a client, and located and reserved a hotel room using a well known online mapping system. 

Such is life for many of us in today’s wired world.  Information Technology, or ‘IT’ truly has become invisible technology.  Service is at our fingertips, and we are a generation that has succumbed to the 3-button rule – ‘select, select, and submit’.  We are surrounded by service catalogs. 

The service catalog emerged in 2009 as one of the most treasured possessions of an IT Service Management (ITSM) project, and this year we have seen the vendor community collaborate to begin the process of defining a common working specification for service catalog management software. 

The Service Portfolio and Catalog Language (SPACL) Consortium, as the name implies, couples the service catalog with another predominantly ITIL V3 artifact – the service portfolio, and explains that a significant reason for failure to develop either properly (from a practitioner or client perspective), is the lack of standards. 

I would like to share with you five common myths related to the service catalog phenomena, using extracts from my upcoming book ‘Outside-In Service Management’.

Myth #1 – You need one

You don’t, not unless you wish to operate and be performance managed as a service provider organization (SPO).  Service provider organizations need to explain to existing and prospective customers the value proposition of the services they offer, by describing how those services help the customer achieve their desired results, and why they should choose their service ahead of any competitor’s.

Given the investment and dependence today of the enterprises on information technology, it makes increasing sense for an IT organization to publish such a catalog of services, to describe what they do, and can do, for each customer community, subject to reading myths 2 through 5.

Myth #2: A service catalog is all you need

The service catalog is but one element of an intricate service management system designed to encourage requests for service, influence service level negotiations, shape expectations, while marketing the value proposition.  The catalog resides on a portal acting as an authorized and often secure service access point and is typically intermingled with service requests and related information.

Behind the scenes a combination of content management, subscription management, request and workflow management, touchpoint management, shopping cart, sticky reward systems and the service provider organization itself, cooperate as part of a holistic service management system. 

A service catalog helps manage the service encounter, represents key moments of truth, and is fundamental to managing the overall customer experience. 

Myth #3: A service catalog can be built from the inside-out

A service catalog is one of the key marketing tools of the service provider organization and should be designed with the interests of each customer in mind. In the marketing universe, the service catalog is analogous to the product brochure.  In fact it may span as varied a format as a single page to a complete telephone book sized directory depending on the need.  Organizations like Victoria Secret issue a specific subset of the overall catalog on a regular basis to customers, with the contents shaped to buying patterns.

Each service is ‘positioned’ in the mind’s eye of the consumer. Catalog entries are formed around a ‘positioning statement’, containing a brief description of the benefit to your target customer, what you do differently from your competition, and why they should believe what you say. 

Positioning statements also have a competitive frame of reference, including points of parity (POP) with competition and points of difference (POD) – all marketing 101.  A good positioning statement helps the consumer understand the goals and successful customer outcomes a product or service helps them achieve, and how it does this in a unique way.  As such, the catalog entries must use the natural language of the target customer, and the provider organization must be prepared to offer many service catalog faces, one per community if need be.

The positioning of a service follows closely behind the efforts to segment the overall market based upon common needs, wants or problems, and the targeting of specific segments.  Professional marketers would recognize the acronym ‘STP’ – segment, target and position. Everyone in the provider organization should understand the positioning and use it as context for making decisions.

So, the development of a service catalog cries out for marketing expertise, just as that of a configuration management database (CMDB) requires the skills of a database analyst, and should be approached from the outside-in. 

Myth #4: A service catalog is where you start

Its not, a service catalog is likely where you end up after walking in the customer’s shoes a while.  The most pragmatic starting point is individual service requests, listed and then categorized in customer language so they can be intuitively used according to the ‘3 button rule’.

Search on ‘311 service request’ and explore how the non-IT realm has successfully developed service request catalogs.  Check out the service providers you use online, your bank, the local pizza parlor, and notice how few actually list services.

Working at the request level also makes it much easier to deploy and ensure the organization receiving the request is able to respond adequately, or review their response and improve upon it on a case-by-case basis.  Keep it simple - one customer community, one scenario, one request, one workflow, one commitment from a service level perspective, one catalog entry at a time.

Also note that common families of service requests are optionally bundled into categories or groupings for a reason, forming the first embryonic definition of a service.  Services are also a deliberate bundling of requests to enable upsell, and this decision demands you understand the specific needs of your target customers – back to the marketing ‘STP’ mantra.

Myth #5 ITIL V3 offers plausible ‘best practice’ guidance

Unfortunately it does not.  Even ITIL® Version 3 demonstrates dramatically it is just beginning its journey of learning the role of a service catalog in a service management system.  The following observations are extracts from my ‘How to Decipher the ITIL® Code’ program, and are contrary to what is commonly suggested by some when referencing ITIL:

  • ITIL does not suggest a service catalog should be created using terms understood by a specific audience, nor that it be the basis for service level negotiations;
  • ITIL states “customers often have a greater clarity of what they believe a service to be” – they do not, customers typically work at the request level and are at best service challenged or agnostic;
  • ITIL compounds the previous statement by adding, “a good starting point is to ask the customer what services they use” – instead, ask them what they do and how you can help, it is unlikely customers actually know what IT services they use, especially if you have yet to actually build and publish a service catalog;
  • If that were not enough, ITIL pushes on and adds, “… The service catalog can also be used for performing a business impact analysis (BIA)”.  Those understanding how BIAs are performed and by whom, and why will recognize the foolhardiness of this suggestion. In fact the reverse is likely more true, the output from BIAs will help the development of a service (request) catalog;
  • No connection is made in ITIL between the service catalog and service level agreements.  What connection there is, is made between request fulfillment and individual requests and SLAs in Service Operation;
  • ITIL does not require a catalog to be ‘actionable’, nor does it even use the term.  As such there is no requirement by ITIL for a service catalog to be integrated with a service request or request fulfillment process.  In fact the Request Fulfillment discussion in the Service Operations book specifically suggests a menu-driven web interface and selectable list of requests;
  • ITIL does not contain the concept of a service request catalog.

And the list goes on…


Frankly I am perturbed that in today’s economically austere climate there are some in the ITSM space that are encouraging client organizations to develop critical customer facing artifacts, such as the service catalog, from an inside out perspective.  Worse still, often in the absence of the lessons already learned by the business and surrounding us in our daily lives, instead favoring maturing framework centered concepts.  Note - inside-out initiatives fail the customer – period.

The path to a successful service catalog leads through a walk in the customer shoes, the incremental development over time of a service request catalog, and being led all the while by an experienced marketing or product management professional.  At the core of any service management initiative should be management of the customer experience, maintaining an outside in perspective, targeting customer satisfaction, loyalty, advocacy, and a lower cost to providing service.  

Any feedback and comments are always welcome!!   

(ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.)

Ian Clayton Email to a colleague | Add to MY ITP

terms & conditions