IT support SLAs and response times explained

This page is for business owners comparing IT support agreements who want clear promises. It explains response time, resolution time, priorities and cover hours, so vague SLA wording does not cause trouble later.

An SLA is a promise with boundaries

SLA means service level agreement. In an IT support contract it should set out what service you can expect: which issues receive priority, how quickly the provider will acknowledge them, when support is available, what is excluded and how performance is measured. It is not a guarantee that every problem will disappear inside a fixed number of minutes.

The SLA should match the way you work. A business that trades only Monday to Friday has a different need from a care provider, manufacturer or online retailer where a weekend outage has an immediate cost. More cover and faster targets usually cost more, so there is no single best agreement for every small business.

Response time is not resolution time

Response time is how quickly the provider acknowledges a properly logged ticket and begins handling it. A response might be a technician calling back, checking the monitoring system or confirming that an engineer has been assigned. It does not mean the problem has been fixed.

Resolution time is how long it takes to restore the service or provide a workable fix. It is harder to promise because the cause may be outside the provider's control: a broadband carrier fault, a failed part, a software supplier issue, missing information from the user or a third party who must approve a change.

A good provider should still communicate clearly. If an issue cannot be fixed quickly, you should know what has been tried, the next action, who owns it and when you will hear again. Ask whether the contract contains a target for update frequency, workaround or restoration, not just the first response.

This distinction matters particularly when an incident could involve a breach. An initial cyber response may be rapid, but investigation and safe recovery take time. Our guide to ransomware recovery explains why a quick restart is not always the right outcome.

How priority levels should work

Most providers use priority levels from P1 or critical down to P3 or P4 for routine work. The labels matter less than the examples. A sensible agreement defines the business impact, not merely the technology that has failed.

• P1 or critical: a whole business site, core system or large group of staff cannot work, with no practical workaround. Think total internet loss at the main office or all email being unavailable.
• P2 or high: a major function or several people are affected, but there may be a temporary workaround. A finance system may be slow at month end, or a department may have lost access to a shared service.
• P3 or normal: one person has a fault, or a non-critical feature is not behaving as expected. It needs attention but does not stop the business.
• P4 or request: planned work such as a new starter, access change, software installation or advice request. These should be scheduled rather than pushed ahead of an outage.

Be realistic when logging tickets. Calling every printer annoyance critical makes it harder for everyone to identify a genuine emergency. Equally, a provider should not downgrade an outage merely to meet a target. Ask who can change the priority and how you can challenge the decision.

Business hours and 24/7 cover

Business-hours support normally means the SLA clock runs only during stated working hours, often Monday to Friday excluding bank holidays. A ticket raised at 5.30pm on Friday may not start counting until Monday morning. That can be perfectly reasonable, provided it is written plainly and suits your operation.

For a typical office-based SME, strong business-hours support plus proactive monitoring and a clear emergency route is often more useful than paying for blanket 24/7 cover that you rarely use. If you rely on calls or cloud systems at all hours, check that your business phone system and broadband arrangements have their own support and resilience options too.

What a realistic small-business SLA looks like

Look for a commitment to acknowledge and start work, a clear escalation route, named support hours and regular service reviews. Monitoring, patching and planned maintenance matter too. Compare the scope with our managed IT support service: reacting quickly is only part of the job.

Costs should be clear as well. Some contracts include remote support but bill separately for projects, on-site work, replacement equipment or out-of-hours incidents. None of those arrangements is automatically unfair; the issue is whether you can see them before you sign. Our article on small-business IT support costs gives more context for comparing like with like.

Weasel wording to question before signing

• Best endeavours: ask what measurable target sits behind it. It may be no promise at all.
• Response within: confirm whether that means an acknowledgement, meaningful diagnosis or a fix.
• Subject to availability: find out whether your priority ticket can wait behind other work.
• Business hours: ask for exact days, times, bank holiday treatment and time zone.
• All-inclusive: request a list of excluded projects, travel, parts, third-party charges and out-of-hours work.
• Monitoring included: ask what is monitored, who acts on alerts and whether the service is actively watched.

Also check the client responsibilities. The provider may need you to keep licences current, maintain an internet connection, nominate authorised contacts and approve replacements. These are reasonable conditions if they are clear. They become a problem when hidden in small print and raised only after an outage.

What to do next

Take your current agreement and underline every reference to response, resolution, priority, hours and exclusions. If you cannot tell what happens during your worst likely outage, ask before renewal. TSS offers a free, no-obligation chat for businesses that want a straight view of whether their support terms match the risk they carry.