SLA vs OLA vs KPI: What's the Difference?
An SLA is a promise to the people you serve, an OLA is a promise between internal teams that makes the SLA possible, and a KPI is a number you watch to see how you're doing. Examples and pitfalls for each.
SLA vs OLA vs KPI in one line each: an SLA (service level agreement) is a promise to the people you serve, such as "access requests resolved within one business day"; an OLA (operational level agreement) is a promise between internal teams that makes the SLA achievable, such as "the security team approves access within four hours"; and a KPI (key performance indicator) is a number you track to judge performance, such as "percentage of requests resolved within SLA". SLAs and OLAs are commitments; KPIs are measurements.
The three side by side
| SLA | OLA | KPI | |
|---|---|---|---|
| Between | Service provider and its users | Two internal teams | Nobody — it's a measurement |
| Answers | "What can users expect?" | "What does each team owe the other so the SLA holds?" | "How are we doing?" |
| Example | First response to any IT request within 4 business hours | Networking fixes escalated Wi-Fi issues within 1 business day | Median first-response time this month: 1h 40m |
| If missed | User trust drops; external SLAs may carry penalties | The SLA it supports is at risk | Nothing directly — it prompts a question |
| Owner | The service owner | Both team leads | Whoever runs the reporting |
SLA: the promise to users
A service level agreement sets expectations with the people who use a service. In IT service management it's usually written per service or request type and includes what is covered, the targets (response and resolution times, availability), how they're measured, and what happens when they're missed.
Inside a company, SLAs are rarely contracts with financial penalties. They are still worth writing down because they turn "IT is slow" into a measurable statement: "access requests met the 1-day target 87% of the time last month".
Google's SRE book adds precision that's useful here. It separates the SLI (the indicator you measure), the SLO (your target for it) and the SLA (the agreement with consequences attached). Most internal "SLAs" are really SLOs — targets without penalties — and that's fine. How to set and track them is in the help desk SLA tracking guide.
Good SLA traits:
- Specific to a request type, not one number for everything.
- Measured automatically from timestamps, not self-reported.
- Achievable most of the time, based on measured history.
OLA: the promise between teams
An operational level agreement is the internal agreement that makes an SLA achievable. The service desk may promise users a laptop within five business days, but it depends on procurement to order it and on IT operations to image it. If those teams have no commitments of their own, the service desk is promising something it doesn't control.
An OLA spells out each dependency: "procurement places hardware orders within one business day of approval"; "IT operations images and ships devices within two business days of delivery".
Why OLAs matter in a request desk: requests that bounce between teams are where SLAs die. When a request is reassigned from the service desk to networking, the clock keeps running. An OLA tells networking how much of that clock it can use. Tracking reassignment timestamps shows whether OLAs are being met — and which handoff is eating the time. Clean routing to the right team reduces how often you need them.
Good OLA traits:
- Sums to less than the SLA it supports, with slack left over.
- Owned jointly — both leads agree to it.
- Reviewed when the SLA it supports keeps breaching.
KPI: the numbers you watch
A key performance indicator is a metric chosen because it reflects whether you're meeting your goals. KPIs don't promise anything; they tell you where to look.
Help desk KPIs that are worth tracking:
- SLA attainment — share of requests resolved within target, per category.
- First-response time — median and 90th percentile.
- Resolution time — median and 90th percentile.
- Backlog age — how many open requests are older than N days.
- Reopen rate — share of resolved requests that come back.
- Deflection — requests avoided because a knowledge-base article answered the question first.
The full list, with how to compute each, is in help desk metrics that matter.
Good KPI traits:
- A handful, not dozens. If everything is key, nothing is.
- Percentiles over averages; averages hide the people who waited longest.
- Each one owned by someone who can act on it.
How the three fit together
Picture a single request for software access:
- The SLA says: access requests resolved within 1 business day.
- Resolving it needs a manager's approval and a security review, so two OLAs exist: managers approve within 4 business hours; security reviews within 4 business hours.
- The KPIs show last month's SLA attainment for access was 78%, and the reassignment timestamps show most breaches waited on security review.
That chain — commitment, supporting commitments, measurement — is what turns "access is slow" into "security review is our bottleneck; let's pre-approve low-risk apps".
Writing your first SLA: a one-page template
You don't need a legal document. For an internal desk, one page per service is enough:
- Service: IT access requests.
- Covers: access to company systems, shared drives and SaaS tools. Excludes new-starter setup (separate service).
- Hours: Monday–Friday, 9:00–18:00 in the IT team's timezone. Outside those hours, the clock starts at 9:00 the next working day.
- Targets: first response within 4 business hours; resolution within 1 business day for standard access, 3 business days when a data-owner approval is required.
- Measured by: timestamps recorded by the request desk; attainment reported monthly per category.
- Dependencies (OLAs): data owners approve within 1 business day; security reviews new SaaS tools within 3 business days.
- When missed: the team lead reviews every breach in the monthly report; three months below 85% attainment triggers a review of staffing or targets.
- Review date: every quarter.
Write the matching OLA in the same format, from the dependent team's point of view. Two short pages, agreed by both leads, prevent most "that's not our job" arguments.
Picking the numbers
Resist the temptation to copy targets from another company. Measure two to four weeks of your own requests with timers running and no targets shown, then set the SLA near your 80th–90th percentile per category. A target you meet most of the time stays credible; a target you miss half the time gets ignored. The measurement details are in the SLA tracking guide.
Common mistakes
- Treating a KPI as an SLA. "Average resolution: 6 hours" isn't a promise. Users need a target per request type.
- SLAs without OLAs. The front line promises what other teams deliver, then eats every breach.
- OLAs that add up to more than the SLA. If three handoffs each get a day, a 2-day SLA is fiction.
- Too many KPIs. Pick the few that drive decisions. Five is plenty for most internal desks.
- Self-reported numbers. Compute everything from timestamps the system records. See analytics with plain Postgres.
FAQ
Is an SLO the same as an SLA?
No. An SLO is a target for a measured indicator; an SLA is an agreement with users that usually includes SLOs and consequences for missing them. Internal help desks mostly have SLOs, even when they call them SLAs.
Do small teams need OLAs?
Only once requests regularly cross teams. If one team handles a request end to end, the SLA is enough. When handoffs start causing breaches, write an OLA for that handoff.
Can a KPI be based on an SLA?
Yes — "SLA attainment" (the share of requests meeting their SLA) is one of the most useful KPIs a help desk can track.
Where do SLAs come from in ITIL?
ITIL treats service level management as a practice: agreeing targets with customers, monitoring them and reviewing them. OLAs and underpinning contracts support the SLA from inside the organization and from suppliers.
Sources
Building Relay — the internal request desk with AI triage and SLA tracking.
Run your internal requests on LetRelay
AI triage, SLA-tracked queues, and bottleneck analytics — the help desk your team actually likes. Free to start.
Keep reading
Internal Help Desk Satisfaction Surveys That Tell You Something
How to measure satisfaction with an internal help desk without annoying everyone — one question after resolution, a follow-up only on bad scores, response rates, CSAT vs effort vs NPS, and turning answers into changes.
Facilities Request Management: From Broken Chairs to Keys
How to run facilities requests like a proper service — categories, location on every request, safety issues that skip the queue, vendor work, recurring maintenance and the numbers that show where the building needs attention.
HR Service Desk: Handling Employee Requests Without the Inbox
How an HR service desk works — categories for pay, leave, contracts and benefits, privacy that's enforced not promised, targets that respect deadlines like payroll, self-service for policy questions, and the metrics HR can use.