<Service Name>
Operational Level Agreement
Effective Date: mm/dd/yyyy
#
0.0
Section
Agreement
Approval
(Who are the
stakeholders
responsible for
adhering to this
agreement?)
1.0
Executive
Summary
(Why this document
exists?)
2.0
Support Service
Summary
(What is being
supported and how
the support will be
provided and to
whom?)
Next Review Date: mm/yyyy
Details
By signing below, all Approvers agree to all terms and conditions outlined in this Agreement.
Name
Role/Title
Signature
Date
OLA Overview:
The purpose of this Operational Level Agreement (OLA) is to ensure that all the support elements and commitments are in place to
provide consistent high-quality service support and delivery to the Carnegie Mellon community by Computing Services.
Goals and Objectives:
The goal of this Agreement is to obtain mutual agreement for service provision among the support roles within the Service Team.
The objectives of this Agreement are to:
 Provide clear reference to service ownership, accountability, roles, responsibilities and dependencies.
 Present a clear, concise and measurable description of service delivery expectations. (Goals for service delivery; ensure
SLA(s) terms can be met. Ex. High availability service)
 Document the service team’s expectations and responsibilities associated with each of the roles.
Support Service Description:
Detailed description explaining the details of the support service being provided.
Customers Served:
What customers will be served through this agreement?
https://www.cmu.edu/computing/ppmo/ola-development/index.html
For Internal CMU Use Only
1 of 4
<Service Name>
Operational Level Agreement
Effective Date: mm/dd/yyyy
3.0
Support Service
Roles and
Responsibilities
(Who is responsible
for what to support
the service?)
4.0
Service
Availability
Next Review Date: mm/yyyy
The following roles are necessary for supporting this service. These members represent the primary stakeholders associated with this
OLA and are responsible for the deployment and ongoing support of the agreement. Any of the following stakeholders may initiate OLA
review.
Role
Responsibilities
Name/Group(s)
Contact Information
Primary Support Hours
Service Owner
The individual responsible for
guiding the strategic direction of
the service
Service Manager
The individual who has the
authority to make decisions
regarding the day-to-day
operations of the service
First Line
Receives initial contact from the
Customer Support
customer and provides initial
support to incidents and service
requests
Second Line
Provides in depth troubleshooting
Customer Support
of the incident or request after
first line customer support
Documentation
Provides the customers
Manager
documentation about the service
Communication
Provides the customers official
Manager
communications regarding the
service
Additional
Additional
Additional
Additional
24 x 7 x 365 or OTHER
(When is the service
available?)
5.0
Support Hours
M – F 7:00am – 7:00pm or OTHER
(When is support
available to the
users?)
https://www.cmu.edu/computing/ppmo/ola-development/index.html
For Internal CMU Use Only
2 of 4
<Service Name>
Operational Level Agreement
Effective Date: mm/dd/yyyy
6.0
7.0
Maintenance
Windows
Standard Service Maintenance Window:
What are the known standard maintenance windows for this service?
(What are the
maintenance
windows for the
service?)
Critical No Maintenance Periods:
When should not maintenance be scheduled due to critical business operations?
Incident
Response
Times
(These are standard
response times
between
escalations.)
8.0
Next Review Date: mm/yyyy
Priority Level
Critical
High
Normal
Definition
Customer(s) are unable to work due to a 24 x 7 x 365 service (per Service Portfolio) being
unavailable.
Customer(s) are unable to work or their work performance is degraded with a workaround
due to a service being unavailable.
Customer(s) are able to work and work performance is not impacted or the customer
states there is no immediate need for response.
Escalation
Process
Standard Hours Escalation Process:
Insert the escalation process flow diagram during standard business hours.
(How are incidents
escalated through
the support
process?)
Off-Hours Critical Escalation Process:
Insert the escalation process flow diagram for critical incidents during off-hours.
Max. Response Time
1 hour
4 business hours
1 business day
Problem Management Escalation Process:
Insert the escalation and management process for incidents that become systemic problems.
9.0
Support Metrics
(What metrics will be
collected to measure
the support
process?)
10.0
Metric data will be collected and formatted per the reporting frequency by the PPMO. The Service Team will analyze the metric data at
the regularly scheduled service team meetings.
Metric
Total # of incidents
% of First Time Resolution
Resolution Time
Data System
Responsible Party
Support Team
Meeting
The PPMO will schedule and facilitate the Support Team Meetings per the following frequency.
(How often should
the support teams
defined in section 3.0
Quarterly, Every Semester
https://www.cmu.edu/computing/ppmo/ola-development/index.html
For Internal CMU Use Only
Reporting Frequency
Quarterly
Quarterly
Quarterly
3 of 4
<Service Name>
Operational Level Agreement
Effective Date: mm/dd/yyyy
Next Review Date: mm/yyyy
meet to discuss the
support metrics and
process?)
11.0
OLA Review
Conditions
(What conditions
trigger a review of
the OLA?)
12.0
OLA
Termination
Conditions
OLA Change Triggered Review:
The following changes will trigger a review of the OLA. When one of the following occurs or is anticipated it is the team member’s
responsibility to contact the Information Process Specialist who will coordinate the review process.
 Any change to availability of the service/a service component.
 The addition or removal of a role, or changes to role definitions in the OLA will trigger a review.
 Team member changes (a team member changes responsibilities or is no longer responsible for a role)
 Changes in business continuity requirements for the service.
 Delivery of tactical projects concerning the service or one of its components.
 Completion or changes to the service portfolio document for this service (including addition and removal of service components
and changes in dependent systems).
Metric Trigger Review:
 Any unplanned full outage of the service.
 Any outage that lasts longer than 8 hours.
 Consistent failures of a component within the system.
Termination of service is always a condition for the termination of this OLA. All other questions about termination need to go through
the OLA review process managed by the PPMO. If any stakeholder raises question about viability of the OLA they should contact the
PPMO to discuss.
(How does an OLA
get terminated?)
A
Rev. #
Addendum
Revision Date
Add additional supporting information here.
Description of Change
https://www.cmu.edu/computing/ppmo/ola-development/index.html
Change Authors
For Internal CMU Use Only
4 of 4