Operational Level Agreements (OLAs) are essential to service level management. ABIT Puresoft utilizes them to outline how we plan to deliver services and track performance indicators to internal customers – such as response time for incidents assigned to IT groups or the availability of servers supporting various applications.
OLAs define the roles and responsibilities of each department, requiring working collaboratively with others to set realistic expectations about services and associated logistics. ABIT Puresoft usually includes one or more objectives or service targets in each OLA.
In ITIL and ITSM frameworks, OLAs describe the operational relationships between an IT service provider and another part of the IT organization, including those between:
- Service Desk
- Support Group(s)
- Incident Resolution
- Network Management
- Operations Management
Efecte and most ITSM tools provide ways to measure OLA and related statistics. Efecte allows organizations to calculate OLA breaches based on what was configured. The platform’s reporting capabilities allow clients to report key metrics in order to improve service quality and shape best practices.
Operational Level Agreements differ from Service Level Agreements (SLA), which deal with obligations towards external clients. We see the main difference between OLAs and SLAs as representing different commitments – the former towards internal groups within the organization and the latter towards the client. In addition, OLAs usually have a smaller target group compared to SLAs, being more focused on technical aspects.
In the below graphic we’ve illustrated the relationship between the OLA and the SLA:
Understanding the distinction between OLAs and SLAs and how they work together is important to ensure that all internal and external resources are aligned when it comes to providing services to the end-user.
Because delivery of the SLA depends upon the promises and limitations outlined in the OLA, we recommend designing the OLA in a way that supports the SLA and avoids breach scenarios. Since various teams can be involved in solving a ticket, it’s critical to measure the time each team spent on the ticket so that it is easy to know which team was responsible in case of an SLA breach. This is why it’s important to define operational level agreements for various teams based on historical data.
Best practices for writing an OLA
Whether you’re creating a one-off OLA or a template for all future OLA documents, we have some useful tips and tricks to share:
Write two short paragraphs to briefly inform the reader of the objectives, targets, and goals of the OLA.
Include detailed information regarding present challenges and how the OLA will serve to resolve them.
Define the service and compliance targets in detail. Optionally, include milestones and list actions associated with each milestone.
List all parties (people and entities) involved in service management and the fulfilment of SLAs.
Fully document hours of operation, service hours, response times and escalation policies.
Outline the method(s) of communication that parties must adhere to throughout the OLA duration.
The document needs to be kept on a secured server, where it can be easily accessed by others. Make sure you’ve indicated the authority of each signer to the document and attach appendices as needed with additional information.
Overall, Operational Level Agreements ensure consistent levels of quality, provide transparency across the organization and to the client, and define standards of accountability for everyone.
