What a realistic SLA actually looks like (with numbers)

Almost every IT team I assess has SLAs. Almost none of them can prove those SLAs are met. The document exists, a number was written down years ago, and then reality quietly diverged from it. This is one of the most common and most fixable problems in IT support.

A good SLA is not an aspiration. It is a promise you can keep and measure. Here is how to design one.

Start with priority, not with time

The most common mistake is setting a single response target for all tickets: “we respond within four hours.” That is meaningless, because a laptop that will not turn on and a request for a new mouse are not the same urgency.

A realistic SLA starts with a priority matrix that combines impact (how many people or how critical a system is affected) with urgency (how time-sensitive it is). Every ticket gets a priority when it is created, and the SLA target follows from the priority.

A workable starting point for a mid-sized company:

Priority	Example	Response	Resolution
P1 – Critical	Core system down, many users blocked	15 minutes	4 hours
P2 – High	Important function degraded	1 hour	8 hours
P3 – Medium	Single user blocked, workaround exists	4 hours	2 business days
P4 – Low	Request, minor issue	1 business day	5 business days

These are starting numbers, not gospel. The point is that the target is tied to priority, and priority is tied to business impact, not to who complains loudest.

Separate “response” from “resolution”

Response time is when a human acknowledges the ticket and takes ownership. Resolution time is when the issue is actually fixed. Conflating them creates unfair, unachievable targets. Your team can almost always control how fast they respond. They cannot always control how fast a complex issue is resolved, because it may depend on a vendor, a deployment window or a root cause investigation.

Measuring both, separately, gives you an honest picture and a fair one.

SLA vs OLA: the piece everyone forgets

An SLA is your promise to the customer. An OLA (operational level agreement) is the internal promise between teams that makes the SLA possible. If your service desk promises a customer resolution in eight hours, but the infrastructure team it depends on has no commitment to respond within any particular time, the SLA is fiction.

Every external SLA should be backed by the internal OLAs required to deliver it. This is the single most overlooked step in SLA design, and the reason so many SLAs quietly fail.

Make the clock automatic

An SLA you track in a spreadsheet is an SLA you are not really tracking. The target has to live in your service desk tool, with the clock starting automatically when the ticket is created, pausing when you are legitimately waiting on the customer, and alerting before a breach, not reporting it afterwards.

If your tool cannot show you, right now, your current SLA compliance rate, that is the first thing to fix.

The honesty test

Here is the test for whether your SLAs are real: could you put your current compliance rate on a slide in front of your board tomorrow, with confidence it is accurate?

If yes, you have a measured operation. If the honest answer is “we’d have to go and calculate it, and I’m not sure I’d trust the number,” then your SLAs are decoration, and that is exactly the gap worth closing first.

---

Supportimize designs SLAs and the OLAs behind them, then configures the live tracking so compliance is something you can prove, not hope for. Book a free consultation or check your maturity in two minutes.