ServiceNow OLA Explained

What Is an Operational Level Agreement?

An Operational Level Agreement (OLA) is a commitment between internal teams about how they will support each other. Where a Service Level Agreement (SLA) is a promise to customers about service delivery, an OLA defines what one part of your organisation will do for another. A support team might commit to responding to incident escalations within one hour. A networking team might commit to provisioning new circuits within five business days. These internal commitments drive how services are delivered to customers.

OLAs typically define response times, resolution times, or handoff quality. They create accountability between teams and make expectations explicit. When teams know what to expect from each other and measure whether they meet those expectations, communication improves and customers experience better service.

Where OLAs Live in ServiceNow

In ServiceNow, OLAs are configured alongside SLAs in the Service Portfolio section. They attach to services, not directly to individual tickets. When an incident or request is classified as part of a particular service, any OLAs that apply to that service activate. The system tracks whether the OLA is being met and escalates if it looks like the deadline will miss.

OLAs work with workflows to drive automation. When an incident is escalated to a support team, an OLA timer starts. If the escalation is not resolved or handed back within the OLA time, an automatic escalation might trigger. This automation means that OLAs drive behaviour: teams stay aware of OLA deadlines and prioritise work accordingly.

A Worked Example

Consider a support desk that handles customer requests but escalates network provisioning requests to a network team. The service includes an SLA of four-hour first response to customers. To meet that SLA, the support desk needs the network team to acknowledge the request within one hour. An OLA defines this one-hour commitment. When the network team receives an escalated request, the OLA timer starts. If the team hasn’t responded within an hour, an escalation alert fires, ensuring the request doesn’t slip.

This OLA exists between internal teams but enables better customer service. The network team doesn’t directly commit to customers, but their internal commitment to the support desk helps the support desk meet customer commitments. This linking of OLAs to SLAs ensures that internal teams understand how their performance affects external service delivery.

Common Misunderstandings

A frequent misunderstanding is treating OLAs as customer commitments. OLAs are internal; customers usually don’t see them. They exist to ensure that internal coordination happens reliably. Another confusion arises from mixing OLAs with SLAs: they’re related but distinct. SLAs are customer commitments; OLAs enable meeting them.

Many organisations also mistake OLAs for operational metrics like average resolution time. OLAs are specific time commitments for individual tickets, not averages. An OLA commitment is met or missed for each ticket; you can’t average your way to meeting an OLA that you often miss. This distinction matters: meeting most OLAs is not meeting OLAs.

OLAs and SLA Relationships

OLAs and SLAs work together. For a customer SLA to be achievable, the internal OLAs that support it must be realistic. A two-hour customer response time requires OLAs that ensure internal teams can respond within two hours. If you promise customers a two-hour response but set OLAs that allow four hours, you’ll regularly miss customer commitments.

Many organisations build OLA tiers that nest within SLAs. A four-hour customer response SLA might include OLAs that give the first team one hour, then the escalation team three hours. This nesting ensures that each team understands their time window and coordinates timing properly.

Related Concepts

OLAs relate to several other service management ideas. Target response times are similar but often used informally without the same tracking rigour. Escalation paths describe what happens when an OLA is at risk, but the OLA itself triggers the escalation. Service dependencies describe which teams support which services; understanding these dependencies helps define realistic OLAs.

Workaround agreements and underpinning contracts are close cousins of OLAs. An underpinning contract defines what a vendor will deliver; an OLA defines what an internal team will deliver. When your organisation depends on a vendor, the vendor’s commitments in their contract should align with your OLAs to your customers, otherwise you risk promising more than you can deliver.

Setting Realistic OLAs

OLAs should be achievable and meaningful. A commitment to respond in five minutes might be unrealistic for most scenarios; a commitment to respond in one week is so loose that it doesn’t drive behaviour. Effective OLAs typically fall between one hour and five business days, depending on the type of work. They should reflect what teams can actually do, not aspirational hopes.

OLAs should vary by urgency or type of work. A critical incident might have a one-hour OLA while a standard request might have a one-day OLA. Different tiers of service get different OLAs. This variation keeps teams focused on priorities and prevents every request from demanding urgent response.

Deciding which handoffs deserve an agreement at all

An operational level agreement earns its place only at a handoff where delay is visible to someone outside the team and the delay has an owner who can change it. Writing an agreement for every internal step produces a thicket of targets that nobody reads. Start with the handoffs customers actually feel. A ticket that waits in a holding queue for another team, a change that stalls while a reviewer is on leave, an access request that needs a second approval: those are the points where a shared expectation changes behavior. Note the receiving team, the sending team and the customer-facing measure each handoff affects. Only the handoffs that touch a customer measure need an OLA in the first round.

Handoff type	Agreement worth writing	Usually better handled another way
Escalation from a front-line queue to a specialist group	An acknowledgement expectation that the specialist group signs	Routing rules that reassign automatically when a queue is idle
Dependency on a platform or infrastructure team	A response expectation for the requests that block customer work	A standing meeting when the volume is low
Hand back to the originating team after a fix	A confirmation step with a named receiver	A notice that nobody is required to answer

Writing an OLA that a team will actually accept

The agreement is only as good as the conversation that produces it. The receiving team needs to say what it can commit to on a normal day, and the sending team needs to say what the customer will experience if the commitment is missed. Negotiate the number from the receiving team’s real capacity and from the customer’s real tolerance, rather than from the SLA the sales team already promised. An OLA that is tighter than the team’s capacity will be missed every week, and the team will stop believing any of the numbers.

1. Map the handoff end to end, naming the event that starts the clock and the event that stops it.
2. Agree the pause conditions, such as waiting for the customer to reply or for a change window to open, and write them as states the platform can read.
3. Choose the target with the receiving team, using their recent history as the starting point.
4. Name one owner on each side who answers for breaches, and one reviewer who sees both sides each month.
5. Configure the agreement against the service, test it with a record in each state, and only then announce it.

Failure patterns that quietly defeat the agreement

The clock that never stops is a common problem. An OLA that keeps counting while the record waits for a customer makes the receiving team look slow when it is not, and the team quickly learns to ignore breaches. The reverse problem is a clock that stops too easily, because every state change is treated as a pause. Either way the number stops meaning anything. A second pattern is an OLA attached to the wrong service, so the breach is recorded against a service that nobody reviews. A third is an agreement whose owner has left, which leaves a target that no one defends in review.

Telling whether the agreements are doing anything

The point of an OLA is behavior, not reporting. Look at whether the receiving team’s queue changes shape around the target: whether acknowledgements happen earlier, whether the escalations carry the information the receiving team needs, and whether the customer-facing measure improves. A breach report that goes unread for a month tells you the agreement has stopped working even if the platform shows green. Review the agreements on the same cycle as the service review, and retire the ones that no longer change anything.

Where an agreement is the wrong instrument

A small team that talks every day does not need a written target for each handoff, and a formal OLA can make a close working relationship feel like a contract. Where the teams are already sharing one queue and one manager, a shared service target usually does the job. An OLA is most useful when the teams are separate in reporting lines, when the handoff crosses a budget boundary, or when the customer-facing measure depends on the speed of a team that does not report to the same leader.

Questions for the first agreement review

Question	What a good answer looks like
Who answers for a breach?	A named person on the receiving side, with authority to change the work
Which states pause the clock?	States the platform records automatically, not states that depend on a comment
Did the target change behavior last cycle?	A visible change in the queue, not only a breach count

Frequently asked questions about operational level agreements

Should an OLA ever be shown to the customer?

Usually not directly. The customer sees the service level. The OLA explains how the internal parts of that promise are split, and it should stay internal so that the internal teams can negotiate it honestly without the pressure of a public number.

What do we do when the receiving team says the target is impossible?

Treat the statement as information about either the target or the service design. Look at the volume and the staffing, then decide whether to change the target, change the routing, or change the customer commitment. Leaving the target in place while knowing it cannot be met is the worst outcome.

Can an OLA cover a team outside the organization?

That is an underpinning contract question. An external party needs a contract with its own terms, and the internal OLA should be checked against that contract so that the internal promise is not larger than the external one allows.

How often should targets be reviewed?

Review them when the volume, the staffing or the service design changes, and at a regular cycle that the receiving team agrees to. A target nobody has revisited in a long time is usually either unused or out of date.

Next step

If internal handoffs are measured only by how fast work moves between queues, decide which ones need a written target before writing any.