Deciding how to segment the service catalog and what table structure to use for an ITIL implementation can be quite a challenge. The default setup of the service catalog balances the following basic goals:

• Make it easy for end users (the customers) to know where to go to request what they need and to follow up on their requests.
• Make the back-end processing and workflows as simple and clear cut as possible for the technical users and approvers who must process the requests.
• Make the system easy for administrators to understand and maintain so that changes can be implemented for one kind of request without affecting how other records are processed.

The Service Catalog offers services to the end user that may be created in one of two tables:  Service Requests or Incidents.  From here the requests can easily be grouped into problems or converted into a change request as shown in the diagram.  The system is designed to make it easy to push requests from one place to another for further work.  For instance, multiple incidents can be linked to a single problem record and a workaround pushed from the problem into the related incidents, automatically emailing the workaround to the customers.

The arrows in the diagram above show the predefined conversion paths a request may take, if a technician believes it is appropriate: a service request can, with a click of a button, generate an Incident or a Change Request, or can be linked to existing incidents or changes. Likewise, an Incident can generate or link to an existing Problem, while a Problem can generate or link to a Change Request.  A change request may also cause an incident.

A Problem may be related to multiple Incidents and a Change Request may be related to multiple Problems, Service Requests, and Incidents. Naturally there are also relationships within each of these tables to Users, Teams, Configuration Items, and other essential components of the system.

Available Services and Request Types

Whether or not a particular group of users can request particular services depends on a few things:

• Their group permissions – for instance, our default internal end users cannot directly create a Change Request, while technical users can. 
• Which SLA Customer group they belong to and which business services and service offerings are included in all SLAs available to that SLA Customer group. 

Internal customers will submit Service Requests – which can include the purchase of items – to request a standard service, such as onboarding of a new employee or a request for a new software license.  They can submit an Incident to report a problem or an interruption to a business or technical service.   If merited, that incident may lead to the creation of a Problem and/or a Change Request by technical staff.

Service Requests, Incidents, and Change Requests may include a set of tasks that need to be completed before the request can be completed.  Service Requests and Change Requests can also include approval workflows prior to the work being scheduled.

Submission Methods for End Users

The system is designed so that end users can submit a request in one of three ways:

• By clicking on View My Service Catalog from the End User Interface (EUI).
  

  
  They can then choose a business service to drill down to the services included, where they see a button to create the appropriate record for the service:

  

• Create an Incident or Service Request directly and then choose the appropriate service from the service catalog once in the record.
  

  

• Select from a configurable set of quick links to create requests for specific services. This lets end users create service requests without the need to know which table is used to store and process the requests.
  

  

Service Requests vs. Change Requests

For some services, it may be unclear whether they should be offered through a service request or a change request. For instance, account provisioning, employee off-boarding or on-boarding, or simple application changes could go under either category. We like to use the criteria that changes that do not require approval are best handled in the service request table, while those that do require approvals or that require careful scheduling belong in the change request table. Approvals are available to both Service Requests and Change Requests, so the services can be configured accordingly. 

SLAs are primarily tied to service requests and incidents, with less weight given to SLA targets for change requests, since changes must often be carefully scheduled during maintenance windows. Thus if you are concerned with measuring turnaround time for standard services, they are generally best handled in service requests.