Jump to Section
Operational level agreements (OLAs) are essential to service level management. The relationship involves working collaboratively with others to set realistic expectations about services and associated logistics. An OLA can help you manage the relationships with those you serve internally.
This article describes what IT providers need to know:
What is an Operational Level Agreement?
Operational level agreements (OLAs) are internal documents that outline how information technology (IT) companies and service providers plan to provide a service and track performance indicators to an internal customer. An OLA aims to define the scope and depth of responsibilities and duties by company departments.
These contracts are different from service level agreements (SLAs) , which address external customer needs. SLAs are agreements between a service provider and an external customer, while OLAs are agreements between internal providers and internal customers.
Examples of Operational Level Agreements
OLAs require you to make critical promises to internal customers. Their ability to generate revenue depends upon your ability to deliver on service and hardware. For instance, every OLA must guarantee that the customer experiences no more than a certain amount of downtime.
Let’s look at a hypothetical example of OLAs between an IT vendor and an internet service provider (ISP) to make this point more clear:
- An IT vendor supports a database for Company A, an ISP
- Company A provides Internet SLAs to external customers
- Company A signs an OLA with the IT database vendor
- The IT vendor OLA states that they must provide 23 hours of daily uptime
- Company A can claim financial damages for excessive downtime
- Conversely, IT vendors meeting standards will retain customers
As you can see, the SLA dramatically depends upon the promises and limitations outlined in the OLA. Due to their complexity, you should draft, negotiate, and finalize your OLAs thoroughly and include some critical terms that protect your company’s fiduciary interests.
Common Terms in OLAs
Like any contract, an OLA contains some necessary provisions that establish the terms and conditions of the relationship, such as roles, responsibilities, and limitations. While the OLA includes many of the same components found in a standard contract, some clauses make them unique.
Common terms in OLAs include the following:
- General Overview: This section of an OLA sets the stage for the relationship, identifies parties, and establishes the relationship’s objectives. You should include references to accountability, roles, and responsibilities. The general overview also delineates a contract’s start and end date.
- Service Scope: This section offers the technical description of the service provided. It should also account for updates and upgrades, and tasks that go beyond the scope of the OLA.
- Service Dependencies: In this provision, list the supporting services dependent upon the vendor’s deliverables. This section may also weigh heavy on the technical aspects of this agreement.
- Responsible Parties: If an issue arises, the internal customer needs to know how to contact the responsible parties. In this section, vendors should include the names, hours, telephone numbers, and emails of individuals they can reach.
- Roles and responsibilities: This section addresses how all involved parties play a role in service delivery. Describe training measures, meeting times, and change notification measures. You should also include the activities in which the vendor must participate.
- Incident Management: Transparency must exist between vendors and service providers. This section of your OLA should list standard expected and ad-hock requests and how they agree to process them. It is vital to segment the process by normal and major incidents.
- Problem Management: If an incident arises, the internal customer also needs reasonable reassurance that you can handle them. A problem management section allows the IT vendor to list ‘what-if” scenarios and communicate the contingencies and actions to resolve discovered issues.
- Service Exceptions: This provision is vital since it also limits the scope and depth of your relationship in terms of incident and problem management. It is unfair that a vendor address problems outside of its control. Outline the exceptions in this section.
- Metrics and Goals: Key performance indicators (KPIs) are a significant component of the OLA relationship. The company should request that the vendor monitors specific metrics and make them available to key team members.
Your OLA may need to address issues that are specialized for your industry. Technology lawyers can review your situation and system and produce a thorough, valid, and enforceable document.
This article also contains information about common terms in OLAs.
Types of Operational Level Agreements
Operational level agreements often work in tandem with a few other contracts. This strategy gives SLA provider reassurance to external customers, making reviewing and negotiating the OLA beforehand even more critical. Both arrangements also protect every party’s rights during the relationship.
There are three types of contracts generally involved in operational level agreements:
- Type 1. Service Level Agreements (SLAs): SLAs are contracts between a service provider and an external customer. They specify the scope and quality of the services covered. An SLA establishes the timelines by which tickets must be accepted and resolved before escalation.
- Type 2. Operation Level Agreements (OLAs): OLAs are agreements between an internal service provider and an internal customer. They specify the scope and quality of the services covered by the contract, including ticket response time and server availability.
- Type 3. Underpinning Contracts (UCs): UCs are an agreement between an external provider and an internal customer. They define the scope and range of the services covered. A UC aims to ensure reliable service from the external provider and hold companies accountable.
You should consider your relationship with each stakeholder in the process. You may need a combination of two agreements, whereas some companies may need to create more. The contract you put in place depends upon your company’s specific situation and dynamics.
Image via Pexels by Manuel Geissinger
Difference Between OLAs and SLAs
It is common for service providers to negotiate SLAs with clients before discussing and negotiating OLAs with internal teams. However, this approach is not necessarily the most practical. An OLA helps teams identify any cost differentials, constraints, and other dynamics while SLAs make promises to customers directly.
Here are four other differences between OLAs and SLAs:
- Difference 1. SLAs exist between a service provider and an external customer. OLAs exist between the internal support departments of an organization that agreed to the SLA.
- Difference 2. SLAs concentrate on the service aspect of the agreement, such as availability and performance. In contrast, OLAs represent commitments to maintain the service.
- Difference 3. SLAs apply to the overall resolution of tickets, whereas OLAs are specific to the support teams to which tickets are assigned.
- Difference 4. OLAs involve more technical terms, measurements, and language than SLAs.
From the list outlined above, you can see that SLAs and OLAs are distinctly different documents that should work in accordance to produce the best result. Mistakes in the OLA drafting and negotiation process can result in unintended legal and financial consequences. As such, you should always get legal help from an experienced lawyer when working with OLAs.
For more information about how SLAs work, check out this blog article.
Get Help with OLAs
The terms of a contract must generally meet your business requirements to serve business needs. Technology lawyers can review the proposed agreement with you before negotiating it while simultaneously identifying potential issues. During the contract drafting process, your lawyer ensures that you receive a fair OLA while understanding its legal implications.