The Service Catalog

The IT service catalog provides customers with the ability to view and order IT services. 

At CIT, our catalog contains services that are available to faculty, students, alumni, and non-technical staff or IT professionals. The services we deliver support their ability to teach, learn, work, as well as the university’s mission. 

Requests for service arrive through the catalog by way of a service request form. When a form is submitted, it generates a ticket to the team that will provide the support or fulfill the request.

Individual services may have their own time to respond and resolve to requests based on their importance to the university’s operations and their service level agreements. 

The catalog is primarily organized for the customer. Service names need to reflect the value the service provides to the customer.

The service and its service offerings should represent the “whole package,” so that the customer isn't being expected to consider specific costs or risks associated with the business capability the service provides. This means avoiding listing out separate parts of the service, such as technologies, products, vendors, contacts, agreements, infrastructure components, support teams, support tasks, and similar aspects. One of the reasons why customers use outside services rather than doing something themselves is so they don't have to worry about this level of detail.

In the catalog, services and their service offerings are organized into top-level service categories. These categories are a logical grouping of services with similar capabilities. Categories help organize the many services offered by IT into groups that are easier to understand and sort through.

Each service in the catalog has a service record containing its service attributes. Attributes include:

• The service description
• Audience
• Benefits
• Costs
• Alias
• Who the service is available to

The Service Portfolio

The service portfolio is a comprehensive view of all services. This includes services that are still in development, in pilot, being phased out, retired, or internal-only services that aren't directly ordered or used by customers. To put into context, the service catalog is the customer-facing portion of the larger service portfolio.

The portfolio allows us to understand the costs associated with delivering a service. It also provides a way to look for value redundancy—offering the same value through multiple services—and review technologies to see if they need to be restructured or retired. 

Within IT ticketing systems such as TeamDynamix, the portfolio’s service taxonomy is used to classify support tickets. Classifications include incidents, problems, changes, and requests. This classification allows us to measure the costs associated with the support and management of services. Service decisions and activities can have the customer perspective in focus, and the data helps us see whether the services being provided to campus are fulfilling customers' current wants and needs. 

Some services exist only in the portfolio because they're application- or technology-based and operate behind the scenes to enable the delivery of customer-facing services. They're in the portfolio because they're still subject to service management practices, but are not in the catalog, because they're not visible to customers. 

What qualifies as a "service"? 

Services and their offerings are often subjective or abstract because they're based on what customers need from IT, and so are represented or “packaged up” in a way that delivers a complete capability to the customer. 

As an example, "printing" is a service. The activities CIT performs for it include provisioning, installing, configuring, and maintaining network servers. While these are essential actions, customers wouldn't consider them discrete services in their own right. 

When defining a service, focus on what delivers something of value to the customer. It can be ordered. It can be consumed. Since services represent capabilities, they are often generic, such as "printing" or "telephone." These services may have service offerings associated with them that are more specific, such as a local printer or network printer for the service of printing, or voicemail or desk phone for the telephone service. 

Service Naming

Services generally have a generic name that identifies the capability they provide. When there are multiple tools or use cases used to meet the needs of the service, those are expressed as service offerings.

Example 1:  Use cases or customer groups

Service    

• Service Offering 1: Academic Tool    
• Service Offering 2: Administrative Tool    
• Service Offering 3: Fundraising Tool  

Example 2: Using product names

Service  

• Service Offering 1: Service Tool (Brand name of first tool)  
• Service Offering 2: Service Tool (Brand name of second tool)  

From the perspective of IT Service Management, both approaches are valid. Example 1 is more "future proof" but applies more to if there are particular offerings with different use cases, needs, customers, or varying costs being charged to customers.   For example, you could have a free version of a tool available to students and a paid version for staff use. In theory, it could be the same product with different license agreements and charging models. In cases where the same product is used by multiple offerings, but they need to be tracked separately for cost, audience, or risk, the product name wouldn't be used in the offering, since it could apply to multiple offerings.