A concise manual on operational-level agreements (OLAs)

An operational-level agreement, commonly referred to as an OLA, is essentially a set of standards set by an organization that stipulates and standardizes the interdepartmental interactions while fulfilling the service.

When fulfilling an common objective involving several teams, an OLA can define the tasks responsible for each team, the duration a team can work on a specific task, the resources that a team is eligible for, and in some cases, even the pricing of the various tasks that a team can charge the organization.

The goal of an OLA is to clearly describe and measure interdepartmental relationships while working on a collaborative activity.

Within ITSM practices, an OLA defines the relationship between the IT service desk, and other internal departments, while delivering a service to an end user. The OLA is a formal contract that defines the service level targets for each department, the objectives assigned to each stakeholder, and the responsibilities of the internal departments.

An IT service desk often collaborates with other departments and teams, such as the HR department or the network management team, to provide a service for the end user. Since the IT service desk is often the origin of the service request or incident ticket, they are accountable for the service delivery experience. All the other participating departments are accountable only for their share of tasks while fulfilling the service. The teams or departments apart from the IT service desk are one step away from the end user, and the other participating teams or departments have their own objectives that do not concern service delivery experience.

Therefore, the IT service desk carries the responsibility of adhering to a service-level agreement (SLA), which is is an agreement between a service provider and an end user.

To help adhere to the SLA, IT service desks can standardize their working relationship with other departments and subteams through OLAs.

Let's see an example of how OLAs helps

Zylker, a large enterprise, has hired a new employee and the HR team has raised a new onboarding request in its IT service desk portal. The IT services team notes that the request will take seven business days, as stated explicitly in its SLA.

With an open request, the IT team is reliant on a few subteams to complete the process. The IT services team is responsible for these activities:

• Create a user account in the enterprise directory
• Raise a new asset request
• Configure the machine with the relevant software
• Encrypt the new asset
• Complete cybersecurity and privacy training

To ensure the SLA isn't breached, the IT services team sets up an OLA with the procurement team, receiving the assurance that a new workstation will be delivered from the vendor in three days. With the identity management team, IT services establishes an OLA to enroll the new user in the organization directory within one business day. The IT services team takes a day to install the relevant software and encrypt the user's device. Finally, the privacy and security teams are responsible for briefing the new employee about the ins and outs of enterprise data confidentiality, user privacy, and asset security. These teams advise the IT services team that they need one business day to complete these OLA tasks. To summarize the process of using OLAs, the responsibilities within a service request are broken down and shared in a standardized manner with the respective subteams.

Typical OLA tasks and SLA targets

Based on the OLAs, the new employee onboarding service typically would be completed in five business days. However, there could be unforeseen delays, and the service level targets provide important guidelines for how much of a delay (or an OLA breach) is permissible for the service. Further, the SLA also accommodates potential delays by adding a two business day buffer to its fulfillment time. This ensuring that IT services almost always aligns with the SLA timeline, underpinned by comprehensive OLAs.

• Standardizes the back-end service delivery activities: OLAs offer clarity to the subteams and departments involved in the service. Every task that needs to be completed is stated, with respective departmental point of contacts (POCs) to clear up doubts, and the expected timeframe for the activity. It also sheds light on the escalation activities in the event of an OLA breach. When a new technician joins the team, they can easily refer to the OLA if they have questions during the service fulfillment process, enabling fast and sustainable growth of the service teams. OLAs enables service departments to scale up efficiently as the business grows.
• Provides scope to innovate for service providers: When OLAs standardize the back-end service fulfillment operations, it frees service leaders from efficiency worries, unforeseen delays, and SLA breaches. Service leaders can work on improvements to their services, focus on employee experience initiatives, and spend meaningful time to analyze service consumption and feedback. Further, OLAs also often include a clause to reevaluate the timeframes, to check if it still aligns with the business growth and end-user demands. Through this clause, service leaders can also conduct continuous improvement efforts as well.
• Improves the rapport between the end users and the IT service desk: OLAs leave a good impression with the end users about the service providers. Since OLAs facilitate better SLA adherence, they lead to greater customer satisfaction, better opinions about the provided services, and subsequently help increase the productivity of the workforce. Also, OLAs often have their own KPIs, which helps to quantify the value the IT service providers offer in terms of productivity to an organization.

This example gives a good impression of where an SLA fits compared to an OLA. To put it simply:

An SLA is an agreement between the IT service provider and the end user in the organization, where the agreement stipulates the duration required for service fulfillment, and the service quality needs to be maintained during service delivery.

An OLA is an agreement between internal departments and the IT service provider to deliver a service efficiently without breaching the SLA to the customer.

Here is a quick comparison highlighting both the common and the different components between the SLAs and OLAs.

An OLA is a joint effort, so it can only be effective with the cooperative of all internal service provider teams, both IT and non-IT. With all the service providers ready to comply with the OLA standards, here is how a typical OLA draft is prepared:

• Begin the OLA with a brief about the objectives or the results to be achieved from the agreement. This ensures that all the participating departments obtain perspective about how the service matters to the organization. Ensure the brief also includes the list of the service providers to be involved in the OLA.
• Add a section where your team describes the challenges and repercussions faced in delivering the service. This section, along with the brief mentioned above, should give a complete picture of why an OLA is important for the particular service and how the service benefits the organization.
• Now, include the time frames to be mentioned in the OLAs. The timeframes include the duration of the contract eligibility before review, the service availability time, the resource availability time, and any other exceptions for these. Ensure there aren't any conflicting contracts operating within these timeframes.
• Once the timeframes are set, begin describing the service requirements and the responsibilities of each internal service provider. This step constitutes the crux of the OLA, so try to be as detailed as possible. Ensure the section covers all the possible scenarios of service requests, so there aren't doubts about the scope or misinterpretations later.
• With the service requirements completed, list the assigned roles for service technicians and agents during live operations. Mention the POCs from each service department, the reporting manager for every stakeholder, the access privileges for every role, and other necessary individuals involved in providing a smooth service delivery. The goal of this step is to inform every participating individual about the role they will be playing during service delivery.
• Next, mention the KPIs to be tracked, for performance review. The KPIs should be explicit for both the individuals and the overall performance goals of the service provider team.
• An important step is to draft the escalation process when a breach occurs. The escalation process should clarify the measures to take to ensure the service is provided as soon as possible. For all steps, indicate the person authorized to manage service request escalations and state the actions to be taken in such a scenario.
• Finally, summarize the OLA and add any niche terms and conditions pertaining to your organization. Attach the necessary reference documents as appendices. Review the document and implement necessary modifications, but your OLA should now be ready to be jointly signed by the participating departments.

Implementing an OLA can facilitate an uptick in your service delivery efficiency. Here are a few helpful pointers to keep in mind when you try to implement them in your organization.

• An OLA can only be as good as your organization's management allows it to be. Management needs to have the full buy-in to the OLAs, and should enforce them with right-sized incentives and penalties, for teams charged with adhering to them.
• Always keep OLAs simple. The internal service departments want to help deliver excellent services, but the longer the OLA, the more complex it can be to clearly communicate its requirements. It's advisable to keep the service availability and fulfillment requirements short. Any niche scenarios can be added to their own separate section.
• While drafting the OLA, be sure to add all the information that would be useful for service providers during service delivery. Be open to adding any relevant illustrations, contact information of key stakeholders, FAQs, and highlights to terms that are easy to overlook. The goal is to provide as much clarity as possible to avoid service disruption and to avoid delivering the wrong service.
• OLAs should be tested thoroughly before they are actually implemented. The tests ensure that the agreed upon timelines function in the production environment as forecast.
• Be sure to track your OLAs. Set the KPIs and other performance metrics to be followed, authorize a group to enforce the OLAs, and ensure compliance to the OLA standards.