This is an example Operational Level Agreement (OLA)
between Integration Services and its various partners in providing service to our clients.
1 General Overview
This document represents an Operational Level Agreement (“OLA”) between Integration Services (“DS·IS”) and other Service Providers to describe the working relationships and response times for supporting [integration service].
The purpose of this OLA is to ensure that the proper activities and commitments are in place to provide consistent service support and delivery by the Service Providers.
The goal of this OLA is to obtain mutual agreement for collaboration between units.
The objectives of this OLA are to:
- Provide clear reference to service ownership, accountability, roles and responsibilities.
- Match perceptions of expected service provision with actual service support and delivery.
This OLA is valid from {begin date} to {end date}.
DS·IS is responsible for facilitating regular reviews. It will be reviewed at a minimum once per fiscal year; however, failure to complete a review will leave the current OLA in effect.
This OLA may be amended as required, provided mutual agreement is obtained from the stakeholders and communicated to all affected parties. DS·IS will incorporate revisions and obtain mutual agreements and approvals as needed.
This OLA will be posted here and made accessible to all stakeholders.
2 Service & Dependencies
2.1 Service Scope
{integration service technical description}
[integration service] is clearly documented here, representing the current configuration to support the service.
Service design changes are handled as projects, which is outside the scope of this OLA.
Funding for major upgrades/updates will be negotiated on a service-by-service basis.
2.2 Service Dependencies
These services are necessary elements of [integration service] to function as designed:.
- [supporting service]
- [supporting service]
- [supporting service]
2.3 Service Charges
As of July 1, 2020, there is no charge for the service.
3 Responsible Parties
The following Service Providers are associated with this OLA:
| Service | Provider | Contact Information* | Normal Hours |
|---|---|---|---|
| [service] | [provider] | [contact] | [hours] |
| [service] | [provider] | [contact] | [hours] |
Phone numbers are not to be used outside normal hours unless specified in section 4.
See section 5.5 for exceptions to normal hours.
4 Roles & Responsibilities
Responsibilities and/or requirements for all Service Providers in support of this OLA include:
- Meet response times associated with the priority assigned to incidents and service requests.
- Train responsible staff on appropriate service support tools {cite examples for this service}
- Notify customers and all dependent services of all scheduled changes via the Maintenance Calendar, Service Catalog web page and/or a communication to campus via the Communication Specialist.
- Participate in all service support activities including incident, problem, change, release and configuration management.
- Meet SLA metrics as stated in the [integration service] SLA located here
- {Additional requirements}
Responsibilities and/or requirements for specific Service Providers follow:
DS·IS agrees to:
- Non-Network Server Hardware support and configuration, and act as a liaison to the Server Hardware Vendor(s) for problem reports and incident handling, EXCEPT for the Servers which are hosted in the VM infrastructure.
- Non-Network Server Operating System support and configuration, and act as a liaison to the Server Operating System Vendor(s) for problem reports and incident handling.
- Non-Network Server Application Software support and configuration, and act as a liaison to the Server Application Software Vendor(s) for problem reports and incident handling.
- Provide expertise to handle user support cases that the Support Centre needs to escalate to Productivity Tools.
- Act as liaison to Purchasing to set up support contacts for hardware and software.
[Service Provider] agrees to:
- Verification of client eligibility
- Diagnosis and investigation of problems, incidents and requests for information regarding the Mail included using and configuring filters (rules), spam scanning, client software and the webmail client
- Writing end-user documentation, technical descriptions, work-arounds, and support documentation for its technicians
- Client software testing and recommendations
- Account provisioning and testing
- Coordinates major incident handling.
[Service Provider] agrees to:
- Maintain and enforce secure physical access to Data Centre facilities
- Monitoring of hardware, software, services and environments
- Escalate detected problems/events (via monitoring or physical inspection) to the appropriate parties per procedures established within ITS and/or procedures established with stakeholders
- Serve as initiation/coordination point for major incidents
- Perform and manage system backups
- Perform and manage manual processing or operational tasks for stakeholders
5 Request, Incident, Problem & Change Management
5.1 Service Requests
Standard Requests
Standard expected requests for [integration service] are:
- [request]
- [request]
Ad-hoc Requests
For example:
- [brief example]
- [brief example]
{Describe how each ad-hoc request is to be processed so that it gets evaluated by the most appropriate staff member or service team.}
5.2 Incident Management
Normal Incidents
Service Providers supporting [integration service] will prioritize incoming incidents based on the following criteria:
- Number of departments or persons affected.
- Impact on academic or administrative function.
- Risk to safety, law, rule, or policy compliance.
- First-come, first-served basis (above criteria being equal)
When a new incident is opened by a caller:
- Service Providers will triage new incidents and respond to the caller within two business hours.
- For "High" priority incidents, Service Providers will update status at least every two business hours.
- For all other incidents, Service Providers will update status as it changes.
Major Incidents
A Major Incident (“MI”) will be created and the MI process will begin under the following circumstances:
- Circumstance 1
- Circumstance 2
Major Incidents will be managed jointly by:
| MI Role | Contact | Back up Contact |
|---|---|---|
| Tech Lead | [name-phone-etc] | [name-phone-etc] |
| Coordinator – Normal Hours | [name-phone-etc] | [name-phone-etc] |
| Coordinator – After Hours | [name-phone-etc] | [name-phone-etc] |
| Functional Expert | [name-phone-etc] | [name-phone-etc] |
| {other} | [name-phone-etc] | [name-phone-etc] |
Documentation of the roles, responsibilities, and flows of the MI process is located here.
5.3 Problem Management
{Describe process for dealing with root cause problems (as opposed to incidents).}
5.4 Change Management
Service Providers for [integration service] follow the Change Management Process documented here.
Pre-approved ("Standard") changes established for [integration service] are:
- change
- change
Service Providers for [integration service] adhere to a system freeze (“no fly”) rule during the periods:
- period
- period
[integration service] requires regularly scheduled maintenance in order to meet established service levels. These activities will render systems and/or applications unavailable for normal user interaction during the following timeframes (“Maintenance Windows”):
- window
- window
5.5 Service Exceptions
Any deviations from current policies, processes and standards are noted by the following exceptions:
| Exception | Parameters | Coverage |
|---|---|---|
| Federal holidays | [definition] | [coverage] |
| University holidays | [definition] | [coverage] |
| Campus closures | [definition] | [coverage] |
| {other} | [definition] | [coverage] |
6 Metrics & Goals
The following metrics monitored internally for actions listed in Section 5 will be reported [intervally] and made accessible here:
| Metric | Units | Goal |
|---|---|---|
| [metric] | [units] | [goal] |
| [metric] | [units] | [goal] |