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.
Anchor | ||||
---|---|---|---|---|
|
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.
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.
Info | ||
---|---|---|
| ||
Here John Smith is in the sales SLA Customer Group, and that group has access to three different SLAs, shown in orange, and through those SLAs, to their services shown in green, some of which overlap. He will be able to submit requests and incidents for any of the services linked to any of these three SLAs. If John submits a request for an email related service that is covered by all three SLAs, then the service-specific SLA will be applied, based on the priority order described above. If he submits a request that is covered by both the corporate SLA and the sales customer group SLA, then the Sales Customer Group SLA will be applied. If he submits a request that is only covered by the corporate SLA, then that SLA will be applied. However, in all three cases above, if the request was for a configuration item that had its own SLA, that SLA would be applied instead. If there are services not included in any of those three SLAs, he will not see them or be able to submit requests for them. |
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 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.
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
Day | Hours |
---|---|
Sunday | |
Monday | 07:00-19:00 |
Tuesday | 07:00-19:00 |
Wednesday | 07:00-19:00 |
Thursday | 07:00-19:00 |
Friday | 07:00-19:00 |
Saturday |
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.
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.
Configuration Item SLAs
Configuration Item SLAs are linked to existing configuration items instead of specific services.
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.
Anchor | ||||
---|---|---|---|---|
|
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.
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.
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.
When clicked, it results in an Excel file that can be manipulated to show any statistics related to SLA metrics.
Service Request SLA Dashboard
The same Excel-based report runs on the Service Request table.
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.
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.
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.
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.
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.
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.