IT service expectations often differ across departments. Finance may expect a locked account to be restored within minutes, a new hire needs their laptop ready on day one, and users may have different interpretations of what qualifies as an urgent request. Without agreed service targets, these differences can lead to inconsistent expectations and disputes over IT performance.
An internal Service Level Agreement (SLA) establishes clear commitments between IT and the departments it supports. It defines the requests covered, expected response and resolution times, and the actions to take when a target is at risk. This guide explains what to include in an internal SLA, provides example response and resolution times by priority, and outlines how to establish service tiers and monitor performance over time.
What is an internal SLA?
An internal SLA is the agreement between an IT team and the departments it supports inside the same company — HR, Finance, Sales, Operations, and anyone else who files a ticket. It uses the same structure as a service level agreement signed with an outside vendor, but the parties are internal and no money changes hands. What it buys you is shared expectations: what IT will respond to, how fast, and what happens when a target is at risk.
Unlike a contract with penalties, an internal SLA runs on accountability rather than legal enforcement. Its job is to turn vague promises like "we'll get to it" into numbers both sides have agreed on in advance.
Internal SLA vs. external SLA vs. OLA
The three terms overlap, which is why they get swapped around. The short version:
The distinction most often blurred is the one between an SLA and an OLA. If your help desk promises a four-hour fix but needs the networking team to act first, that dependency belongs in an OLA sitting underneath the SLA — not in the number you show the business. Getting that layering right keeps you from committing to something another team never signed up for.
What to include in an internal SLA
A workable internal SLA is short and specific. These are the parts worth defining:
- Services covered. List what the SLA actually applies to — password resets, access requests, hardware, a specific business app. Anything not listed is out of scope by default.
- Service hours. State when the clock runs. "Four hours" means something different at 2 p.m. on a Tuesday than at 2 a.m. on a Sunday, so tie your targets to business hours unless a service is genuinely 24/7.
- Priority levels. Define how urgency and impact combine into a handful of priorities, and give a plain example of each so tickets get triaged the same way every time.
- First response time. How long before a human acknowledges the ticket and owns it. This is the promise users feel most.
- Resolution time. How long until the issue is fixed or the request fulfilled, measured per priority.
- Escalation path. What happens when a target is about to be missed — who gets notified and where it moves next.
- Exclusions. The things you explicitly don't cover: personal devices, shadow IT, low-priority requests outside service hours. Naming them up front prevents arguments later.
- Review cadence. When you'll revisit the whole thing. Quarterly is a reasonable default.
Keep the list of commitments tight. Everything you write down becomes something you're measured against, so it helps to separate the targets you're truly accountable for from the numbers you only watch.
Internal SLA examples by priority
The table below is a starting point, not a standard to copy. Use it to see the shape of a tiered SLA, then set your own numbers against what your team can realistically deliver today.
Unless you run a 24/7 service desk, measure these during your stated service hours — a P3 logged at 4:55 p.m. shouldn't breach overnight. The right targets are the ones you can hit consistently, so start a little conservative and tighten them once the data backs you up.
How to set internal SLA tiers for the first time
If you're starting from nothing, resist the urge to design the perfect scheme on paper. Build it from what you already do.
- Measure what you do now. Pull your current first-response and resolution times from your ticketing data, broken out by rough urgency. You can't commit to a target you've never actually hit.
- Group services into a few priorities. Sort the work by business impact — what stops the company, what stops a team, what stops one person, what can wait. That grouping becomes your tiers.
- Agree the targets with each area. Walk Finance, HR, and the rest through what's realistic and let them push back. A number IT sets alone is a guess; a number both sides accept is an SLA.
- Start with two or three tiers. A simple scheme everyone applies the same way beats a precise one that gets ignored. You can add granularity once the basics hold.
- Re-measure at 90 days. Compare actuals against the targets, see where you're breaching or sandbagging, and adjust. The first version is a hypothesis, not a finished product.
How to track internal SLAs in InvGate Service Management
Once the targets exist, they have to run on their own or they'll quietly drift. In InvGate Service Management, SLA policies attach first-response and resolution targets to tickets automatically through business rules — by category, priority, help desk, or custom attributes — so a Finance access request can carry different targets than a company-wide outage without anyone starting a timer by hand. Configuring an SLA follows a short, repeatable process: pick the SLA type, set the conditions that assign it, and define the timing, pausing, and escalation rules.
Most organizations won't have one set of targets for everyone, which is why you can run several SLA policies side by side, each scoped to the area or service it covers. The clock follows your working hours and holiday calendars, pauses automatically while a ticket waits on the requester, and can show that requester an estimated resolution time.
When a target nears its threshold or breaches, the policy escalates the way you defined, and everything rolls up into the way you manage service levels across the board — so the SLA becomes something you can report on, not just a document in a drawer.
The internal commitments that sit underneath those targets are covered too. InvGate Service Management supports Operational Level Agreements natively, so you can set and enforce targets for each team or escalation level in a multi-team resolution — the layer that makes a customer-facing resolution time realistic in the first place.
If you're writing internal SLAs for the first time, or cleaning up ones that have drifted, you can try it free for 30 days and watch the engine run against your own priority levels. Or schedule a call with our team.
Common mistakes with internal SLAs
- Promising times you've never measured. Targets set from optimism rather than data get breached from week one, and nothing erodes trust in IT faster than an SLA it routinely misses.
- Too many priority levels. A scheme with ten tiers nobody can remember gets applied inconsistently. A handful of priorities everyone understands is worth more than a precise system no one follows.
- Writing the SLA without the other teams. If Finance and HR never agreed to the numbers, you don't have an agreement — you have IT's internal wish list. The receiving teams have to sign off.
- Tracking response but ignoring resolution. A fast acknowledgment followed by a week of silence meets the letter of the SLA and fails the user completely. Commit to both, and measure them during real service hours.
- Setting it and forgetting it. Staffing, tools, and workload all change; an SLA that's never revisited slowly stops matching reality. Put a review on the calendar and actually keep it.
Frequently asked questions
What is an internal SLA?
It's the agreement between IT and the other departments it supports in the same company, setting how quickly IT will respond to and resolve their requests. It runs on mutual accountability rather than the penalties you'd find in a vendor contract.
Do internal teams need SLAs?
Not always formally. A small team with a light ticket load may do fine on shared norms. The value of a written SLA shows up as you scale: it makes expectations explicit, gives you something to measure against, and settles the "why hasn't this been done yet" conversations before they start.
What is the difference between an internal SLA and an OLA?
An internal SLA is IT's promise to the business — the response and resolution times a requester sees. An OLA is the set of supporting commitments between internal teams that make that promise deliverable. The SLA faces the requester; the OLA sits underneath it.
How many SLA tiers should IT have?
Start with two or three, and rarely go past four. The number should match how you actually triage work, not how precise you'd like to appear. Too many tiers get applied inconsistently, which defeats the purpose.
