How To Create A Service Catalog

How to create a Service Catalog: Advice, Best Practices, Mistakes

Today I would like to share with you my experience of creating service catalogs for various companies. I hope some of my practical advice will prove helpful to you. My choice as an experienced consultant are on ITSM and ITIL frameworks, which are considered the best practices for service provision. And although these techniques were initially developed for IT sector, it's not an issue to adapt them for companies from other industries.

First of all, what is a "service" and where does its value lie?

On the face of i t, it's difficult to give a clear definition to a service due to the variety of its forms nowadays. As I see it, service is creation of value for a customer. A client does not have to possess any resource or bear responsibility when working with a service provider. Yet, if during their interaction a value was created, for example, a part of the production chain was outsourced, software was developed, goods were transported, mineral resources were mined, this can be rightfully called a service. When the value you provide meets or even exceeds client's expectations, this means the service provider has reached his goal.

There are two aspects that determine service value:

Utility — when the functionality of the service corresponds with client's needs (goods are transported);
Warranty — when the service conforms with the quality requirements (goods are transported on time and in the right way).

Service catalog and service portfolio — the same or different?

Service catalog is a centralized list of services that are currently available to customers (external and internal to your organization). As with individual services, it is necessary to pay extra attention to the value you want to provide through it. If you are not sure that kind of service can help clients or will be in demand at all, think twice before listing it in the catalogue. It is also worth considering the future promotion of the services while compiling the catalogue. Here is a case study proving the importance of the marketing component.

We worked with a small consulting company — one the best law experts in the region. Some of them specialized in business law and contracts. Some were the best customs support specialist in the region. A couple of workers were deeply knowledgeable in labor law. Others were engaged in mergers and acquisitions and legal support of start-ups. When the company made its service catalog, it contained several dozens of offers. They were proud they could cover the whole range of legal consulting services and hoped to quickly win the leading position on the market. However, after a few years they found out that it was nearly impossible to provide marketing and presale support to such a sophisticated catalogue. Clients left them after the initial contact. For example, startups preferred to work with less renowned legal firms that, on the other hand, specialized solely on startups. As a result, right conclusions were made and their service catalog has been revised and significantly narrowed down.

The process of service lifecycle support is called Service Portfolio Management. A service portfolio contains not only available services, but also the retired ones or those being developed. Over time some services lose relevance, become too complex to perform or undemanded. These are wake up calls, telling you that services need to be updated — at regular intervals or in connection with some events (for example, the release of a new version of the used tool). Even if there's a stable demand for the service, don't you relax — the service needs to be constantly revised and improved. In case the service proves undemanded or unprofitable, it's better to retire it.

Service: we see it differently

When a customer orders a shipment of goods, he sees this process the following way: he leaves a request (through a phone call or a request form at the web-site) and waits for the workers who come over to his address at the appointed time, pick the load and deliver the goods safely to the right address on time. This is the user request level.

It all looks different from the business level. The company is in possession of manpower and some resources (cars, computers, servers, electricity) — IT usually refers to them as components and infrastructure. Obviously, all this has some value. By applying the components mentioned above in the proper configuration, the company creates a service that brings value to the client. The company, in its turn, receives the added value.

There is also a production level.The workers' foreman receives a detailed description of the task: addresses, load volume and weight, contacts of the client and the recipient, information about the cargo (fragility, shape); there's a team of workers and a number of cars at his disposal. There is an operational manager who is also in charge of the service provision process. He monitors the content of customer requests, predicts their flow, manages resources and its availability). Having an understanding of how the service provided, he can quickly restore it in case of a failure or an incident.

Can such scheme be applied to software development? Yes of course.

Take the provision of "Access management" service as an example. A client would like to access the Service Catalog through a simple point of contact, select and order the service to change his access level (for example, to gain access to the corporate messenger channel). At the business level there should be an understanding of the cost of the service provided, the components involved, the infrastructure and manpower. The process level should have clear instructions and technical information for personnel and permissions to access the internal knowledge base and user requests to access customer data. The working process must also be described in detail, eg. working hours, breaks, staff qualifications.

One of our clients, a major Internet provider, provided the service of connecting new subscribers to the network via optical channel. The company implemented the Service Desk software for structuring and automating the subscriber activation process. However, clients didn't use the form on the website; instead, they continued to send email requests and call the service center. Many requests were lost and the workload on the staff was unbalanced, the planned automation wasn't realized, and the customers were getting nervous. Having analyzed user behavior, the company found out that the name of the User request was too complicated, and customers simply could not find it on the web site. The request form itself was also too complex, required an email to confirm user profile activation and contained too much marketing information; moreover, the user had to enter a lot of data manually (for example, the tariff plan). Apparently, potential clients found it was easier to write a short email or make a call. As a result, the application form was simplified and integrated with the CMDB system, technical data is now "pulled up" automatically, so there is no need to enter it manually for a client. What is more, they introduced an automatic user notification on their application progress.

To sum up, I would like to make some recommendations: when creating the Service Catalog don't to forget the basic principle of the ITIL framework, which is "make everything as simple as possible" (at least for customers). Also, do not forget to revise your service catalog for relevance and compliance with the corporate mission. Finally, consider the components involved and dependencies, and automate everything as much as possible.