An IT support service-level agreement should turn a provider’s promises into clear, testable commitments. It should explain when support is available, how incidents are prioritised, how quickly the provider will respond, what happens next and where the service boundaries sit.
A useful SLA is not simply a table of impressive-looking times. It works alongside the wider support agreement, service scope and technical schedule. Together, those documents should let a business understand what is covered, what is excluded, who owns each responsibility and how performance will be reviewed.
Start by separating the SLA from the service scope
The SLA describes the level of service being committed to. The service scope describes the work the provider has agreed to perform. You need both.
A contract might promise a 15-minute response to a critical incident, but that promise has limited value if the affected server, application or site is outside the managed scope. Equally, a long list of included services is difficult to rely on if there are no defined support hours, escalation routes or performance measures.
When comparing proposals, put the documents side by side and ask:
- Which users, devices, sites, systems and services are covered?
- Which activities are included in the recurring fee?
- What service levels apply to each part of that scope?
- What remains the responsibility of the customer or another supplier?
If those questions cannot be answered without interpretation, the agreement needs clarification before it is signed.
Support hours and 24/7 monitoring are not the same thing
Many providers monitor agreed systems around the clock. That does not necessarily mean engineers are staffed to answer every user request at any hour.
The SLA should distinguish between:
- staffed helpdesk hours;
- automated monitoring hours;
- out-of-hours incident response;
- planned maintenance windows; and
- arrangements for weekends and public holidays.
It should also state which time zone and business calendar apply. If out-of-hours assistance is available only by prior arrangement or as a chargeable extra, that should be explicit.
This distinction matters because “24/7” is often used to describe monitoring rather than a continuously staffed support desk. Both can be valuable, but they are different services with different costs.
Priority definitions should reflect business impact
An effective SLA defines incident priorities in business language. Priority should not be based only on how strongly a ticket is worded or who submitted it.
A sensible model considers impact and urgency:
- Critical: a major business service, site or significant proportion of users cannot operate, with no practical workaround.
- High: an important service or group of users is seriously affected, but part of the business can continue or a limited workaround exists.
- Normal: an individual or non-critical function is affected and ordinary work can continue elsewhere.
- Low or request: a minor issue, information request, planned change or task that can be scheduled.
The agreement should include examples relevant to the customer. A failed guest Wi-Fi network may be inconvenient in one business and commercially critical in a hotel or venue. A slow CAD file server may affect an entire architectural practice even though email and internet access remain available.
The provider and customer should also agree who can declare a critical incident and how a priority can be changed when new information emerges.
Response time is not resolution time
This is the most important distinction in many SLAs.
Response time normally means the provider has acknowledged the incident and begun an appropriate assessment. Resolution time means the service has been restored or the agreed work has been completed.
A rapid acknowledgement is useful, but it does not guarantee a rapid fix. Some incidents depend on hardware delivery, an internet carrier, Microsoft, a software vendor or access to the premises. A responsible provider should not promise a resolution time it cannot control.
The SLA should therefore explain:
- what counts as a response;
- when the measurement clock starts and pauses;
- whether targets are measured only during staffed hours;
- how customer or third-party delays are handled;
- whether restoration or a workaround counts as resolution; and
- how often updates will be provided while an incident remains open.
For serious incidents, update frequency can be as important as the initial response. Decision-makers need to know what is happening, what the current business impact is and when the next update will arrive.
Make escalation visible
The agreement should explain what happens when an issue is not progressing normally.
Look for a documented escalation path covering technical escalation, service-management escalation and major-incident communication. It should be clear when a ticket moves to a more senior engineer, when management becomes involved and who communicates with the customer.
Named individuals can change, so the process matters more than a static list of names. However, the customer should still know how to reach an accountable person when the normal route is not working.
For a critical incident, the provider should coordinate the technical response rather than leaving the customer to chase several suppliers independently. Where another supplier owns the fault, the agreement should state whether liaison is included and what information the IT provider will need to act on the customer’s behalf.
Define remote support, on-site attendance and travel
Many issues can be resolved remotely, but established businesses also depend on physical infrastructure: firewalls, switches, Wi-Fi, servers, meeting-room equipment, CCTV, access control and devices that cannot always be diagnosed through a support tool.
The SLA should state:
- when the provider decides an on-site visit is necessary;
- whether on-site time and travel are included;
- the geographic area covered by standard arrangements;
- any target for attendance;
- what happens at additional sites; and
- how emergency visits outside staffed hours are charged.
Be cautious about treating an on-site attendance target as a universal resolution promise. Travel time can be committed to; hardware availability and third-party repair times often cannot.
Read the exclusions and dependencies carefully
An SLA is only meaningful when its boundaries are visible. Common exclusions or separately charged activities include:
- major projects and migrations;
- new equipment installation;
- support for unapproved or end-of-life systems;
- extensive user training;
- office moves and new sites;
- recovery work where no supported backup exists;
- support outside stated hours; and
- faults within third-party services.
Exclusions are not automatically unreasonable. The problem is ambiguity. Ask the provider to give examples of what it treats as routine support, a standard change and a project.
The agreement should also identify customer dependencies. Response targets may rely on authorised contacts being available, remote access remaining enabled, equipment being under warranty or the customer providing timely access to buildings and third-party accounts.
Security incidents need their own operating expectations
A suspected compromise does not behave like an ordinary support ticket. The provider may need to contain accounts or devices before the full cause is known, preserve evidence, involve an insurer or specialist responder and restrict what is shared through potentially compromised communication channels.
The contract should make clear:
- which security monitoring and response services are included;
- who receives and acts on alerts;
- who may authorise containment actions;
- how the customer is contacted if normal email is unsafe;
- where specialist incident response begins; and
- what logging, backup and insurance dependencies apply.
Do not assume that supplying antivirus or Microsoft 365 administration automatically includes a complete incident-response service.
Reporting should show outcomes, not just ticket volumes
An SLA should be reviewed, not filed away after signature. Agree a sensible reporting and review cadence for the size and complexity of the organisation.
Useful reporting may include:
- response performance by priority;
- unresolved and ageing tickets;
- recurring incidents and underlying problems;
- device, monitoring and patch coverage;
- backup failures and restore tests;
- security actions and outstanding risks;
- user, licence and equipment changes; and
- progress against agreed technology priorities.
High ticket volumes do not necessarily indicate good or bad service. They may reflect business growth, a successful reporting culture or a recurring fault that should have been removed. The review should connect the numbers to causes, actions and business impact.
Include onboarding, documentation and exit arrangements
The beginning and end of the relationship deserve the same clarity as day-to-day support.
Onboarding should cover discovery, documentation, administrative access, monitoring, security tooling, backups, user communication and immediate risks. The agreement should state when normal SLA measurement begins and how urgent issues found during onboarding will be handled.
Exit terms should confirm ownership and handover of documentation, credentials, licences, configurations and customer data. Check notice periods, renewal terms and any reasonable charges for substantial transition work.
A good provider should maintain the environment so another competent provider can understand it. Customers should retain organisation-controlled access to essential systems rather than becoming technically dependent on one supplier.
A practical SLA comparison checklist
Before choosing or renewing an IT support agreement, confirm that you can answer all of these questions:
- What users, devices, sites and systems are covered?
- What are the staffed hours, monitoring hours and out-of-hours arrangements?
- How are critical, high, normal and low priorities defined?
- Are response and resolution clearly distinguished?
- When does the SLA clock start, pause and stop?
- How frequently will updates be provided during a serious incident?
- What are the technical and management escalation routes?
- When is on-site attendance included, and what geography applies?
- Which third-party liaison and supplier-management tasks are included?
- What security-response responsibilities are covered?
- What is excluded or treated as a project?
- What reporting and service reviews will be provided?
- Who owns documentation, credentials and licences?
- What happens during onboarding and when the relationship ends?
The strongest agreement is not necessarily the one with the shortest response time. It is the one that aligns scope, responsibilities and realistic commitments with the way the business actually operates.
Bring your current SLA for a plain-English review
Merr IT provides managed IT support and structured provider switching for established organisations across Wiltshire. If you are comparing proposals or approaching a renewal, bring us your current agreement. We will help you identify unclear commitments, missing responsibilities and the questions worth asking before you decide.
You may also find these guides useful: