ITS M: Service Level Agreements Sample Agreements, Reports, and Checklists

RL Consulting
People Process Technology

Organization Integration
IT SERVICES MANAGEMENT
Service Level Agreements
Sample Agreements, Reports, and
Checklists
White Paper
PREPARED BY:
RICK LEOPOLDI
May 25, 2002
Copyright 2002 RL Consulting. All rights reserved.

Duplication of this document or extraction of content is strictly forbidden.
ITSM - SLA SAMPLES
Service Level Agreement Sample #1

This sample is a short form contract used to both document the SLA and report
monthly on its status. One of these is produced for each service provided.
Between IT Department And
ABC Department
Contacts:
IT Department:
Date: MM/YY
Effective Dates: From MM/YY
to MM/YY
ABC Department:
Approvals:
IT Department:
ABC Department:
CICS Service
Availability
8 am - 5 pm Mon-Fri
Response
% of response within 2
seconds (internal)
% of response within 2
seconds (internal)
Transactions/min during
peak (9 am 11 am)
Daily CPU hours
Load
Accuracy
Batch
Service
Errors due to DC
Problems
Errors due to
Applications
Class S: % turnaround
in 30 minutes
Class T: % turnaround
in 15 minutes
Goal
98%
Actual
100%
Difference
2%
90%
95%
5%
95%
95%
0%
300
250
-50
3.5
3.0
-.5
95%
85%
-10%
98%
100%
2%
SLA Criteria:
1) Availability based on CICSPROD up and files open.
2) Penalties for missed services:
a) 10% reduction in billing for 2% missed service unless miss caused by user.
3) Penalties for exceeded loads:
a) 10% increase in billing and no penalty for missed service.
4) Reporting: Data Center will provide this report by 8 am each day. Weekly report will summarize
service for the week.
5) Changes to SLA's must be negotiated with contacts for IT and ABC department.
6) Priorities if full resources are unavailable: TSO users will be logged off to favor CICS.
7) Batch Services:
a) Turnaround is defined to be from job submission to job end (not including print time)
RL Consulting
Page - 1
ITSM - SLA SAMPLES

This sample is a long form contract with a sample report following it. One of these is
produced for each service provided.
Date: MM/DD/YYYY
To: Order Processing Department
From: Information Technology Department
Subject: Service Level Agreement
I.
INTRODUCTION
The following Service Level Agreement (SLA) is between the Order Processing Department, referred
to as the client and the Information Technology Department (IT). A SLA summary report will be
distributed on the 15th workday of each month. A sample of this report is attached.
Ultimately the goal is to deliver 100% availability. This SLA is another step in the effort to achieve
that objective. It is Information Technology's intention to continuously apply ABC Company quality
standards to improve client service in all areas whenever possible.
This agreement shall be in effect for 1 year from MM/YY or until the SLA is renegotiated. Expired
SLA's will continue to be reported upon until new SLA's are put in place.
II. IT SERVICES PROVIDED

A.
SYSTEM AVAILABILITY
The Order Processing Department's system availability is a metric from a combination of various
availability components. This metric is representative of mainframe hardware and system control
programs (MVS, VM, etc.). IT will report availability for MVS, VM, EMAIL, the network and the
ORDER system.
1. ORDER System
Description:
The ORDER System platform will be available as measured by IDMS production on a weekly
basis and include specified service hours as documented below.
Scheduled Backups:
Tuesday and Friday
During maintenance periods
8:00 PM - 9:30 PM
5:30 PM - 7:00 PM
The ORDER System will be available in "inquiry" mode during backups.

Service Goals:
The ORDER System will be available not less than 97% of the agreed production hours.
Unscheduled outages will not exceed 1% of the time.
Measurement Method:
The ORDER System availability reporting will include both unscheduled and scheduled
outages. IDMS production will be measured on a weekly basis and reported upon weekly.
RL Consulting
Page - 2
ITSM - SLA SAMPLES
2. EMAIL
Description:
EMAIL availability reporting will include both unscheduled and scheduled outages. The
EMAIL production system will be available a certain percentage of the time for unscheduled
outages as documented below under Service Goals. EMAIL production will be measured on
a weekly basis and reported upon weekly.
EMAIL Maintenance:
EMAIL will be unavailable during scheduled application maintenance periods. The
maintenance schedule is currently as follows; 7:00PM to 10:00PM on alternate Tuesdays
during the PM window and 9:00AM until 11:00AM Sundays for database maintenance.
Service Goals:
The EMAIL production system will be available not less than 97% of the time. Unscheduled
outages will not exceed 1% of the time.
Measurement Method:
EMAIL availability reporting will include both unscheduled and scheduled outages. EMAIL
production will be measured on a weekly basis and reported upon weekly.
3. MVS Systems
Description:
Information Technology (IT) will provide the client a level of MVS platform availability that is
defined in this document. Availability metrics include both scheduled and unscheduled
outages.
Systems Maintenance:
Computer Systems will be unavailable during the PM window. That maintenance schedule is
currently as follows; 7:00PM to 10:00PM on alternate Tuesdays.
Service Goals:
Computer Systems will be available 98% of the time, as measured on a weekly basis
including unscheduled outages and specified service outages as documented above.
Measurement Method:
Computer System availability reporting will include both unscheduled and scheduled
outages. Production will be measured on a weekly basis and reported upon weekly.
4. VM System
Description:
The VM system will be available as measured on a weekly basis within specified service
hours including maintenance as documented below.
Scheduled Maintenance:
Will be performed 12:00 Midnight Friday until 8:00 AM Saturday.
Service Goals:
The VM production system will be available not less than 94% of the time. Unscheduled
outages will not exceed 1% of the time.
RL Consulting
Page - 3
ITSM - SLA SAMPLES

Measurement Method:
VM production will be measured on a weekly basis and reported upon monthly. Reporting
will include both unscheduled and scheduled outages.
5. Network Availability
a) VTAM availability is included in MVS system availability. The objective for this area is 98%.
b) Hardware/Front End Processors
Description:
Front End Processors include communications controller equipment and equipment from
other vendors which perform similar functions.
Service Goals:
Front End Processors will be available 99.5% of the time.
Method of Measurement:
Availability will be measured by IT through manual and automated methods. Reporting will
be done on a monthly basis. Measurement is on a 24 hour by 7-day per week basis.
Outages include scheduled, negotiated and unscheduled periods of unavailability.
Unscheduled and scheduled outages will not exceed 0.5% of the time.
B.
PERFORMANCE
The Order Processing Department's systems client response time will be maintained at mutually
agreed upon levels.
1. ORDER System Performance
Description:
ORDER System Performance includes IDMS internal response time and dial-up network
response time. IDMS internal response time will be measured for all ORDER System online transactions. Network response time includes all components of the dial-up
teleprocessing network.
Service Goals:
IDMS internal response time:
!"
91% of all ORDER System transactions will complete in less than 2 seconds
!"
98% of all ORDER System transactions will complete in less than 5 seconds
Measurement Method:
ORDER System response time will be measured by IT Performance and Capacity
Planning and by Applications. Measurement will be done on a weekly basis and
reporting will be monthly.
2. Remote Network Response Time
Description:
Network Response Time includes network delay as a component of ORDER system
performance.
Service Goals:
The average of all ORDER system dial-up transactions will complete within 6 seconds.
RL Consulting
Page - 4
ITSM - SLA SAMPLES

Measurement Method:
ORDER system IDMS performance will be measured via MVS host based monitoring
technique for internal response time and by microcomputer based measuring for the
network.
C.
OPERATIONS & SERVICES
1. Computer Operations and Batch Services

Production Batch
Description:
Production services include scheduling and tracking to completion all scheduled batch
workloads processed on host-based systems.
Service Goals:
All scheduled production ORDER System batch jobs will be completed on time 99% of
the time according to the production documentation scheduling requirements.
Measurement Method:
Production batch performance metrics will be recorded, measured and reported by
manual monitoring techniques (this can be automated).
a) Tape Service:
Batch submitted jobs which call for tape mounts on MVS systems will be provided
an automated and manual mechanism to fulfill those tape mount requests. Tape
mounts will be measured and reported as an average. Tape mounts will be
satisfied within 2 minutes of operator/system notification. Saturday and Sunday,
they will be satisfied within 5 minutes.
Service Goals:
IT will provide the above services within the service levels indicated 100% of the time.
Measurement:
Tape service measurement will take place through automated processes and will include
average tape mount time for a given number of jobs per week.
2. DASD Management
a) Dataset Restore from Archive
Information Technology will provide the client a satisfactory level of dataset restores
from archive. Dataset restores on MVS systems are included in this service. This
service is in effect only when all supporting hardware and software systems are
available.
Service Goals:
Restores from on-line compressed DASD to client DASD: 35 seconds 99% of the
time.
Restores from tape cartridge to client DASD: 30 minutes 95% of the time.
b) DASD Recovery
IT will provide 4-hour turnaround on recovering data in cases of a single DASD volume
failure. Off-shift turn-around may add two hours to the above commitment. Recoveries
from an off-site source will be made within 48 hours. Recoveries requiring longer will
RL Consulting
Page - 5
ITSM - SLA SAMPLES

be communicated to the client and an appropriate schedule will be negotiated within
eight hours.
Service Goal:
Services identified above will be fulfilled 100% of the time.
c) DASD Capital Acquisition
IT will provide Quarterly Capital Acquisition approved DASD within 5 weeks of procurement.
Service Goal:
Services identified above will be fulfilled 100% of the time.
DASD Measurement Method:
IT Storage Management will measure weekly and report monthly on the above objectives
through manual and automated processes. To optimize manpower, in-depth reporting will
occur on an exception basis. High-level pass/fail objectives will always be reported upon
and detailed results will be reported upon only when objectives are not met.
3. Information Technology Support
a) Help Desk Support
Description:
Information Technology (IT) will provide the Order Processing Department with
business oriented problem resolution and reporting. Help Desk functions include client
assistance in technical matters pertaining to Computer Center availability, general
information, problem resolution and performance issues.
Service Goals:
80% of all calls to the Help Desk will be resolved within one business day.
D.
PROCEDURE FOR UNSATISFACTORY SERVICE
When service falls below the thresholds identified under paragraphs titled "Service Goals", IT will
work to resolve service problems and report progress to the customer. In the event that service
does not improve, a joint meeting between members of the Order Processing Department and IT
will convene. This meeting will be used to discuss and resolve problems that have resulted in
diminished service to the customer. A comprehensive report that documents the results and
resolutions of these problems shall be published and distributed to management.
SERVICE LEVEL AGREEMENT REPORTING
Service Level Agreement Reporting will take place on a monthly basis with a weekly overview and
event analysis report.
III. CLIENT RESPONSIBILITIES

The Order Processing Department will participate, when requested in all IT/Order Processing
administrative, technical and process decisions that may affect the integrity of the customer
applications and databases.
RL Consulting
Page - 6
ITSM - SLA SAMPLES
IV.
ASSUMPTIONS
The commitments in this agreement are based upon the following assumptions:
1) Scheduled holidays will be included in the Service Level Agreement.
2) Periodic database and application maintenance will be negotiated with IT and the client in
advance. These mutually agreed upon times will be subtracted from the scheduled
availability.
3) All application enhancements must be communicated to Information Technology (IT) and
will be incorporated into the system via procedures in place.
4) The ORDER System overall Service Level Agreement may be jointly renegotiated only by
Order Processing Department and IT organizations. Either party may open negotiations.
Renegotiated SLA's require both vice presidents signatures.
5) ORDER System service levels are based upon the maximum size of the ORDER database
during the month of MMMM, 20XX, with no more than a 20% increase over a six month
period. Proactive monitoring, analysis and projection will be performed by IT to prevent
descending below established service levels.
6) ORDER System service levels are based on a maximum number of total transactions per day
on the most active day in MMMM, 20XX. When transactions exceed a 30% increase over
this level within a six-month period, the SLA metrics will be reviewed and renegotiated.
Additionally, service is based on an average of transactions per hour on the most active day
in MMMM, 20XX. Proactive monitoring, analysis and projection will be performed by IT to
prevent descending below established service levels.
7) MVS DASD backups are performed on a daily basis. Certain critical datasets are backed up
more frequently. TSO, Pool, Common packs are backed up on a daily incremental, weekly or
monthly basis. ORDER databases are backed up on a daily basis.
8) Backup of client private DASD volumes is the responsibility of the client.
V.
APPROVALS
Information Technology:
_____________________________________________ Date_________
J. Smith - Director Applications Development
_____________________________________________ Date_________
R. Jones - Director Operations/Technical/Communications
_____________________________________________ Date_________
S. Johnson - Vice President Information Technology
Order Processing Department:
_____________________________________________ Date_________
R. Wilson - Manager Order Entry
_____________________________________________ Date_________
S. Nealis - Manager Order Processing
_____________________________________________ Date_________
Y. Young - Vice President Order Processing
RL Consulting
Page - 7
ITSM - SLA SAMPLES
Service Level Agreement Report Sample #1

(Based on previous SLA Sample)
Order Processing Department SLA Detail Report

MAY 7
MAY 14
MAY 21
MAY 28
TARGET
IDMS
97.5%
99.5%
95%
99.4%
97%
MVS
97.7%
99.45%
99.2%
100%
98%
EMAIL
96.75%
98.6%
98%
99%
97%
VM
100%
100%
94.9%
99.7%
94%
FEP
99.9%
99.9%
99.9%
99.9%
99.5%
IDMS < 2 Sec
93%
94%
94%
94%
91%
IDMS < 5 Sec
98%
98%
98%
98%
98%
ORDER Dial-up (sec)
4.9
5.1
5.0
5.0
6.0
TSO < 5 Sec (All Shifts)
98%
98%
98%
98%
97%
TSO < 2 (1 & 2 Shifts)
94%
94%
94%
95%
92%
TSO < 2 (3rd Shift)
92%
92%
93%
93%
90%
Terminal Prob Resp (2hr)
100%
100%
100%
100%
100%
DASD Management
100%
100%
100%
100%
100%
Help Desk Calls
85%
90%
80%
90%
80%
Tape Mount Wait Avg. (min)
3.2
3.1
1.5
2.1
5.0
Batch Performance
98.6%
99.8%
100%
100%
99%
Availability
Performance
RL Consulting
Page - 8
ITSM - SLA SAMPLES
Service Level Agreement Checklist Sample #1

This checklist is intended to assist in the development of a Service Level Agreement.
Since Service Level Agreements can be used to describe a variety of services, the
particular elements appropriate to a specific SLA will depend on the circumstances.
Service to be provided:
Purpose of the service
Location of the service
Type of service
- Application DP Services
Batch jobs
TSO development
IMS
DB2
CICS
- Communications Services
Terminals
Concentrators
Front-ends
Lines
Modems
Network Control
- Applications Development Services
Functional review
Design
Testing
Implementation
- Technical assistance
Computer Operations
Software Support
Hardware planning
Strategic planning
Contract Administration
Hardware Installation
- Problem Resolution
Coverage
Help Desk
- Maintenance
Hardware
Software
Outside Vendor
- Training
For DP
For customer
By DP Trainer
By outside Vendor
- Environmental Support
Facilities
Security
RL Consulting
Page - 9
ITSM - SLA SAMPLES

Volume Expectations
- Batch jobs
Weekly totals: min, max and average
Daily peaks: min, max and average
Distribution over prime, non-prime and weekend
Projected 2-year growth
-Interactive transactions
Daily totals: min, max and average
Hourly peaks: min, max and average
Hourly distribution over prime, non-prime and weekends
Terminal Count
Terminal Growth
- Communications network volumes
Daily totals: min, max and average
Hourly peak: min, max and average
Hourly distribution over prime, non-prime and weekends
Terminal count
Terminal growth
- Applications development
Functional specifications
Testing requirements
Documentation
Implementation schedules
Specify services to be provided
Reports
Forecasts
Planning documents
- Problem resolution
Support services to be provided
Volume of demand for services
Daily totals: min, max and avg.
Hourly peaks: min, max and avg.
- Maintenance services
Maintenance services to be provided
Expected volume/frequency
Scheduled/unscheduled maintenance
- Training
Type training to be provided
Training schedule
Class size/frequency
- Administrative support
Type service to be provided
Expected volume/frequency
- Environmental support
Type service to be provided
Scope/Volume/frequency
RL Consulting
Page - 10
ITSM - SLA SAMPLES

Timeliness Expectations
- Batch Jobs
Turnaround times
Elapsed job start to job stop
Input received to output delivered
Average times vs percentile distribution
Volume related ranges
Conformance to schedule
- Interactive transactions
Response times
Host processor times
Customer terminal times
Average times vs percentile
Volume related ranges
- Communications services
Network delay times
Applications development
Implementation dates
Implementation dates
Response to crisis demands
- Problem resolution assistance
Wait time for service initiation
Time for problem resolution
- Maintenance
Conformance to maintenance schedule
Response to crises demands
- Training
Adherence to schedule
Training duration
- Administrative support
Wait time for service completion
Elapsed time for completion
- Environmental support
Adherence to schedule
Response to crises demands
Availability
- Commercial/Real time primary DP Service
Time period during which service is to be provided
- Application development
Project length
- Problem resolution/maintenance/Environmental support
Time period during which service is to be provided
- Technical assistance/administrative support
Normal office hours
- Training
Course schedule
RL Consulting
Page - 11
ITSM - SLA SAMPLES

Reliability
- Reliability = actual availability as a percentage of scheduled availability
- Conditions and exceptions
Perception of customer and provider may vary
- Periods of limited capability
Limitations
- Interdependencies
- Impact on other areas
Resource constraints
Conflict with shared resources
- Priority
With respect to providers other work
With respect to customers other work
- Backup requirements
- Security requirements
- Disaster Recovery policy and procedures
Compensation
- Definition of pricing units
Charge for service provided
Cost of service fixed by provider
Computer resources
Man-hours
Materials
Related services
- Relation of price to service
Premium price for premium (faster) service
Price adjustment for substandard service
Price discount for off-peak times
- Relation of price to volume
Decreasing scale to encourage volume (if desired)
Price penalties for excessive peak volumes (if desired)
- Non-monetary incentives/penalties
Wage and bonus incentives
May tie to MBO
Measurement
- Responsibility
Provider
Customer
Shared
- Appropriate metrics
- Source of information
- Measurement tools
- Analytical tools
- Definitions
- Assumptions
- Approximations
- Reporting vehicle
- Reporting audience
- Reporting frequency
RL Consulting
Page - 12
ITSM - SLA SAMPLES

This sample is a short form contract with the same areas contained in Sample #2.
One of these is produced for each service provided.
Reference Number
___________________________________________________________________
This document constitutes a formal contract between:
(Provider)
and
(Customer)
Implementation Date Review Date ______________________________________________________________
Provider's Location Providers Coordinator
___________________________________________________________________
Customer's Location Customers Coordinator
___________________________________________________________________
Description of Service ___________________________________________________________________
Volume ___________________________________________________________________
Timeliness ___________________________________________________________________
Availability ___________________________________________________________________
Reliability ___________________________________________________________________
Compensation ___________________________________________________________________
Measurement
Provider Approval Date -
RL Consulting
Customer Approval Date -
Page - 13
Building Service Level Agreement Contracts

A Best Practices Approach
Overview
Introduction
This paper presents a brief overview of what goes into a Service Level
Agreement (SLA) contract. It also presents an example of one.
Contents
This publication contains the following topics:

Topic
Why Have Service Level Agreements?
Contract Areas to Consider
Contract Components
Example Of A Service Level Agreement Contract
-1-
See Page
2
3
6
8
Why Have Service Level Agreements?

Rationale
SLAs are critical towards formalizing expectations around services with end
users and customers. Without these, customer expectations will assume that
everything will be delivered and available at a 100% level all the time.
Very little can be done about poor service when there is no definition what
good service is. Objectives should be set that describe items such as response
times, availability, turnaround and accuracy. Customers and IT should
commit to a mutually acceptable means of verifying compliance with service
objectives and agree on actions that must take place when exceptions occur.
Key Goals
Key goals of undertaking formalized service arrangements are as follows:

Allow for IT to understand customer service requirements.
Control customer expectations for levels of service to be delivered.
Allow for clear understanding of priorities when handling service problems.
-2-
Contract Areas to Consider

Overview
The following section presents a number of key areas to consider when

building SLA Contract documents.
Level of
Formalization
Service levels may range from a formalized contract that is signed off by
representative customer departments to informal "known" levels internal to IT
functions. IT should be aware which level of formalization is appropriate.
Ability to Meet
Service Targets
IT should ensure that documented levels of service can indeed be met. Targets
should allow for a latitude contingency to cover occasional problems or
slowdowns to occur without jeopardizing targets.
Within ITIL, Availability Management should review planned targets and
provide guidance as to what levels may be appropriate given current IT
capabilities. Requirements for new capabilities should be highlighted to
management to determine whether to invest in them or not.
Control of
Customer
Expectations
Targets should be communicated to customers in terms that make them

clearly understood from their perspective. This promotes a good level of
understanding and cooperation when service problems do occur.
Handling SLA
Contract
Changes
Processes should be in place to handle changes in service requirements.

Customers may wish to negotiate better service levels, add new functions that
require new levels of service or periodically renew current levels. These
should be negotiated through a Service Level Manager and processed via
Change Management.
Number of SLA
Contracts
Less is better, more greatly increases management overhead to report and

manage. It may be determined to have a single contract for all departments
versus multiple service contracts for different departments. Another structure
may be to have a base agreement that covers everyone as a default with a
limited set of overriding contracts for unique needs.
Continued on next page
-3-
Contract Areas to Consider, Continued

Types of
Service Targets
to Be Included
The types of service targets to be provided should be identified in the service

level contract. Examples of types of service targets include items such as:
Response Times
Availability Windows
Equipment Service And Repair Times
Technical Support Response and Level
Report Or Other Media Delivery
Security Access
Data Retention and Backup Requirements
Determining
Customer
Services
It will be necessary to identify what critical customer workloads are. From

this a specific service level can be derived. Workloads can be defined as one
or more customer functions that require service from IT. Examples of these
might include items such as:
Processing patient accounts in a hospital.
Entering orders from customers on a phone.
Accessing E-Mail.
Retrieving and creating memos.
Each of the above have an associated level of service that allows that function
to be accomplished successfully. This level might include availability of
service to that function. (i.e; E-Mail will be available from 8AM to 9PM on
weekdays). It might also include a level of response. (i.e; Order Entry
transactions on a terminal must provide a response time less than 5 seconds
85% of the time).
Most organizations have found it helpful to implement an ITIL Service
Catalog to better define what these services are. With this, the SLA contract
would only need to reference those service descriptions. The Catalog can also
serve to centralize all of these definitions in one place.
Multiple
Targets For
Services
It may desired to provide or negotiate multiple service levels for a single

customer service. An example of this might be negotiating a lower response
time for peak hours of the day and a higher response time at other hours.
Another example might be provision of high availability all the time but
specific functions or files may be unavailable at certain times of the day.
-4-
Contract Areas to Consider, Continued

Resolution of
Service
Disputes
It may be desired to put a process in place that fairly identifies resolutions to

problems or misunderstandings in service expectations. This may be a
committee of representative Customer and IT personnel without a direct
interest in the problems under discussion.
Operational
Level
Agreements
and
Underpinning
Contracts
In an environment where the service to be delivered is provided by multiple

departments, organizations or outside vendors, service boundaries must be
clearly defined. This identifies where responsibilities lie and what kinds of
services have to be delivered by each service delivery entity.
An example of this might include a client/server architected application where
end user response time service consists of both mainframe processing and
server/front-end processing. If these two components are managed by
different organizations, then each organization should set up an operational
level agreement.
As an example of the above, mainframe response time targets will be under 5
seconds 85% of the time, server processing will be under 3 seconds 80% of
the time. This would result in the actual service level to the customer of a
response time less than 8 seconds 80% of the time.
Service Targets
Must Be
Reportable
Any service level that is set must be able to be adequately reported on. It
would be useless to establish a service level for which monitoring data cannot
be collected. The operational efforts and costs involved with monitoring and
reporting on any given service level should be taken into account when that
level is set.
-5-
Contract Components
Overview
A Service Level Contract is a key component of a formalized service level

agreement process. Key components of this document are described in this
section.
Contract Dates
Starting and ending dates that the contract is to be in force. If ending dates are
specified, new service level agreements may have to be created for projects or
departments that function beyond the end dates.
Contract
Numbers
These may be necessary if negotiating multiple contracts. They simply

identify specific contracts.
Customer
Identification
Identifying information that describes the group of users who are included
within the scope of the contract.
Demand
Periods
It is helpful to identify periods of time in which types of use are likely to

make the greatest service demands on processing resources. Some targets
may differ depending on demand periods. For example, an E-Mail service
may have a lesser target for response time during the start of work when most
employees retrieve their messages. There may be a higher target for slower
periods later in the day.
Project or
Departmental
Description
A brief description of the department or project to be serviced. This may

include its main purpose or business function and how processing supports
the goals of that entity.
Expected
Service
Requirements
A description in clear concise terms of the service level targets to be delivered

by IT to support the department(s) or project(s) covered by the service
contract. These should be in business terms and from the customer
perspective as much as possible.
-6-
Contract Components, Continued

Service
Assumptions
If needed, this section can be included to describe any service assumptions

used to support the service levels being delivered. Examples might include:
A set number of customer users not to be exceeded
Specific IT capacities that might incur additional costs if exceeded
Allowances for special times of the day, week, month or year
Target
Calculations
Methodologies or calculations used to determine service expectations should

be documented. The purpose is to clearly state how service levels may be
calculated, measured and reported on.
IT Charging
Costs
Any assumptions or expected costs of delivering the service should also be

documented. Determination of costs is aided by the Capacity Planning and
Financial Management processes. In some cases, it may be necessary to
include a sample charging bill.
Contract
Maintenance
This section should describe the conditions under which the contract should
be changed. It should identify who is responsible for reporting on the quality
of service delivered and how service disputes may be resolved.
Contract
Responsibilities
This section should identify organizations or personnel responsible for

support activities related to Contract Maintenance, Service Level Reporting,
Service Level Dispute Resolution and Renegotiation of Service Levels.
Signature Block This section provides space for Customer and IT sign-off to the terms in the
contract.
-7-
Example Of A Service Level Agreement Contract

Introduction
The following pages present one example of a comprehensive Service Level

Agreement contract. This example is probably much more formalized than
necessary but illustrates some of the concepts discussed in this paper.
-8-
Example Of A Service Level Agreement Contract, Continued
SERVICE LEVEL AGREEMENT
Contract Date:
Expiration Date:
Agreement Number:
Division:
Location:
Project:
Peak Times:
This document with attachments specifies the agreement between the above named business unit
and the Data Processing Center (DPC) for shared computing services. This agreement consists of
the following sections:
Section I:
Services To Be Provided
Section II:
Expected Service Requirements
Section III:
Service Assumptions
Section IV:
Costs
Section V:
Contract Maintenance
Section VI:
DPC Responsibilities
Section VI:
Customer Responsibilities
Section VII:
Service Change Control Procedure
Section VIII:
Signatures
-9-
- 10 -
SECTION I: SERVICES TO BE PROVIDED

Business Unit Description, Business Unit Scope And Desired Services to be provided.
May provide references to ITIL Service Catalog here.
SECTION II: EXPECTED SERVICE REQUIREMENTS

Examples (May list for each service to be provided or reference ITIL Service Catalog):
Response Time Requirements:
Availability Requirements:
Report/Media Delivery Requirements
Data Retention and Back-Up Requirements:
Technical Support Requirements:
Job/Report Turnaround Requirements:
Security Requirements:
- 11 -
SECTION III: SERVICE ASSUMPTIONS
The services and costs within this agreement are based on the assumptions below. Any assumption
found invalid could have an effect on ability to meet service targets and/or costs charged for
services. Changes to assumptions will be handled in accordance with the Service Change Control
Procedure described in this agreement.
The service assumptions included with this agreement are:
SECTION IV: COSTS
RULE AND CHARGES APPLIED
COST FACTOR
------------------------------- Anticipated Costs Per Period ----------------------------Period 1
Period 2
Period 3
Period 4
- 12 -
SECTION V: CONTRACT MAINTENANCE
Terms for Renegotiation
Penalties/Rewards
Service Level Reporting Responsibilities
Service Problem Resolution Responsibilities

- 13 -

SECTION VI: DPC RESPONSIBILITIES
DPC will provide IT Service Management to control the services described in this agreement. DPC will
appoint a Service Manager who will have responsibility for:
Coordinating DPC activities and responsibilities to address any service issues that may
arise.
Interfacing with the customer Service Contact for service issues and requests for service
changes.
With the customer Service Contact, administer the Service Change Control Procedure
described in this agreement.
Delivering service reports to the customer Service Contact.
Maintain service communications and reviewing any service improvement actions and
progress with the customer Service Contact during execution of this agreement on a regular
basis.
- 14 -

SECTION VI: CUSTOMER RESPONSIBILITIES
This section identifies the customer responsibilities associated with this agreement. DPCs
performance is predicated upon the responsibilities identified below.
Prior to the start of this agreement, customer will designate a person, called the Service Contact
to whom all DPC communications will be addressed and who has the authority to act for
customer in all aspects of this agreement.
The responsibilities of the Customer Contact include:
Serve as the interface between DPC and all customer departments participating included in
the scope of this contract.
With the DPC Service Manager, administer the Service Change Control Procedure as
described in Section VII of this agreement.
Attend service status meetings.
Obtain and provide information, data, decisions and approvals, within 3 working days of
DPC's request unless DPC and the customer agree to an extended response time.
Resolve deviations from service assumptions which may be caused by customer.
Help resolve service issues and escalate issues within customers organization, as necessary.
The following responsibilities by appropriate customer personnel involved in this project are as
follows:
- 15 -

SECTION VII: SERVICE CHANGE CONTROL PROCEDURE
The following provides a detailed process to follow if a change to this agreement is required:
A Request For Change (RFC) will be the vehicle for communicating change. The RFC must
describe the change, the rationale for the change and the effect the change will have on the
services.
The designated contact of the requesting party will review the proposed change and
determine whether to submit the request to the other party.
The receiving contact will review the proposed change and approve it for further
investigation or reject it within three (3) working days. The investigation will determine the
effect that the implementation of the RFC will have on service targets, service charges and
service assumptions related to this agreement.
- 16 -
SECTION VIII: SIGNATURES

We have read the attached contract and terms and hereby forge an agreement according to the
conditions stated therein:
Date:
Business Unit Representative:

(signature)
DPC Representative:
Date:
(signature)
Other Representative:
Date:
(signature)
We understand that these services may be extended via the Service Change Control Procedure
included in Section VII of this agreement.
- 17 -

ITS M: Service Level Agreements Sample Agreements, Reports, and Checklists

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ITS M: Service Level Agreements Sample Agreements, Reports, and Checklists

Caricato da

Copyright:

Formati disponibili

RL Consulting

People Process Technology

May 25, 2002

Copyright 2002 RL Consulting. All rights reserved.

ITSM - SLA SAMPLES

Service Level Agreement Sample #1

ITSM - SLA SAMPLES

Service Level Agreement Sample #2

II. IT SERVICES PROVIDED

The ORDER System will be available in "inquiry" mode during backups.

ITSM - SLA SAMPLES

ITSM - SLA SAMPLES

ITSM - SLA SAMPLES

OPERATIONS & SERVICES

1. Computer Operations and Batch Services

ITSM - SLA SAMPLES

PROCEDURE FOR UNSATISFACTORY SERVICE

III. CLIENT RESPONSIBILITIES

ITSM - SLA SAMPLES

ITSM - SLA SAMPLES

Service Level Agreement Report Sample #1

Order Processing Department SLA Detail Report

IDMS < 2 Sec

IDMS < 5 Sec

ORDER Dial-up (sec)

TSO < 5 Sec (All Shifts)

TSO < 2 (1 & 2 Shifts)

TSO < 2 (3rd Shift)

Terminal Prob Resp (2hr)

Help Desk Calls

Tape Mount Wait Avg. (min)

ITSM - SLA SAMPLES

Service Level Agreement Checklist Sample #1

ITSM - SLA SAMPLES

ITSM - SLA SAMPLES

ITSM - SLA SAMPLES

ITSM - SLA SAMPLES

Service Level Agreement Sample #3

Provider Approval Date -

Customer Approval Date -

Building Service Level Agreement Contracts

This publication contains the following topics:

Why Have Service Level Agreements?

Key goals of undertaking formalized service arrangements are as follows:

Contract Areas to Consider

The following section presents a number of key areas to consider when

Targets should be communicated to customers in terms that make them

Processes should be in place to handle changes in service requirements.

Less is better, more greatly increases management overhead to report and

Contract Areas to Consider, Continued

The types of service targets to be provided should be identified in the service

It will be necessary to identify what critical customer workloads are. From

It may desired to provide or negotiate multiple service levels for a single

Contract Areas to Consider, Continued

It may be desired to put a process in place that fairly identifies resolutions to

In an environment where the service to be delivered is provided by multiple

A Service Level Contract is a key component of a formalized service level

These may be necessary if negotiating multiple contracts. They simply

It is helpful to identify periods of time in which types of use are likely to

A brief description of the department or project to be serviced. This may

A description in clear concise terms of the service level targets to be delivered

Contract Components, Continued

If needed, this section can be included to describe any service assumptions