The Service Level Agreements (SLAs) table manages the service level agreements between the IT department and its customers. SLAs define specific SLA targets for response and resolution times for incidents and service requests. These SLA targets also define diagnosis and resolution times for problems. SLA targets are based on the priority of the request record and are applied or updated whenever the priority is set or changed.

Each SLA has its own SLA targets.

The SLA structure is designed to be extremely flexible. It can handle anything from the simplest situation, in which all employees and services have the same standard SLAs, to scenarios where each department has different response times, multiple sets of services have different response times, or a combination of the two.

When applying an SLA to a request or incident, there are two factors that determine which of the available SLAs is applied: the SLA types and the SLA Customer Group of the submitter.

SLA Types

There are four different types of SLAs and they are applied to new service requests or incidents in priority order as follows:

Configuration Item - Critical configuration items or classes of items may be given their own SLA, and this SLA will take priority over other SLAs.

Service-Specific - This is an SLA for one or more specific services typically with reduced time frames for its SLA targets that may be available to only some customer groups. For example you may have a special SLA for a high priority service that should have better response times than less business-critical services, or for single services that should only be available to a specific groups of users.

Customer Group - This is an SLA that typically covers multiple services but that applies to a specific Customer Group, for instance an SLA for the finance manager group that gives them better resolution times for mission critical financial-related services.

Corporate - This is an SLA for multiple services that are made available to all users in all customer groups, typically at a base level of service, for services that may not be included in the other SLA types.

SLA Customer Groups

SLAs are defined to be available to one or more SLA Customer Groups. Users each belong to one SLA Customer Group. The SLA Customer Groups table holds the values for the different groups. The out-of-the-box groups include:

• Corporate
• Finance Managers
• IT Managers
• Sales Department
• HR Department
• Gold / Executive
• Silver

 You can modify these records or create new SLA Customer Groups to match your company service structure. SLA Customer Group records hold a name, status, and description.

Sample SLA Customer Group record.

On the Related Info tab, they show all the people who are assigned to the group, as well as the business services and service offerings associated with the group.

Application of SLAs to Customer Groups, Users, and Requests

Corporate SLAs are applied to all groups automatically. Both Service-Specific and Customer Group SLAs can be applied to one or more SLA customer groups. So a particular customer group might have a combination of all three types of SLAs available to it, and all three might even be linked to some overlapping services. 

Users of the system each belong to one SLA Customer Group, and that group defines the list of services that user can request, based on the SLAs tied to his group and the services tied to these SLAs, as shown in the diagram.

Diagram showing a hypothetical user's SLA Customer Groups, and the number of linked services available for each.

SLA Layout

It is important to set up the SLAs carefully to ensure that there is some coverage for all services – typically in a corporate SLA – with the special coverage for certain services or certain groups within the organization. Open an SLA by clicking the Edit icon in the left pane. They can also be opened from within a service record, on the SLAs tab.

The SLAs tab in a Service record highlighting the edit icon for the linked SLA.

The Details tab of the SLA contains the primary fields. SLAs may be applied to both incidents and service requests or only to one request type. The multi-value Applies to SLA Customer Groups field defines the groups that can use the services in this SLA.

Fields for Scope and attached files gather the negotiated data and requirements for the SLA. The SLA Owner Team defines the internal IT team that is responsible for managing the SLA, while the availability and support hours define the hours that will be used for SLA target measurement and reporting.

It is important to configure the Support Hours because all SLA targets are measured against the defined Support Hours.

Sample SLA record showing the SLA Details section.

Support Hours

The support hours for SLAs, as well as the availability and maintenance schedules for requests and configuration items, are defined as special teams. Teams can have specific working hours and the system is able to include or exclude team working hours in any kind of time measurement, for elapsed time fields or reports, so this gives the ability to set targets based on such team hours and then to measure them.

For example, here are the working hours defined for the Support: 7 - 7 weekdays team

Screenshot of the team working hours.

Several default teams have been set up with and named for specific working hours, but if you need to manage other kinds of schedules, you can modify these teams or create new ones. The Teams table has a special custom field, Team is Responsible For, that helps filter the drop-downs for support hours, maintenance hours, and availability hours, as well as the drop-downs for assigned teams within the request tables.

The Team is Responsible For choices are a set of checkboxes. The image highlights Availability Hours, Maintenance Window, and Support Hours.

When setting up new teams for this purpose, it is important to check the appropriate box so the team will appear in the various drop-downs.

Services for an SLA

The Services tab allows the user setting up the SLA to first select the business services, and then the related service offerings to which the SLA will apply. The service offerings are filtered to those for the business services selected. Users can click Add All Services to add all services for the selected business services, or use the lookup to choose individual services.

Service Offerings section.

Configuration Item SLAs

Configuration Item SLAs are linked to existing configuration items instead of specific services.

Services screen in an SLA record for Configuration Items.

An SLA can also be selected when creating or editing a Configuration Item record. Here is the corresponding configuration item record:

Below the services section is the related table showing the SLA targets that will be used for this SLA. When setting up a new SLA, click the New button above this table to create new SLA target records.

SLA Targets Table

The SLA targets table is used to define the turnaround time for a service request, incident, or problem record. Each target is linked to one SLA and is shown within that SLA. Since an SLA may cover more than one request type, the targets can be distinguished by the request type as well as the SLA. The SLA target form has the following fields: ID and Status; SLA Target Information including Request Type, Priority Level, Resolution Time, Resolution Time Warning, and Response Time; and linked fields to the SLA which include SLA Title, SLA Type, SLA Request Types, SLA Service Level, and SLA Description.

SLA Target Details screen.

The key elements are the Priority value, the Request Type, and the three time fields that set the response, warning, and resolution times. Each of these times is measured only during the defined support hours for the SLA. So if the SLA has hours from 7 AM to 7 PM and a service request with the above target is submitted at 6 PM on Monday, the response time will be due at 7 PM, the warning time will occur at 2 PM Tuesday (with 1 hour remaining Monday and 7 hours starting from 7 AM Tuesday), and the resolution time will be set to 3 PM Tuesday.

Applying SLA Targets in Service Requests and Incidents

When a service request or incident is created, the appropriate SLA is applied based on the criteria described above. Then based on the Priority of the record, the appropriate SLA target is applied and linked into the request or incident.

When the SLA target is linked, if no approvals are needed first, a rule sets three date fields in the request – the SLA Due Date, SLA Response Due Date, and SLA Warning Date – by adding the values set in the target for each of these times to the current date/time plus that value according to the working support hours for the SLA. 

In a case where there are approvals before work can begin for a service request, the SLA Response due date is set immediately, and the SLA Warning Date and SLA Due date are set when all approvals are completed and the status is set to Approved. In that case, the time is measured from the Date Approved rather than the date the record was created.

A sample set of SLA Targets for an SLA that covers both incidents and service requests.

Available Priorities

In order to assist in setting up SLA targets, the available priorities for the various request types included in the SLA are shown in the Available Priorities table view. It is the priority number (level) that is used in the target. If there are only three priorities for Service Requests, but five priorities for Incidents, as in the default setup, then an SLA that covers both request types will have eight SLA Targets, one for each possible priority.

Related Information Tab - Measuring Performance

The Related Information tab holds information about all open service requests and open incidents that are based on this SLA. It can be used in reporting to show the current situation by SLA.

Emails and History Tab

The Emails tab hold standard communications fields showing all emails sent about the SLA. The History tab displays standard History fields and the Date Created, Date Updated.

Onboarding an SLA - Status Workflow

The SLA record has several workflow statuses to manage the on-boarding of new SLAs. The SLA on-boarding process may well begin as a Service Level Requirement - the first Status allows the SLA record to be created in a status of Planned - Service Level Requirement, so that the necessary requirement information can be collected and gathered in this record during negotiations. From there it may move to In Negotiation, and when ready to use, Active. 

When SLAs are applied to service requests and incidents, only those in a Status of Active or In Review may be applied. If an SLA is replaced by a new version, the old one can be set to a Retired status, and a planned SLA may be canceled if it does not meet the needs of the organization.

Date Fields for Tracking Progress

When an SLA changes to Active, the Date Activated field is automatically populated. In addition, the Next Review Date can be set to trigger a reminder to review the SLA and see if it should be adjusted, at whatever interval is ideal. SLAs are automatically set to a Status of In Review when the Next Review Date arrives and an email is sent to the SLA Owner Team notifying them that the SLA should be reviewed. This email is sent by a time based rule that checks each day to see if the current date matches the next review date.

The Ongoing Notes field is an append-only field that will date/time/user stamp all updated comments.

Reporting

Reporting for SLA performance is done from several places.

Excel reports have been created for the Service Request and Incident tables that allow the data to be sliced by any factor, from the individual SLA, to the individual business service or services, by assigned team and so on. 

SLA Dashboard for Incidents

The report on the Incident table is shown below. Go to Incidents > Charts and Reports to access it.

SLA Dashboard.

When clicked, it results in an Excel file that can be manipulated to show any statistics related to SLA metrics.

Report image showing pie chart of Resolution Met.

Service Request SLA Dashboard

The same Excel-based report runs on the Service Request table.

Service Request SLA Dashboard.

It shows a similar overview with slicers for each factor.

Open Service Requests that have Breached their SLA Resolution Time

This report, with a bar for each SLA, runs on the service request table and also appears in the Service Management Dashboard.

Bar chart of Open Service Requests that breached the SLA Target.

Active Incidents that have Breached SLA by Priority

This report on the incident table shows the open incidents that have already breached their resolution time. It also appears in the service management dashboard. From the report's HTML tab you can access the underlying Incidents.

Bar chart for Active Incidents that have breached the priority.

Closed Service Requests: Percentage meeting SLA in past 12 months by assigned team

This chart and report shows by team the percentages of requests that met the SLA.

Table of Closed Services Requests report.

Service Manager Dashboard

The dashboard is accessible to service technicians to quickly find incidents and service requests that have breached their SLAs and to drill down to work on them.

Service Manager Dashboard with quick links and five charts.

Automatic Performance Monitoring

The Services table also has rules monitoring it to keep service records updated with the current number of open requests, and to set the color of the service to red when some threshold is surpassed. A time based rule tracks the performance of all services with regard to current status of breached incidents and sets the row coloring for service based on the result:

• If the percentage of breached incidents or service requests is greater than 30%, the row color is set to red.
• If the percentage is between 15-29.99% it is set to orange
• If the percentage is lower than 15 it is not colored.

Table showing highlighted rows based on breach percentage.

Event Creation for SLAs with Performance Problems

SLA performance issues can result in the generation of an Event in the Event Management module. There is a weekly rule that searches for all SLAs whose Percentage of breached incidents is greater than 75% and generates an event for each one. These events will notify the service managers involved so they can analyze the reasons for the breach and take appropriate action.