The Service Portfolio table holds all of the individual service offerings related to a business service - the individual records in this table are called Services. 

It is the main source for the detailed ITIL Service Catalog. It holds a record for each service that may be offered to end users or technicians through the service catalog. All services offered by the organization to end users should be managed here and this table's workflow is used to manage the on-boarding process for a new service. Each service is offered through a different request type, such as a Service Request, Incident, or Change Request. Each service is therefore associated with one of these three tables, and this association is defined in the Services field "Request type."

Presenting Services to Customers

There are several ways the system can be configured to enable users to create a request for a particular service. Whichever method is used, users will only see the Active or In Review business services and service offerings for which their SLA customer group has an active SLA. 

The system comes with Corporate SLAs that cover all users and that are linked to most of the default services, but each service may have specific SLAs available to only one set of users. 

Whenever customers interact with the services or the service catalog, they only have access to the services defined as available to their SLA Customer Group. For technician users, their permissions allow them to view all services, including those that are not yet active. When submitting a request, technicians are still limited to selecting from services that are Active or In Review. Since the system filters the services a customer can view, there is no need to create a specialized catalog for each customer. Instead, customers in different SLA customer groups automatically see their appropriate services based on their own linked SLAs.

Our default End User Interface demonstrates the main three methods by which customers can access services and create requests and incidents.

Business Service Catalog Drill-Down

The first method for presenting services is to use the Service Catalog view of Business services, which allows the user to view the service offerings within a business service and to click the Create Request button without knowing in advance whether the request will become an incident or a service request. In this method, the user clicks on the View My Service Catalog link to see the personal service catalog. This opens a view of the business services with a row for each authorized business service.

The My Service Catalog screen in the end user interface, with the 'Desktop Hardware' service highlighted.

Now the user can click on a particular business service, for instance, Desktop Hardware, to view more about it and to see the individual service offerings. From the list of service offerings, the user can click on the linked service to view more information about the service offering, or they can click on the Create Request button to create a new request with the business service and service prepopulated.

Incident screen showing the Business Service 'Desktop Hardware' and Service Problem Type prepopulated.

Preconfigured Hyperlinks for Specific Services

A second method for presenting Business Services is to create links to create requests for the most popular services, or the services that are available to all users. This approach is represented by the Quick Links section on the interface.

Clicking one of the Quick Links open a new Service Request or Incident with the service and business service prepopulated. This simplifies services for users since it takes only one click to open the request. However, if your service catalog is large with many offerings, it is more difficult to set up and maintain.

Creating New Incidents or Service Requests Directly

Alternatively, users may create a new Service Request or Incident directly. To do this, click the relevant link for 'Create a Service Request' or 'Create an Incident,' then select the business service and service.

New Service Request screen, showing required fields Summary, Business Service, Service, Description of Service, Special Instructions, Service Approval Required, and Impact.

This works best if the users already know which kinds of requests are Service Requests and which are Incidents. If they do create a record in the incorrect table, staff can convert from one record type to the other.

Adding Specialized Catalogs

You can make specialized catalogs available that find any subsets of services based on search criteria or fields in the Services table. The end user interface shows a second service catalog, Purchase Catalog, that displays all services that relate to a purchase.

Purchase Catalog link, under the View My Service Catalog link in the End User Interface.

If users click on this item, they see those specific services and can create a request directly.

IT-Only Services

Technical users who use the power user interface have additional options when creating requests. They can go directly to the appropriate table in the left pane to submit a request, or they may also use the Service Manager home page and click on a link to their own service catalog. In either case, they will see additional services that were not available to customer users, such as IT Infrastructure change, based on their own SLAs and group permissions.

Showing all Services for a Customer

Within each user record, a related table shows all the services that customer can access. In addition, reports can show which services were actually used by which customers. The report: All Services by Submitter on the Service Request table shows the services actually used by each customer.

Showing all Customers for a Service

It is possible to review the customers for whom a service is available in a few different ways. Services are linked to one or more SLA customer groups, and users are associated with those groups. So, the recommended way to view customers for a service is from the service record, and then through the linked SLA Customer Groups. Clicking on an SLA Customer group such as the Gold / Executive group shows the SLA Customer Group record. In the SLA Customer Group record, the Related Info tab shows all the users in that group.

Alternatively, you could add a field to the Service record that shows a table view of all users in the linked SLA customer groups.

SLA Customer Group record highlighting the Related Info tab and linked customers.

Service Record Layout

We have created several sample services. Naturally, your organization will want to create its own services, delete many of our sample services, or change the associations we have made for those services. For instance, the on-boarding of new employees is currently managed through the Service Request table under the Service New Employee Setup. Some organizations may prefer to manage new employee setup through the Change Request table instead. Making this kind of change is a matter of modifying the service record and changing the field called Request Type to point to the desired table.

Since the Service Catalog is the backbone for many ITIL processes, the Services table has several special fields that are pulled into the corresponding request to enable automation, escalation, and special field visibility and dependencies based on the type of service.

Details Tab

The first screen displays key details about the service. The Description of the service and the Special Instructions are shown to users when they submit a service request or incident to provide them with more information about the service.

The Attached file fields such as the Supporting Service Business Case and Service Design Package can hold supporting documents about the service, while the Service Warranty field can be used to provide further information about the expected turnaround times. The Service Criticality field represents the value of the service to the business.

Additional fields define the default team to be assigned to the request and the escalation team, as well as whether the service is billable, and if so, based on what criteria. The Auto-Assign to Responsible Team determines whether the service responsible team takes priority over the CI Responsible Team, if a CI was selected for the request, when assigning a new request. If yes, then the service team is assigned, if No, then if there is a CI and it has a responsible team defined, that team will be assigned to the request.

The Level 2 Escalation Team is automatically assigned to a request or incident when the SLA is breached, and is notified both before – at the warning interval – and after the SLA breach.

Costs for Services

Some services may be billable, and the system supports four different cost models by default: Fixed for the Service, Based on Items Purchased, Based on Task Costs, or Based on Time Spent.

Depending on the cost model, the cost information is entered in the service itself. For values of Fixed for the Service it is entered directly. For Based on Task Costs, the task templates will have values that are totaled. For Based on Time Spent, it is compiled by totaling the time spent on the request, while for Based on Items Purchased, it is the total cost for items purchased as part of the request. 

When a service request or incident that is billable is completed, the Total Cost in that record is populated automatically by the system based on the entered data and the service's cost model. Reports for billable service requests and incidents can be used to export cost information to an accounting system. A Cost Center field in the request tables allows the submitter to select the appropriate cost center that should be billed for a given request. Cost center values are held in the Cost Centers table and can be modified by importing your own values there and deleting the default values.

The cost fields are only visible when setting up a service if the ITIL Functions table record for Service Costs has a Yes value in the Function Turned On field. If not, those fields will be hidden wherever they appear.

SLAs / OLAs / Priorities Tab

This tab holds information about the available SLAs and OLAs for this service. The links to the service are generally made from the SLA or OLA table when those records are created and their scope defined. A service may have multiple SLAs linked to it, and the SLAs are applied to a request in priority order, described more fully in the Service Level Management section. 

Service level requirements are also held in the SLA table and that is where the SLR is negotiated and defined. For a service that is being planned, the SLR may be linked to that service to provide information on the requirements that are being negotiated. Once that SLR becomes an SLA, it would typically remain linked to the service as it goes live.

An example of a service for Quickbooks support with both a special SLA and an OLA.

Note that the view of the SLA and Underpinning Agreement can show the percentage of breached agreements and/or the number of open and breached requests. The next section on the SLAs / OLAs / Priority tab shows the Priority group used for the service and the available priorities for that group.

Priorities Available. Priority Group and Priority Matrix fields, with a list of Impacts and Urgencies in the priority matrix.

The SLA and OLA sections on the form will be hidden if the ITIL Functions for SLA or Underpinning agreements are turned off. Specialized priority groups can be created to provide a particular service with its own impact, urgency and priority values as needed. See Impact, Urgency, and Priority Management for more details on how this is done.

Approvals and Tasks Related to Services

Some services may have associated approval workflows or standard tasks or task workflows. These options are available from the additional tabs in the service record. Approvals and tasks are available out of the box for both Service Requests and Change Requests, while tasks are also available for incidents.

Approvals for Change Requests and Service Requests

There are three options for how to handle approvals for a change request or service request, shown in the Approval Generation Method drop-down below: using a predefined approval workflow, manually created ad hoc approvals, or both. For a Predefined Workflow Only, the user will select from existing approval workflows related to change requests. If none yet exist, they can use the button to create a new approval workflow on the fly.

If the user selects Manually Created in Request Only then no further information is needed in the service record, and they will be able to add the approvals manually within the individual request.

Approval View in the Change Request or Service Request

The selections made in the Service will result in different options appearing within the Change Request.

In a request based on a predefined workflow only, the user will see the workflow listed and a button to generate the approval records. If the user has permission to edit the Approval Workflow Title field, they would also be able to change to a different workflow as needed. If both predefined and manual approval creation are permitted, the user will see an additional checkbox, Create Approvals, that can be expanded to add one or more ad-hoc approvals. If only the manual approval creation is defined, then the user will just see the option to Create Approvals and will add any approvals needed.

 Note that if the Approval Required field in the service has a Yes value, at least one approval will need to be created and approved to move the request forward to completion.

Tasks for Change Requests

The Tasks tab of the service allows the selection of a method for task generation. The available methods depend on the request type and they are different for service requests and incidents vs. change requests. Change Requests have two options for the task generation method: Predefined Task Workflow and CR Single Task from Template.

Change requests are typically associated with one or more configuration items. Task handling for change requests is therefore designed to create a task for each configuration item that has been associated with the request. If the user chooses 100 configuration items for a change request and generates tasks, whichever tasks are defined for the change request are created 100 times, one for each configuration item. The tasks are generated in this way by using a task template and pushing its details down through the configuration item records, so this necessitates restricting some of the other task generation options. 

Predefined Task Workflow - allows the selection and/or creation of a Task Workflow with predefined task templates arranged in a sequential or parallel order. See more details about configuring task workflows in the Task Workflows Table section.

Note that if your workflow has 3 tasks, they will each be generated for each configuration item.

The CR Single Task from Template option is more common for change requests involving numerous configuration items. Here you define a single task template to be used with the change request. 

Note that a single task may have several predefined steps, presented as a checklist, to assist technicians in performing the task. See the sections on Task Templates Table and Task Steps Table for more details on how to set this up.

Using task steps within a single task makes good sense for a change request. While setting up the service, if the task template you want to use does not yet exist, use the Create and Apply New Task Template button to open the task template screen to define a new template. After saving the template, select it for the service where you started.

Shows the Create and Apply New Task Template button under the Default Task Template heading.

In the Change Request, it is possible when using this task method to select more than this one task template to generate. After the default task is generated, the user can select from other predefined tasks and generate them as well.

Tasks for Service Requests and Incidents

For service requests and incidents, there are some different task generation options. There are three possible methods:

• Predefined Task Workflow – this is the same as the usage in change requests, except that the tasks are not tied to CI's and are just created once per request. With this choice in a service,, another field - Enable Ad Hoc Tasks – appears, and if it has a Yes value, then in addition to the predefined tasks, the user may create additional tasks for a particular request.
• User Selected Tasks –allows the service manager to create a set of possible tasks that will be displayed in a request as checkbox items, so the user may select which tasks are relevant for this particular service request or incident and generate just those tasks.
  Supporting Tasks and OLAs section where users scan create task templates used in the Service Request.
  To create templates for the potential tasks, click Create Task Template. Ad hoc tasks may also be enabled for this type by selecting Yes for the Enable Ad Hoc Tasks? field. In the Service Request, the optional tasks from the service appear as checkboxes.
  

  Optional tasks shown in the Service Request record: Create custom sign or banner, and Prepare order for print shop.

  The user checks the boxes for the tasks he wants, and clicks the Generate Task(s) button to generate the individual tasks. These tasks, since they are all optional, are defined as parallel tasks without specific prerequisites.

• User Generated Ad Hoc Tasks – this selection allows the user to manually create tasks in the service request without reference to any preexisting templates. In this case, the user will see a button in the service request to create a new task. Ad hoc tasks can be made sequential during creation by selecting one or more prerequisite tasks as the individual tasks are created.

Performance Tab

The performance tab on the layout is used to hold information about the number of open incidents or service requests for a service and the percentage of those that have breached their SLA.

Depending the request type, it shows different fields: a related table of open incidents, or a related table of open service requests, and the relevant statistical fields.

Table of open service requests.

These values can be shown in reports on the service table as well as on the Incident or Service Request tables.

Service Provisioning Tab

This is where the workflow for on-boarding a new service is done. There are fields to track communications, updates, knowledge and other materials that may be relevant, and automation to make it easy to email people responsible with information or questions about the service.

New Service Onboarding and Management

In addition to the notes and links to files and knowledge, the Status field is used to manage the onboarding process and to define the subsets of the Service Portfolio. It has default values of Planed, Pending Approval, Approved, In Development, Active, In Review, Retired, or Canceled.

• All services that are in a status of Planned, Pending Approval, Approved, or In Development are shown in the Service Pipeline list and report.
• Those with a status of Active or In Review are shown in the Service Catalog list.
• Those that have been set to Retired are shown in the Retired list and report.

Once the Service Catalog is initially set up by creating the appropriate services in the Service table, new service items will typically be created by power users only when a new service is planned or initiated. Initial permissions are set so only users in the admin, Service Manager, and Change Manager groups can create, modify, and delete services.

Ownership

Services are owned by the person who creates the service.

Workflow

Workflow diagram showing transitions between the available states. For instance, from Pending records may move to Canceled, Approved, Active, or In Development.

Saved Searches

A few of the default saved searches are listed below.

Reports

A few of the available reports are listed below.