Managed IT SLAs: What Response and Resolution Times Should You Expect?

Mid-July. Your only IT person is away for two weeks, and it’s not the accounting printer that’s down — it’s the ERP server. Who do you call, and how fast will they act? If you don’t already have a written answer to that, you don’t have a support agreement. You have a phone number. The single line that separates the two usually goes unread: the SLA, or service level agreement.

Plenty of businesses study a support contract’s price, scope, and references. Few read the SLA line. Yet when it actually matters — when the system goes down — that line is what protects you, or fails to.

What an SLA does and doesn’t guarantee

An SLA is the measurable promise a provider makes to you. Two separate clocks run inside it, and confusing them gets expensive:

• Response time: How long before the provider acknowledges your request and gets back to you. It’s the “received, looking into it, technician assigned” moment. It is not a fix.
• Resolution time: When the problem is actually cleared, or a workaround gets you running again.

If a provider says “15-minute response” and you read it as “15-minute repair,” the misunderstanding starts before the ink dries. A good SLA states both times separately, and by priority level.

Look for an honest clause that admits a fix isn’t always in the provider’s hands, too: waiting on a hardware part, or a bug in third-party software that depends on the vendor, can pause the resolution clock. Seeing those written as defined exceptions is a sign the provider takes the commitment seriously.

Priority levels and realistic times

Not every fault is urgent. One user’s mouse problem and the whole company’s email going dark don’t belong in the same bucket. A healthy SLA classifies incidents by priority and sets a separate target for each. For SME-scale operations in Türkiye, the commonly accepted bands look roughly like this:

Priority	Example	Response time	Resolution target
P1 – Critical	Server/ERP down, whole company offline, suspected ransomware	15–30 min	Workaround within 4 hours
P2 – High	A department can’t work, email flow stopped	1 hour	Same business day
P3 – Medium	Single user affected, slowness, printer issue	4 hours	1–2 business days
P4 – Low	Request, install, information query	1 business day	Scheduled

These numbers are negotiable, not sacred. For a small office, a 30-minute P1 response is perfectly good; for a factory running around the clock, even 15 minutes can feel long. What matters is setting the times against your real business risk. Out-of-hours support may be a luxury for an accounting office, while for an e-commerce firm a site staying up at 2 a.m. is a revenue question.

Not every “24/7 support” line offers the same protection

This is the most reassuring yet least binding phrase in most contracts. Unless there’s a written answer to these three questions beneath it, “24/7 support” is decoration:

1. What exactly is 24/7? Monitoring, someone picking up the phone, or a resolution SLA that still applies after hours? In many contracts “24/7” really means automated monitoring; human intervention is capped at business hours.
2. What’s the out-of-hours response time? If a 30-minute daytime promise stretches to 4 hours at night, you should know that up front.
3. Who is on call, and how are they reached? A one-person provider’s “24/7” doesn’t work while that person sleeps. Ask whether a team runs a rotation.

At Xen Bilişim we prefer to spell this distinction out in the contract, because an exception a client discovers at midnight erases the goodwill signed in daylight.

Clauses to look for in the contract

When an IT support proposal lands on your desk, before checking the price, hunt for these lines:

• Priority definitions: Are P1–P4 written clearly, with examples?
• Separate response and resolution times: The two shouldn’t be squeezed into one figure.
• Working hours and out-of-hours scope: Is “24/7” stripped of ambiguity?
• Measurement and reporting: Is SLA compliance reported monthly, or is the promise just words?
• What happens on a breach? Is there a credit, a discount, or at least a root-cause-analysis commitment?
• Out-of-scope items: If what’s not included is written down, the provider knows the job.

That last one looks contradictory but inspires the most confidence. A provider who isn’t afraid to write the exceptions is promising only what it can keep.

Frequently asked questions

Is a support agreement worthless without an SLA? Legally no, in practice largely yes. An SLA-free agreement is the formal version of “we’ll look at it as soon as we can.” When something breaks, you have no measurable commitment to hold on to.

Does a small office really need a 15-minute P1 response? No. For a 10-person office, 30–60 minutes is usually enough. Cutting the time raises the cost; check whether you’ll actually use the speed you’re paying for.

What if the response time isn’t met? A well-written SLA earns its keep here: a credit off the monthly fee, a discount next period, or a written root-cause report so it doesn’t recur. If none of that is in the contract, what you hold is a wish with no teeth.

Let’s review the SLA lines in your support agreement together and set realistic times against your real business risk — get in touch.