Keep up-to-date with ITIL news. Low volume to-the-point bulletins...
ITIL in Practice from
How to produce a Service Catalogue
The official definition of an ITIL Service Catalogue is:
(ITIL Service Design) A database or structured Document with information about all Live IT Services, including those available for Deployment. The Service Catalogue is the only part of the ITIL Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services. The Service Catalogue includes information about deliverables, prices, contact points, ordering and request Processes.
Although ITIL mentions or refers to a Service Catalogue, little information is provided with regards to what it might contain. In this article we have taken the opportunity to provide detail of what could be considered for inclusion. We suggest that the Service Catalogue can be produced as a simple spreadsheet. We acknowledge that additional information could be included such as deliverables, prices, ordering and request processes, although this is dependant on how the Catalogue is to be utilized by the organization.
The Service Catalogue provides the ability to contain critical information in a central repository accessible by both the IT department and the Business. The information contained within the Service Catalogue relates to all Services provided by the IT department to the Business. The Service Catalogue is generic and can be applied across all platforms, environments or geographical locations of any organization.
Several vendors offer Service Catalogues that conform to what ITIL suggest and in some cases are able to offer additional features and functionality that may benefit an organization, it may be worthwhile reviewing what they have to offer.
Service Catalogue Definitions 
The following data elements are suggested for inclusion within the Service Catalogue, but are by no means exhaustive and one might expect data elements to be added or removed as the benefits and uses for the Service Catalogue are recognized.
The suggested data elements are:
  • Service Name
  • Service Description
  • Availability
  • Target Availability
  • Backup
  • Service Owner
  • Service Representative
  • Service Criticality
The suggested data elements listed above are now explained below.
Service Name
The Service Name should state the term(s) by which the Service is referred to by the Business community and also the term(s) referred to by the IT community. Clear distinction must be made as to which community the term is known by.
Simple as this may be, documenting the Service Name eliminates any confusion that may exist around the name or names of a Service. Often Service Names differ between the Business and the IT community. An understanding or translation of the Service Names is probably no more important than on the Service or Help Desk(s). A clear understanding ensures effective and efficient management of any incident or request that may be posed to the IT department.
Service Description
The Service Description should be written in easy to understand, simple, non technical terms that almost any person within the organization could understand. The Description should be at a very high level with no more than two or three lines at the most, ideally it should be written by a member of the Business community.
The Availability data should contain details relating to the availability of the service both in hours and days, stating any exceptions, for example: 07:00 – 19:00 Monday to Friday excluding Bank Holidays.
Critical periods for the Service to the Business should also be stated for example: last Thursday and Friday of each month and the last week of March (year end). Critical period information also assists Change Management with regards the authorization and scheduling of Requests for Change (RFCs).
If known, the number of Business Users who use the Service should be stated, this assists with understanding the potential impact of the unavailability of the Service. In addition it can focus the minds of the Support personnel within the IT Department and thus encourage a speedier recovery of the Service when unavailable and also ensure Changes are made at times which are acceptable to the Business i.e. with minimal impact and risk to the Service and Service Level Agreements.
Finally, if the information is not sensitive, consider including figures regarding how much revenue the Service generates for the organization, this can also assist in focusing the Support teams. In addition the cost of unavailability can be roughly calculated and reported upon in association with Service Level Management.
Target Availability
Consideration should also be given to including a target availability which the IT department is striving to achieve. Once again this should be reported upon and where the Target Availability is not being achieved Service Improvement Programs can be instigated.
The type of Backup together with its frequency should be stated, for example: incremental backups Monday – Friday and full backups on Saturday.
Service Owner
The Service Owner is the person within the organization who provides the funding for the Service – the person with the check / cheque book. In addition the Service Owner potentially provides an understanding with regards the level of Service currently being delivered and that required for the future.
Service Representative(s) 
The Service Representative(s) provide a focal point for communication between the IT department and the Business community. The communication should be two-way and allows the Business and IT to work together in partnership. Examples include the provision of regular updates to the Service Representative during major outages (major incidents), as well involvement in decision making from a Business perspective. The Service Representative would then be responsible for the dissemination of the status of the Service to other members of the Service community.
The Service Representative would also be included in the ITIL Change Management process, providing input into the assessment, authorization and scheduling of any Requests for Change (RFCs).
Ultimately, the Service Representative provides an invaluable bridge between the IT department and the Business community, the importance of this relationship should not be under-estimated.  Other titles could include Account Manager or Business Relationship Manager.
Service Criticality
The criticality of the Service is determined by the Business. The following list is a suggested structure for determining the ‘service categories' and corresponding criticality of organizations services, for definitions of the categories please refer to the section below entitled ‘Standard Service Definitions':
  • Mission Critical
  • Business Critical
  • Business Operational
  • Administrative Services
In addition it may be beneficial to ask the Business the sequence in which the Services should be recovered should a major disaster occur. The Businesses knowledge of revenue generation, customer impact and marketplace visibility is invaluable when determining the recovery sequence. The feasibility of the recovery sequence may need to be discussed with the IT community.
Standard Service Definitions
The service categories used in the Service Definition Matrix are based on the standard industry definitions given in the following sections.
Mission Critical
A mission critical service requires continuous availability. Breaks in service are intolerable and immediately and significantly damaging. Availability required at almost any price.
Key characteristics of this type of service are:
  • Generates revenue: customer orders are booked through the service
  • External customers are direct users of the services
  • Underpins other services
The typical impacts of a service outage are:
  • Immediate reduction in revenue
  • Damaging for the company's commercial reputation and credibility
  • Long-term outage threatens bankruptcy
An example of a mission critical service is a financial trading application of a bank or financial institution.
Business Critical
A business critical service requires continuous availability, though short breaks in service are not catastrophic. Availability required for effective business operation.
Key characteristics are:
  • Indirectly affects revenue generation and may prevent collection of revenue
  • Supports customer facing activities
The typical impacts of a service outage are:
  • Inability to collect revenue efficiently
  • Long-term outage can significantly reduce company cash flow
An example of a business critical service is the customer billing application.
Business Operational
Contributing to efficient business operation but out of direct line of service to customer.
Key characteristics of business operational:
  • Internal users only
The typical impacts of a service outage are:
  • Reduced efficiency and increased cost of operations
An example of a business operational service is enterprise messaging.
Administrative Services
Services on the level of office productivity tools, required for business to operate. Failures are undesirable but do not affect customers and can be tolerated a little more. Cannot justify extreme additional expenses for higher availability.
Key characteristics:
  • Internal users only
The typical impacts of a service outage are:
  • Reduced individual performance and productivity
Examples of administrative services applications are desktop applications.
We hope you found this article interesting and of value, if you have any comments, practical experience or advice to share then please contact us.


2010-06-25 by "pete.hipkiss"

Congratulations At last someone who has defined a Service Catalogue in a concise and practial way

2010-10-18 by "peter.hodgetts"

Very helpful. Thank you.

2011-01-06 by "cfp"

I find this article extremely good, consice, consistent and coherent. A good usable interpretation of ITIL. Thanks

2011-01-19 by "sachinsalvi"

Service catalouge is prime important from Service Management standpoint and your points on how to achive good catalouge are praise worthy.

2011-02-25 by "kafshar"

Very helpful. Thank you

2011-03-31 by "alyke11"

That's good work. Thanks for the depth.

2011-04-05 by "amandabarkus"

Thank you for the article. I would have liked to see some information on how to define a service, maybe with a set of questions that one can answer to decide if an application should be considered a service on its own or not. For example, a trading system is a service but a small program that translates messages from one format to another may not be a service on its own (could be grouped with some other service). This type of basic info would be really valuable to your community.
Reply on 2011-05-09
Many thanks for your enquiry. It is an interesting question that you ask. It is worthwhile establishing under ITIL what the definition of a 'Service' is... the definition states:

A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.

Determining what constitutes a service within your organization will ultimately require sitting down with the various 'Business' and / or 'Customer' representatives and simply asking the question. It is quite an experience obtaining the Business or Customers view of the service(s) offered by IT - it can be humbling seeing services offered from those who receive them.

In our experience we have found following on from the formuation of a 'Service Catalogue' is the establishment of Service Level Agreements. It is at this stage that we find that 'critical' elements of a service are identified and need to be documented. On one occassion we met with the Finance department representatives who stated that on the last working day of each month the availability of a specific printer was critical to the organization as a whole. The 'configuration item' details were captured and the Configuration Management System (CMS) was updated to reflect the criticality of the printer at specific times. The Service Desk were then able to raise appropriate 'severity' incidents thus ensuring the appropriate response and support were provided.

The printer may well have been perceived as part of the Desktop service yet the importance overlapped into the Financial service itself, yet without liaising with the Business the criticality of the printer may never had been known.

There will inevitably be components of an overall service that are critical to certain customer or business communities, needless to say understanding who will be effected is very important. Working with the 'Key Service Contact' will assist with defining exactly what constitutes a 'service'.

2011-04-13 by "fredrik.m.lind"

The information contained within the Service Catalogue relates to all Services provided by the IT department to the Business. Sounds promising but reading further I get the impression that it only covers IT systems ?
Reply on 2011-04-29
The Service Catalogue has been written to refer to IT systems but incorporating Business Services should not be an issue as the approach is flexible.

We would simply add the Business Services and perhaps for simplicity, using a spreadsheet, colour code such services as necessary.

Secondly review the headings to ensure they are still applicable for your Business Services requirements.

We have used such an approach whereby a Service Catalogue is produced incorporating services that are provided by individual regions.

2011-06-01 by "bannyk.76"

It would be helpful if some templates on Technical Service Catalog and Business Service Catalog are provided.

Secondly the way IT sees a service and from business stand point are completely different. So if you could provide a mechanism on how you can align business service underpinning with IT and produce a Business service catalog would be helpful.

2011-11-08 by "andy_peters"

This made an interesting read. I hope to meet with our business reps soon, so should be interesting!

2011-11-23 by "neil"

Why is Service Catalogue mentioned in detail in Service Strategy (ITIL foundation exam book) when it is Service Design?
Reply on 2011-11-28
I suspect that the Service Catalogue is stipulated in Service Strategy as it is a mechanism to capture details of 'services' that may very well not come to fruition, in other words strategically they are captured as an entry but due to events and direction of the organization may become superfluous and therefore do not enter the 'Service Design' phase.

It might be worthwhile taking a look at the following article as it probably explains things a little better:

ITIL V3 Service Portfolio and Lifecycle

Please come back and share your thoughts.

2012-05-04 by "ralf.hemmers"

I wonder if you would define services that are delivered with the request fulfilment process in the service cataloque and if you would have "Billing enquiries" and complaints defined as services that are delivered with the request fulfilment process?
Reply on 2012-05-08
We would expect all billing enquiries and complaints to be fed through the Service Desk whom provide the Single Point of Contact (SPOC) for both enquiries and also complaints.

2012-08-07 by "ami"

Very efficient and informative article, I would suggest to add:

1. Price (Monthly and setup fee)

2. SLA time frames

There is an interesting question:

those the SLA level is a property of each service or should it be separated to different services (one service can be offered in different SLA levels).
Reply on 2012-11-15
Many thanks for your compliment and also valued input. Apologies for the delay in responding to your questions.

The Service Catalogue has been explained as perhaps the fundamentals to include. nevertheless the additions suggested could also be included.

In answer to your question which we have hopefully understood we have the following comment:

In our experience we have often written Service Level Agreements (SLAs) and referenced the Service Catalogue or added it as an appendix of the SLA. The SLA may apply to a specific group of customers who for instance use one particular service or it could apply to a specific customer who uses a set or portfolio of services.

Care should be taken when including pricing within the catalogue as some customers may which this information to not be widely available. We would recommend checking with the customer before including. Secondly, the Service Catalogue should be easily accessible to all as it provides a single point of reference and eradicates potential confusion.

So based on your customer base, whether they are internal or external customers you wish to use the service catalogue for general use, but possibly provide a separate version which contains pricing to aid with discussions with those stakeholders involved with budgets and paying for services.

It would be interesting to have your thoughts on this matter and potential the direction you may or have taken.

2012-11-26 by "hi_lizm"

I would put some of these elements, for example backup in the SLA, and not the Service Catalogue - please comment.
Reply on 2012-11-30
Many thanks for asking the question. Yes you can place the 'backup' into the SLA and it can be measured and reported upon. What the Service Catalogue is achieving is conveying to a wide audience just when the backups take place raising awareness and also understanding. It is also publishing the 'behind the scenes' activities that IT provide in support of the business.

2013-03-16 by "nanalekgau08"

Does Service catalogue have to be limited to be developed on an Excel spread sheet or can I also use Word as a start, while still investigating other technologies ?
Reply on 2013-03-18
Many thanks for contacting ITILnews.

The Service Catalogue can be produced in whatever media that works for the organization in question.

I have produced the Service Catalogue as an Excel spreadsheet which was attached as an appendix to a Service Level Agreement. I have also created a Service Catalogue in Word format that was a separate document in in its own right that was referenced by a Service Level Agreement. Also consider having the agreed Service Catalogue accessible via an organizations intranet.

So as you see it does depend on the audience who are going to use the Service Catalogue. It would be interesting to hear if any other formats having been used successfully.

2013-03-23 by "Kristathompson"

We are developing our Service Catalogue using Microsoft SharePoint 2010 which has robust capabilities for displaying certain content using customizable groups of people or Active Directory users and groups. The ability to incorporate automated workflows to route services as they are being developed (ie Service Portfolio) to support a repeatable and consistent process. Taking advantage of InfoPath allows us to provide a web look and feel to the service attributes.
Reply on 2013-03-26
Hi Krista, This is brilliant. Many thanks for sharing this information regarding an innovative approach to producing a Service Catalogue, which I believe 'brings it to life' making it more productive and an invaluable tool to your various internal customers of the organization. Thanks again

2014-01-15 by "deallen"

I like your suggested template ... however it assumes that a service = an SW application.

We support 3 quasi-autonomous Bus. Our services are arranged in a 3 tier hierarchy:

1) families of services

2) lines of service

3) the app service.

For example:

Family: Prod & App Dev Services

Lines: Doc&Localization, Training, Config&Build, Quality, RequirementsMgmt, and TaskMgmt.

Services: Each line has 1 - 6 app services.This structure let's us analyze costs/benefit at each of the three levels: Familly, Line, Service.

2014-07-24 by "bill.cooper"

Nicely Done!!

2015-05-27 by "mannk"

I also found this very helpful. I am trying to bring my department along within ITIL and want to check my perception. Besides the specific categories suggested, the simple suggestion that there is a lot of room for interpretation is very helpful.

2015-10-15 by "sophie.reynolds"

Very informative. One comment - examples please!
Reply on 2015-10-16
Can any readers share any examples for us to include here ?

2015-11-11 by "larsholdgaard1"

So where is the downloadable service catalog template?
Reply on 2015-11-12
We feel we have provided all the necessary information for the reader to produce their own template either in a spread sheet or as a text document. We would welcome any examples which our ITILnews community are prepared to share. Please only the template and no organizational data.

2016-02-08 by "joe.dsouza"

For the most part it is a fairly well written article but there are areas where it could be reviewed, revised and republished - for e.g. the author has included comments about "Scope" within "Availability".

The second paragraph of "Availability" should have been under discussion under "Scope".

If I were to rewrite this, I would include "Scope" as a separate sub topic and discuss scope related discussions under that...

Also under "Availability" the last paragraph discusses "Operational Costs". Wrong place. And no separate space for "Operational Costs".

There are other smaller improvements I could suggest but those are minor and probably not worth sweating over...

2016-03-24 by "bryan.gervais"

Nicely written! Some slight differences I use but you cover the main areas very well. I'd only add that when writing a Service Catalog it is important to know your audience. A Business Service Catalog would be written in a less technical language than an IT Service Catalog and I always suggest to have both. Also, it should be written / designed in such a way that it can nicely be encoded into an ITSM Tool and be inline with Internal and External Governances. Also, having a strong understanding of the interfaces to other ITIL Lifecycles and their respective processes is also helpful in getting the design right the 1st time.

2018-09-11 by "ekralicek"

Nice job. I would suggest explaining Service Level Offerings (service catalog) in relationship with Service Level Targets (OLAs) and Service Level Requirements (Customer). The service catalog must represent offerings that are supported by OLAs and help to drive Customer expectations in fulfilling the service level requirements.

2021-09-30 by "s40359"

I think this is really helpful but something that could make it better is a detailed approach to the benefits and drawbacks of an IT service catalogue.
There are 5 comments awaiting user validation. There are 7 comments awaiting publication.

Please submit any comments you have about this article.

Your feedback will help add value to the content for other visitors and help us develop the content for the benefit of all.

You will need to provide and verify your e-mail address but your personal information will not be published or passed on to others. To identify each post we take the part of your email address before the @ sign and use that as the identifier, so if you are your post will be marked "by john.smith".

NB: We respond personally to every post, if it calls for it.

If you prefer to respond without posting your comment please use our contact form.

Click the REVIEW button below to preview your comments.

Tags; ITIL Service Catalogue, Service Catalogue, ITIL Service Portfolio, Requests for Change,ITIL v3,ITIL Service Design
This article has been viewed 301832 times.
NB: This page is © Copyright and / or the relevant publishing author. You may copy this article only in it's entirety, including any author bio and / or credits, and you must link back to

Keeping up-to-date with ITIL...

Keep up-to-date with ITIL news. Low volume to-the-point bulletins...