When ordering services from your IT department, it’s of prime importance that you know exactly what services you’re getting. Use an ITIL Service Level Agreement to ensure you’re receiving IT services according to your expectations. You wouldn’t go to a restaurant that made you do your own dishes – would you?
If you like our site please spread the word by telling your friends about us. We like to be Liked.
|Service Level Agreement|
MS Word Adobe PDF
[You are free to use this Service Level Agreement template within your organization. The green text is instructional and should be removed from your final document. You can download an MS Word version of this template by clicking on the Word icon above.
The introduction will provide an overview of the entire ITIL Service Level Agreement. It will include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Service Level Agreement.]
[Provide a brief description of the purpose of this Service Level Agreement.]
This document provides an agreement between “The Service Provider” and “The Client” as to what constitutes acceptable service in quantifiable and measurable terms. It documents the mutually service objectives, how those objectives will be measured, and the schedule of distribution for the measurements. The intent of this Service Level Agreement (SLA) is to ensure the proper understanding and commitments are in place for effective support, measurement and resource planning in the provision of the Help Desk service according to the ITIL methodology.
[Provide a description and scope of the services covered by this Service Level Agreement (SLA):
The service to be provided is the provision of Help Desk for the information technology infrastructure of “The client”. The areas to be serviced are:
The timeframe will be from January 1, 20xx, to December 31, 20xx.
The complete description of all the networks, devices, servers, workstations, operating systems, and applications to be serviced (currently in use or predicted) is listed in the referenced document ("The Client". Help Desk Service. Complete Description of Targets.)
For the provision of this service, the following processes have been optimized:
Service will not include:
1.3 Definitions, Acronyms, and Abbreviations
[This section provides the definitions of all terms, acronyms, and abbreviations required to understand this document.]
Table 1. Definitions, Acronyms, and Abbreviations
[This section provides a complete list of all documents referenced elsewhere in this document. Identify each document by title and other applicable data like version, date, etc. This information may be provided by reference to an appendix or to another document.]
Doe, Jane;. (20xx). "The Client". Help Desk Service. Assigment of roles.
[This subsection describes what the rest of the DT contains and explains how the document is organized.]
The sections below detail how the Help Desk Service from “The Service Provider” to “The Client” must be measured and evaluated, as agreed by both parties.
Section 2 lists all the stakeholders involved in the acceptance and maintenance of this agreement. Roles and responsibilities are defined at the end of this section.
Section 3 describes the details of the agreed service levels, including how they are measured.
[Document the key participants and their responsibilities in the process of negotiating and managing this Service Level Agreement. These participants may include:
[Customize this list with all the persons signing and approving this document. For each person, insert name and position.]
The following persons have negotiated this document and agree it will be used as the formal Service Level Agreement (SLA) for the provision of the Service.
Table 2. Signatories.
[Add in this section other persons which are important for this Service Level Agreement, for example, for legal issues, procurement, etc. For each person, insert name and position.]
Table 3. Contacts.
[Summarize the roles and responsibilities of the key parties to this SLA. For each role, list the responsibilities. Duplicate when needed for both client and customer.]
Table 4. Responsibilities.
For the updated assignments of roles to people / positions see the referenced document ("The Client". Help Desk Service. Assigment of roles.).
3. Service Objectives and Measurements
[These are the important commitments in the IIIL Service Level Agreement, which the Service Owner and Service Supplier have agreed as the key measurements of SLA achievement. As part of the design of the Service, a few KPIs and metrics have been selected; they are as close as possible to the real perception that the client has of the service.]
3.1 Service Objectives
[List key service level objectives and measurements. The objectives in the list will vary according to the service been provided, the warranties required, and the targets been serviced.]
3.1.1 Service Hours
[Write a description of the hours that the customers can expect the service to be available. Specify special conditions for exceptions (e.g. weekends, public holidays) and procedures for requesting service extensions (who to contact – normally the Service Desk –- and what notice periods are required)]Service must be available from 8:00 AM to 10:00 PM, Monday through Friday, except when the Customer facilities are closed due to holidays, administrative closings, or inclement weather. A service can be requested or an Incident reported by telephone during working hours, or by mail or by the Web Service Portal at any time. Incidents reported or services requested outside the working hours will be served at the next scheduled working day, unless a special procedure for Major Incident is invoked (see 3.1.5 below.).
3.1.2 Service Availability
[Specify the target availability levels that the IT service provider will seek to deliver within the agreed service hours. Availability targets within agreed service hours are normally expressed as percentages (e.g. 99.5%). Measurement periods, method and calculations must be stipulated. This figure may be expressed for the overall service, underpinning services and critical components or all three. It is often more practical to try to measure service unavailability in terms of the customer’s inability to conduct its business activities.]
For the provision of the Service covered by this Service Level Agreement, availability is determined by the percent of the time components of the Service are available to users.
“The Service Provider” will seek 100 % availability during working hours for all the interfaces combined (telephone, e-mail or Web) to report or request, that means client will always have at least one mean available to report and Incident or request a service at working times. Availability of each interface alone is provided below:
Table 5. Availability of Service.
3.1.3 Service Reliability
[This means the maximum number of service breaks that can be tolerated within an agreed period; it may be defined either as number of breaks in a timeframe, or as a Mean Time Between Failures (MTBF) or Mean Time Between Systems Incidents (MTBSI). Define what constitutes a ‘break’ and how these will be monitored and recorded.]
As part of the quality of service, “The Service Provider” has designed the service to be resilient; enhancing in that way realibility.
The commitments in this SLA are as follows:
For the provision of the Service covered by this SLA, a Failure will be considered any Incident with Impact = Critical. See the referenced document ("The Client". Help Desk Service. List of Incidents and Services to Request.) to determine the Impact of an Incident.
3.1.4 Scheduled Processing
[Describe the procedure for serving the request for service made for users. Include details of the contacts within each of the parties involved in the agreement and the escalation processes and contact points. If the procedure is explained in other documents, include the reference to them]
All Incidents will be managed according the Incident Management Process that was designed along with the design of the Service itself. For details like workflows, roles and responsibilities, work products, escalation and control procedures, see the referenced document ("The Client". Help Desk Service. Incident Management Process Design.).
All the service requests made by users will be managed according the Request Fulfillment Management Process that was designed along with the design of the Service itself. For details like workflows, roles and responsibilities, work products, escalation and control procedures, see the referenced document ("The Client". Help Desk Service. Request Fulfillment Management Process Design.).
The first-line support is the entry point defined for both process. Users can request service or report an Incident by using one of the following:
3.1.5 Exceptional Processing
[Write here special procedures like escalation, major incidents, etc.]
Special procedures are defined in the design of both processes to address special circumstances like:
In those cases, emergency procedures are defined including hierarchical escalation. They must be authorized for both Service Level Managers. See the referenced documents ("The Client". Help Desk Service. Incident Management Process Design.) and ("The Client". Help Desk Service. Request Fulfillment Management Process Design.)
This number will be available for emergency request:
3.1.6 Service Performance
[Include details of the expected responsiveness of the IT service, like online response time commitments, transaction processing targets, performance objectives, etc. Performance objectives should be related to agreed business volume levels or transaction volumes. Describe how performance will be measured.]
The target resolution time for each Incident or Service Request depends on its Priority. The agreed targets are as follows:
Table 6. Target resolution times by Priorities.
Priority is determined by the Urgency and the Impact of the Incident or Service Request, as per follow:
Table 7. Determination of Priorities.
A updated, detailed list of types of Incidents and Service to Requests, along with their agreed Urgency and Impact and the calculated Priority is shown in the referenced document ("The Client". Help Desk Service. List of Incidents and Services to Request.) not included inside this document.
[Capacity to be provided, preferably related to business volumes (e.g. transaction volumes, number of concurrent users, etc.). What will be done if agreed capacity limits are exceeded.]
To address the work at all times, the personnel for delivering the service is organized into 2 (two) shifts:
The assigned manpower for each of the three tier of Support and the technical infrastructure for providing the Service is described in detail in the referenced document ("The Client". Help Desk Service. Service Design.)
3.2 Service Objectives Ratings
[Create a ratings chart to show how the customer would rate the service in terms of performance. The ratings should be based on targets, such as availability targets, response, etc.]
When possible, RAG (Red, Amber, Blue) charts will be used to evaluate the Service performance and other results. These are special types of SLAM (Service Level Agreement Monitoring) charts. Two days before each Service Level Review, the Service Level Analyst will distribute the RAGs altogether with the source reports to all the participants.
Resolution time is pivotal to performance as shown in Table 6. Target resolution times by Priorities.
The agreed criterion for rating the service is as follow:
Table 8. Rating of Service.
When the Rating is “Target breached”, a penalty may be applied upon “The Service Provider”, unless demonstrated the fault lies on the side of “The Client”. The penalty can also be waived if both parties reach an agreement to do so. If applied, Penalty will be:
P$ = V$ x (95% - P); where
V$: Payment to receive for the period;
P: Percent of Incidents and service request resolution meeting target.
Additionally, surveys will be used to measure the perception of users about the Service. The results will be used to monitor and increase the quality of service. A rating of 3.5 in a scale from 1 (lowest) to 5 (highest) will be considered satisfactory.
3.3 Measurement Details
[Provide details of how measurements will be taken and any necessary calculation formulae. Define any special transactions or benchmark processes that will be used to measure and monitor service levels.]
Event Management will provide the environment for all the measurement and reporting required to monitor the components, the process and the Service itself. The primary source for monitoring the targets in this SLA is the information collected into the Service Management tool. In the case of measuring elapsed times (like resolution time which is pivotal for rating the Service), the value is calculated from the time the incident or request is created in the system until the time the incident or request is marked as closed. When the incident or service request is reported outside the working hours, the record is actually created at the beginning of the next working hour, unless a special procedure is invoked to start resolution immediately.
3.4 Measurement Reporting
[Describe how measurement results or changes to the schedule will be published. Additional detailed information other than standard monthly measurements will be included in the monthly report only if one or more of the service level objectives has been missed.]
Reports will show collected measurements relevant to the targets defined in this Service Level Agreement. They are of three types:
The periodic reports will incorporate details of performance against all Service Level Agreement targets, together with details of any trends or specific actions being undertaken to improve service quality. They will include SLAM charts at the level of the whole service. Optionally, they can be drilled down at the level of components, especially if a target is reported breached. The Service Level Analyst will distribute these periodic reports to all participants two days before the Service Level Review meetings.
The Service Level Reviews will be held every two weeks and will be led by Service Level Managers.
4. Additional Considerations
[Put additional content about services here.]
The parties agree to try resolving their differences internally in good faith. In case a difference persists, they will submit their complaints to the arbitrator. The decision of the arbitrator will be considered final and must be accepted by both parties.
5. Supporting Information
[The supporting information makes the DT easier to use. It includes:
These may include use-case storyboards or user-interface prototypes. When appendices are included, the DT should explicitly state whether or not the appendices are to be considered part of the requirements.]
5.1 List of Tables
[Provide an index for all tables in the Service Level Agreement.]
[Provide an index of all sections of the Service Level Agreement.]
Copyright © 2012 The Corporation, Inc.