IT Support Response Times: A UK Business Guide to Setting SLAs That Actually Match Your Risk in 2026

An IT support SLA is the only part of a managed service contract that tells you what happens on the worst day of your year, and it is routinely the least examined. Most UK businesses read the headline response time — fifteen minutes, one hour, four hours — decide it sounds reasonable against the price, and sign. The number rarely gets tested against the thing it is supposed to protect: how long a specific system can be unavailable before the cost of the outage exceeds anything the support contract could ever be worth.

This guide reverses that order. It starts with how to calculate a risk-based response requirement from your own operational and financial reality, then shows how to translate that requirement into priority ticket levels that a provider can actually staff. From there it covers the escalation path that determines whether a P1 gets the right engineer or the next available one, the SLA clauses that quietly matter more than the headline number, what the various service tiers cost in the UK in 2026, and how to measure performance in a way that survives a quarterly review. By the end you should be able to write a one-page response-time specification, hand it to three providers, and compare what comes back on a like-for-like basis instead of on marketing copy.

What an IT support SLA actually is — and what a response time guarantee does not tell you

A service level agreement is a contractual schedule that defines the service being bought, the measurable targets it will be delivered against, how those targets are measured, and what happens when they are missed. In UK managed IT it usually sits as an annexe to a master services agreement, and it typically contains four things: a set of priority ticket levels, a target response time and target resolution or fix time for each level, the hours during which those targets apply, and a remedy — almost always a service credit — if the targets are breached over a measurement period.

The critical distinction, and the one that causes most of the disappointment in this market, is between response and resolution. A response time guarantee commits a provider to acknowledging a ticket and beginning work within a stated window. It does not commit them to fixing anything. A fifteen-minute response on a P1 means a human being has picked up the ticket and started; the outage may still run for six hours. Some contracts add a target resolution time, but it is nearly always expressed as a target rather than a guarantee, and it is nearly always hedged by exclusions covering third-party dependencies, hardware lead times, and anything the provider classifies as outside its control. A great many UK SME support contracts contain no resolution commitment at all.

The second distinction that matters is what the clock measures. Two providers can both advertise a one-hour P1 response and mean entirely different things. One starts the clock when the ticket is created in the portal and stops it when an engineer posts a substantive update. The other starts when the ticket is triaged during business hours, pauses whenever the ticket is set to “awaiting customer”, and stops when any automated acknowledgement is sent. The second contract can report near-perfect compliance while your users wait all afternoon. Neither is fraudulent; only one is useful. You cannot tell which you are buying from the headline number, which is why the number should be the last thing you negotiate rather than the first.

Where UK support tickets actually come from — and why that shapes your SLA

Response times are only meaningful in proportion to the ticket mix they apply to. In a typical UK SME of 30 to 250 staff, the overwhelming majority of tickets are low-impact requests that a well-run service desk clears the same day, while a small tail of genuine incidents consumes most of the risk. Buying a fifteen-minute response across every ticket type means paying for urgency on password resets. Buying a four-hour response across every ticket type means accepting that a site-wide outage waits behind the queue.

The distribution below reflects the pattern seen across UK managed service desks: identity and access issues dominate by volume, application and licensing questions follow, and infrastructure-level incidents — connectivity, server, security — are comparatively rare but account for nearly all of the lost productivity. Design your priority ticket levels around this shape, not around an even split.

The bottom two rows are where SLA design earns its money. Roughly one ticket in twenty is an infrastructure or security event, and that ticket is the one that generates the board-level question afterwards. If your agreement gives that ticket the same treatment as a mailbox permission request, the contract is mispriced against your risk regardless of how cheap it looks. Equally, if you have negotiated aggressive targets across all four priority levels, you are paying a premium on the 96% of tickets where nobody would have noticed a two-hour difference.

There is a second-order effect worth planning for. Ticket volume is not evenly distributed across the week or the day. Monday mornings and the first working day after a bank holiday routinely carry double the average volume, driven by weekend password expiry, device updates and returning staff. If your SLA has a monthly compliance measurement and your provider staffs to the monthly average, the breaches will cluster precisely on the days your business is trying to restart. Ask for compliance reporting broken down by day of week before you sign, not after the first bad Monday.

The numbers that should drive your SLA before you read a single provider tier sheet

A risk-based response requirement is derived, not chosen. It comes from four inputs that any finance director can produce in an afternoon: the fully loaded hourly cost of the affected staff, the revenue that depends on the affected system, the maximum tolerable period of disruption the business has already agreed elsewhere — usually inside a business continuity or insurance document — and the frequency with which that system has actually failed over the last three years.

Put those four cards together and the central tension of SLA buying becomes obvious. A four-hour outage for that 60-person office costs roughly £9,120 in lost productive time alone, before any revenue impact, customer commitment or overtime recovery. If the monthly support fee is £4,200 and service credits are capped at 10%, the maximum contractual remedy for that outage is £420. The SLA is not, and was never designed to be, an insurance policy. It is a specification for how fast a provider will work and a mechanism for holding a commercial conversation when they do not. Treating it as financial protection is the single most common analytical error in this market.

That reframing changes what you should negotiate for. Service credits are worth having as a governance trigger, but the clauses that genuinely reduce your exposure are the operational ones: guaranteed engineer skill level on a P1, a named escalation contact with authority to commit resources, a defined maximum time before the incident is escalated past first line, and the right to invoke a major incident process that pulls people off other work. Those cost the provider real money to honour, which is precisely why they are worth more than the credit percentage.

The fourth input — historical failure frequency — is the one most businesses skip, and it is the one that stops you over-buying. If your core line-of-business application has had two unplanned outages in three years, both resolved inside ninety minutes, a fifteen-minute response tier is unlikely to change your annual outcome materially. If your connectivity has failed four times in eighteen months, the money is better spent on broadband failover and redundancy than on shaving thirty minutes off a support response, because the resilience removes the incident rather than accelerating the reaction to it.

Calculating your true cost of downtime — the two-hour exercise that sets everything else

The purpose of this exercise is to produce a single figure per system: the cost, in pounds, of one hour during which that system is unavailable to the people who need it. Once you have that figure for your top eight systems you can rank them, and once you can rank them you can write priority ticket levels that mean something. Without it, every conversation with a provider is an argument about adjectives.

Start with the productivity component, because it is the easiest to defend. Take the number of staff who cannot do their primary work when the system is down, multiply by the fully loaded hourly cost, and multiply by a productivity loss factor between 0.4 and 1.0. The factor matters: when email is down, most knowledge workers can still do something useful for an hour, so 0.5 is realistic. When the practice management system, warehouse system or till system is down, the factor is 1.0 because there is no workaround. Be honest here — inflating the factor produces a number nobody in the business believes, and the exercise loses its authority the first time it is challenged.

Then add the revenue component, which applies only to systems that sit directly in the earning path. For a professional services firm, an hour of unavailable email delays work but rarely destroys revenue; the work is done later. For an e-commerce operation, an hour of a down checkout is revenue that does not return, and the calculation is simply average hourly order value for that time of day. For a contact centre or a booking business, use abandoned contact rate multiplied by conversion rate multiplied by average order value. Most UK SMEs discover that only two or three systems carry genuine revenue loss, which is a useful and money-saving discovery.

Third, add the recovery cost: the overtime, the manual reconciliation, the re-keying of orders taken on paper, the supplier chasing. This is routinely 20–40% of the productivity figure for any outage over two hours, and it is almost never budgeted. Fourth, and only where it genuinely applies, add contractual and regulatory exposure — SLA penalties you owe your own customers, missed statutory filing windows, or a personal data availability incident that becomes reportable to the ICO. Availability failures are frequently forgotten in this context: the UK GDPR treats accidental loss of access to personal data as a security incident, not merely an inconvenience, and prolonged inability to access records can trigger a reporting assessment.

The final step is to compare each system’s hourly cost against the maximum tolerable period of disruption already recorded in your continuity plan or insurance schedule. Where the two disagree — and they usually do — the continuity document is normally the optimistic one, because it was written by people estimating rather than measuring. Reconciling them is the point at which SLA design stops being a procurement task and becomes a governance one. If you have already documented recovery objectives as part of an Azure disaster recovery and failover plan, those figures are the correct starting point and your support SLA should be tighter than them, not looser.

One caution on the arithmetic. Cost of downtime is not linear. The first fifteen minutes of most outages cost almost nothing, because people assume it is transient and wait. The curve steepens sharply between thirty minutes and two hours as workarounds are exhausted and managers begin reallocating people, then flattens again once the business has switched to a manual process. This shape is why a response-time improvement from four hours to one hour is often worth far more than an improvement from one hour to fifteen minutes: you are buying a reduction in the steep part of the curve rather than the flat beginning of it.

Risk-based readiness scoring — where most UK businesses sit today

Before negotiating with a provider it is worth grading your own position honestly, because a provider cannot deliver a tight response commitment against an environment they cannot see. The three cards below reflect the pattern seen repeatedly during UK managed service transitions: the contractual position is usually adequate, the operational readiness behind it is thinner than assumed, and the measurement discipline is close to absent.

The pattern is consistent. Businesses invest attention in the contract, which is a one-off exercise conducted with a solicitor present, and neglect the operational and governance layers, which require ongoing effort from an internal owner. The consequence is a technically sound agreement that cannot be enforced, because nobody is reading the reports and nobody has verified that the out-of-hours number reaches an engineer rather than a voicemail box.

If you fix only one row from the three cards, make it the second one in the middle card. An asset and dependency register that the provider can query is what converts a P1 from an investigation into a diagnosis. Without it, the first forty minutes of every major incident are spent establishing what exists, who owns it, and what it connects to — time that is charged against your response window and produces nothing.

Designing priority ticket levels that a provider can actually staff

Priority is a function of two variables: impact (how much of the organisation is affected) and urgency (how quickly the effect becomes material). Most UK managed service providers work to a four-level scheme, and the mistake businesses make is defining those levels by technology — “server down is a P1” — rather than by business consequence. Technology-based definitions fail immediately in a cloud estate, where there may be no server to be down, and they fail again when a single user who happens to be processing the month-end payroll run is treated as a P3.

A workable UK four-tier scheme looks like this. P1, critical: a complete loss of a business-critical service, or any security incident with suspected data exposure, affecting a whole site, a whole department, or a single individual performing a time-critical statutory function. P2, high: significant degradation where a workaround exists but is materially slower, or complete failure of a non-critical service affecting multiple users. P3, medium: a single user unable to perform part of their role, or a fault with an acceptable workaround. P4, low: requests, changes, questions, and cosmetic faults with no operational impact.

Three refinements make this scheme survive contact with reality. First, write in an explicit named-role clause: certain individuals, at certain times, escalate automatically. The payroll administrator in the two days before pay day, the person operating the goods-in scanner during a delivery window, the practice manager during a clinic session. Providers accept these clauses readily because they are bounded and predictable; without them, your most time-critical single-user faults sit in the P3 queue behind a laptop that will not connect to the projector.

Second, define what a security incident does to the priority. Any suspected compromise, credential theft, business email compromise or ransomware indicator should be an automatic P1 regardless of how many users are affected, because the cost profile of a security incident is driven by dwell time, not by headcount. Where you have already invested in Microsoft 365 email security controls against phishing and BEC, the SLA should specify how alerts from those controls enter the ticket queue and at what priority, otherwise the detection is fast and the response is not.

Third, agree who sets the priority and what happens when the two sides disagree. The healthiest arrangement is that the customer sets the initial priority, the provider may propose a change with a written reason, and unresolved disagreements default to the higher priority until a service manager reviews them. The unhealthy arrangement — and it is common — is that the provider sets priority unilaterally at triage. That is the mechanism by which a provider with a struggling month quietly improves its compliance figures, and it is invisible unless you audit reclassification rates.

Finally, resist the temptation to add a fifth or sixth level. Every additional tier increases the proportion of tickets that arrive with the wrong label, and mislabelled tickets are the primary cause of SLA disputes. Four levels, tightly defined, with a named-role override and a security override, covers the realistic range of an SME or mid-market estate.

Vendor-standard SLA versus a risk-aligned SLA — what actually changes

Nearly every provider leads with a standard tier sheet, and it is usually a reasonable commercial product. The question is not whether it is good but whether it matches the risk profile you calculated earlier. The comparison below sets a typical off-the-shelf UK SME support agreement against a risk-aligned one built from a downtime cost model. The differences are less about the headline minutes than about what is defined, measured and escalated.

Notice what the risk-aligned column does not do: it does not demand faster response across the board. It concentrates the speed where the cost model justified it — a listed set of critical systems — and accepts standard targets everywhere else. That concentration is what makes the commitment affordable for the provider and therefore credible. A blanket fifteen-minute response across all systems and all priorities is either priced accordingly or quietly unmet, and in the SME market it is far more often the latter.

The second thing the right-hand column does is convert informal good intentions into contractual triggers. Every competent provider escalates a stuck P1 eventually. The difference is whether that happens because a service manager noticed, or because the ticketing system escalated automatically at the sixty-minute mark and copied a named director. Time-triggered escalation costs the provider nothing when things go well and is the single most valuable clause in the agreement when they do not.

Third, the update cadence deserves particular attention because it is cheap to grant and disproportionately valuable to hold. A commitment to a substantive written update every thirty minutes during a P1, and every two hours during a P2, transforms the internal experience of an outage. It gives your management team something to communicate, it prevents the provider from disappearing into a diagnostic rabbit hole unobserved, and it produces a timeline that makes the post-incident review factual rather than anecdotal.

The first four hours of a P1 — what a working escalation timeline looks like

An SLA describes obligations; an escalation timeline describes behaviour. The sequence below is the one to write into the agreement as an appendix, because it converts abstract targets into a set of checkpoints that both sides can verify afterwards. Every entry has an owner and a maximum elapsed time. Where a step is missed, the incident review has a specific fact to examine rather than a general sense that things went slowly.

Two details in that sequence do most of the work. The automatic escalation at sixty minutes removes the need for a customer to chase, which is the single most common source of frustration during outages and the least reliable mechanism imaginable. The workaround decision point at ninety minutes forces an explicit trade-off that is otherwise made by default: engineers are trained to fix, and left alone they will keep fixing well past the point where the business would rather have a slow service than no service.

Note also what the timeline does with third parties. Engaging the carrier, the software vendor and the cloud provider in parallel at the sixty-minute mark rather than sequentially after internal diagnosis is exhausted can remove hours from a connectivity or platform incident, because those vendors have their own queues and their own response clocks that start when you raise the case, not when you finish investigating.

Building an escalation process that has authority behind it

An IT support escalation process only works if the people named in it can actually change what happens. Most published escalation matrices list job titles and phone numbers and stop there, which produces an escalation that transfers frustration upwards without transferring resource. A functional process defines three things at each level: who is contacted, what decision that person is empowered to make, and what the maximum time is before the next level is engaged.

On the provider side the levels are usually service desk lead, senior engineer or technical lead, service delivery manager, and operations or account director. The important question to ask during procurement is what each of those roles can authorise. Can the technical lead pull two engineers off scheduled project work? Can the service delivery manager commit an out-of-hours team without a purchase order? Can the account director authorise an on-site visit the same day? If the answers require someone else’s approval, the escalation matrix is a communication tree rather than an escalation process, and it will disappoint you at four o’clock on a Friday.

On the customer side, the equivalent question is who is empowered to accept degraded operation. During a serious incident, the most valuable decision available is often to switch to a workaround, fail over to a secondary system, or send people home and restart in the morning. That decision has commercial consequences and needs an owner who is contactable and authorised. Naming that person in the SLA appendix, with a deputy, avoids the situation where a provider is ready to fail over and spends forty minutes trying to find someone who can say yes.

Get the mechanics right too. Escalation contact details should be reviewed quarterly and tested twice a year, ideally as part of the same exercise you use to validate restore capability — the discipline described in our guide to backup and restore testing applies equally here. A test is simple: outside working hours, call the emergency number, log a test P1, and record how long it takes to reach an engineer who can act. Businesses that run this test are consistently surprised at least once, and it is far better to be surprised during a test than during a ransomware incident.

Finally, agree an explicit de-escalation rule. Incidents that have been resolved but not yet confirmed should not sit at P1 consuming attention, and incidents that were over-classified in the first ten minutes should be downgraded transparently with a note. A process that only escalates accumulates noise until people stop believing the labels.

What UK IT support SLA tiers cost in 2026

Pricing in the UK managed service market is usually expressed per user per month, occasionally per device, and increasingly as a blended figure covering a defined estate. The table below reflects the typical range seen for SME and mid-market agreements in 2026. Treat these as orientation for negotiation rather than a quotation: the figures move substantially with estate complexity, the number of sites, whether server or cloud infrastructure management is included, and how much of the security stack sits inside the contract.

The jump that surprises most buyers is between the enhanced tier and full 24/7. It is not a marginal increase because it is not a marginal service: 24/7 cover requires a rota, which requires a minimum viable team, which the provider must fund whether or not anyone calls at three in the morning. If your genuine requirement is cover for a specific window — a weekend batch run, a Saturday trading day, a month-end process — the add-on model is usually far better value than buying continuous cover you will use six times a year. Define the window precisely in the schedule, including bank holidays, which are otherwise a recurring source of dispute.

Be equally careful with what the per-user figure includes. Two quotes at £55 per user can differ by a third in real annual cost once you account for whether project work is in or out of scope, whether third-party licence management is included, whether on-site attendance carries a call-out charge, and whether the security tooling is bundled or billed separately. Ask every provider to price the same defined scope and to list exclusions explicitly; the exclusions list is more informative than the inclusions list.

One more commercial point. Multi-year agreements with an annual uplift clause are standard, and the uplift is frequently tied to an inflation index with a floor and no ceiling. Negotiate a cap. Over a three-year term, an uncapped index-linked uplift on a £60,000 annual contract is a material and entirely foreseeable exposure.

The SLA clauses that matter more than the headline response time

If you only have an hour to review a proposed managed service SLA, spend it on the eight clauses below rather than on the response-time table. These are the provisions that determine whether the headline number describes reality or describes a measurement artefact.

1. Clock start and clock stop. Find the sentence that says when the response clock begins. It should begin when the ticket is received on any agreed channel. Watch for wording that starts the clock at triage, at the beginning of the next business hour, or on receipt of “sufficient information”. Equally, find what stops it. An automated acknowledgement should not stop a response clock; a substantive human response should.

2. Pause and hold conditions. Most agreements allow the clock to pause while awaiting customer information, third-party action or scheduled access. These conditions are legitimate but must be bounded. Insist that a pause requires a written request naming what is needed, that the clock restarts automatically when the information is supplied on any channel, and that provider-initiated pauses are visible in the monthly report. Unbounded pause rights make any target unenforceable.

3. Ticket reclassification. Establish who may change a priority, on what grounds, and whether reclassification resets the clock. The safest formulation is that reclassification never retrospectively re-baselines an already-breached target and that the monthly report shows the reclassification rate by direction. A provider downgrading 18% of P1s to P2 at triage is telling you something the compliance percentage will not.

4. Hours of cover and the definition of a business day. Check whether the working day is 09:00–17:00 or 08:00–18:00, what happens on the working day between Christmas and New Year, and how English bank holidays interact with Scottish ones if you have sites in both. If any part of your workforce starts at 07:00 or works Saturdays, an SLA that begins at 09:00 leaves your earliest and most operationally exposed staff outside the agreement.

5. Exclusions. Read the exclusions list twice. Common and reasonable exclusions cover force majeure, customer-caused faults, unsupported legacy systems and third-party outages. Common and unreasonable ones cover “issues requiring vendor escalation” without qualification, which excludes a large share of genuine incidents, and “systems not under active management” without a maintained list of what those are. Ask for the list of excluded systems as an appendix that is reviewed quarterly.

6. Service credits and their mechanics. Confirm whether credits are automatic or claim-based. Claim-based credits with a short claim window are rarely claimed, which is why they are popular. Confirm the measurement period, the cap, and whether credits are the sole remedy. A sole-remedy clause combined with a 10% cap means the SLA is the entire extent of your recourse for service failure, which is a point worth raising with whoever signs the contract.

7. Chronic failure and termination triggers. The most valuable remedy is not a credit but the right to exit. Negotiate a chronic failure clause: for example, three consecutive months below 90% compliance, or two P1 breaches in a quarter, gives a right to terminate without penalty on 30 days’ notice. Providers resist this less than expected, because they know that a customer in that position is leaving anyway.

8. Exit and transition assistance. Define what happens at the end: how quickly documentation, credentials, licences and tenancy ownership transfer, at what cost, and with what cooperation obligation. An SLA with strong response times and no exit clause can still leave you unable to move. Ensure administrative ownership of your Microsoft tenant, domain registrations and cloud subscriptions sits with your organisation throughout the term, not with the provider.

A ninth clause is worth adding where your estate depends on identity-based access controls: specify how support access itself is governed. Providers holding standing global administrator rights are a material risk, and the modern alternative — just-in-time, approved, time-boxed elevation — fits naturally alongside a zero trust network access model. Write it into the agreement rather than assuming it.

Where the response window actually goes

When post-incident reviews are analysed across a year of major incidents, a consistent pattern emerges: a substantial share of the elapsed time before real diagnostic work begins is spent on activity that has nothing to do with technical difficulty. It goes on establishing scope, locating documentation, identifying which third party owns the failing component, and finding someone authorised to approve access or a workaround.

That figure is the most actionable number in this guide, because it is the part of your outage duration that no response-time clause can fix. Buying a thirty-minute response instead of a one-hour response saves you thirty minutes. Maintaining an accurate asset register, a documented dependency map, current third-party support contract references and a tested access route can save considerably more, and it costs a day of someone’s time each quarter rather than a permanent uplift in the monthly fee.

This is why the readiness work described earlier is not administrative housekeeping. A provider arriving at a P1 with a current diagram of what depends on what, a list of vendor case-raising details, and a break-glass access path can start diagnosing in minutes. The same provider arriving without those things spends the first part of your SLA window doing discovery you could have done in advance, and you pay for that time twice — once in the fee and once in the outage.

There is a governance point buried here too. If your provider cannot produce a current dependency map on request, that is a service failure in its own right, and it is worth writing a documentation currency obligation into the agreement: the asset and dependency register to be reviewed at each quarterly service review, with a stated maximum age for each record.

Benchmarks — what good performance looks like on each measure

Compliance percentage alone is a poor measure of a service desk, because it can be improved by reclassification, generous pause rules and conservative target setting without any change in the experience of your users. The measures below give a more complete picture, and all of them can be reported from any competent ticketing platform. The percentages shown are the levels at which a UK managed service is performing well; anything materially below suggests a conversation, not necessarily a breach.

Three of those rows are diagnostic rather than performance measures. Reopened tickets indicate that fixes are being applied to symptoms; a rate above 10% almost always points at a first-line team closing tickets to protect resolution figures. Downward reclassification above 8% suggests the priority definitions are ambiguous or that the provider is managing its compliance numbers. Repeat-cause tickets above 12% mean the service is absorbing a recurring fault rather than eliminating it, which is comfortable for everyone in the short term and expensive over a year.

The last row is not negotiable in a mature agreement. Post-incident reviews are the mechanism by which a support relationship improves; without them, the same incident recurs and the SLA merely governs how quickly it is acknowledged each time. Insist on a written review for every P1 and for any P2 lasting more than one working day, delivered within five working days, containing a dated action list with named owners on both sides.

Add one further measure that does not appear in standard reporting packs: average elapsed time from ticket creation to a user being able to work again, measured on P1 and P2 only. It is the only number that corresponds to what the business experienced. Providers rarely offer it because it includes time they do not control, but tracking it alongside the contractual measures makes quarterly reviews substantially more honest.

Scoring your current SLA out of 100

Use the ten questions below to grade an existing or proposed agreement. Award ten points for each unambiguous yes. The scoring is deliberately weighted towards definition and enforceability rather than speed, because a well-defined four-hour commitment is worth more than a vague one-hour one.

The ten questions: are priority levels defined by business impact rather than technology? Does the response clock start at ticket creation on any channel? Are pause conditions bounded and reported? Is there a named-role override for time-critical individuals? Do security incidents automatically become P1? Is escalation time-triggered rather than request-triggered? Is a minimum engineer capability specified for P1? Is there a mandatory update cadence during incidents? Does reporting include reclassification and repeat-cause data? Is there a chronic failure right to terminate?

A score of 56 is typical and is not a crisis; it usually reflects an agreement inherited from a template rather than one that was negotiated. The point of scoring is to identify the two or three cheapest improvements. In most cases the highest-value changes are the clock-start definition, time-triggered escalation and the update cadence, all three of which cost a provider very little and materially change your experience during an incident. Bring them to a renewal conversation with the specific wording drafted, not as a general request for “better service”.

Score again six months after any change, and score the reporting rather than the contract. An agreement can be improved on paper and unchanged in practice; the monthly report is where you find out which.

Out-of-hours, bank holidays and the 24/7 question

The question of whether to buy round-the-clock cover is usually framed as a cost decision when it is really a risk-window decision. The useful analysis is not “can we afford 24/7?” but “during which hours outside the standard working day would an unresolved incident cause material harm, and how many such hours are there in a year?” For a professional services firm with no overnight processing, the honest answer may be fewer than fifty hours, concentrated around month-end and year-end. For a logistics operation loading vehicles from 04:00, it is every weekday morning.

Once you have the hours, the buying options separate cleanly. A full 24/7 tier suits businesses with genuine continuous operation or a regulatory obligation to maintain availability. A defined-window extension — for example 06:00–22:00 weekdays plus Saturday mornings — suits the majority of UK SMEs and costs far less than continuous cover. A P1-only out-of-hours retainer suits businesses whose overnight risk is catastrophic but rare: nobody is working, but a ransomware detonation at 02:00 must not wait until 09:00.

Whatever you buy, three details need writing down explicitly. First, bank holidays: England and Wales, Scotland and Northern Ireland differ, and a multi-site business needs the schedule to state which calendar applies where. Second, the Christmas period: many providers operate reduced cover between Christmas and New Year, and this should be a stated schedule agreed each autumn, not a surprise discovered on 28 December. Third, the mechanism: is out-of-hours reached by the same number, a different number, or an escalation from an answering service? Test it, and test it from a mobile phone rather than an office extension.

There is a related question about security monitoring that is often conflated with support cover. A support SLA governs how quickly a provider responds to something you have reported. It does not, by itself, mean anyone is watching. If your risk model includes out-of-hours compromise, you need either a monitoring service with its own detection-to-response commitment or an explicit acceptance that detection depends on someone noticing in the morning. Buying a 24/7 support SLA and assuming it delivers monitoring is a common and expensive category error.

Finally, consider what out-of-hours cover is for in your specific case. If the realistic overnight scenario is a failed connectivity circuit or a failed cloud region, response speed may matter less than automated failover, since a human responding at 02:00 can only do what the architecture allows. Where that is true, the money is better spent on resilience than on rota cover, and the SLA should be written to match the architecture rather than to compensate for its absence.

How your support SLA should relate to your recovery objectives

Support response times and recovery objectives are usually written by different people at different times, and they frequently contradict each other. A business with a documented four-hour recovery time objective for its finance system, supported under an agreement with a four-hour P1 response target and no resolution commitment, has an arithmetic problem: the recovery window is entirely consumed before work is guaranteed to have started.

The reconciliation rule is straightforward. For any system with a stated recovery time objective, the support response target must be a small fraction of it — a reasonable working figure is no more than one eighth — and the escalation checkpoints must fall inside it. A four-hour RTO implies a thirty-minute response, a sixty-minute third-line escalation and a ninety-minute failover decision point, all of which appear in the timeline earlier in this guide. If the provider cannot commit to that shape for the systems in question, either the RTO is aspirational or the tier is wrong.

The same logic applies in reverse to recovery point objectives. An RPO is a statement about data loss, and it is delivered by backup architecture rather than by support response. But the support agreement determines how quickly a restore is initiated, who authorises it, and whether the provider is contractually obliged to have tested the restore path. Businesses regularly discover during an incident that their backups were sound and the restore took eleven hours because nobody had ever run one at full scale. That is an SLA and readiness failure rather than a backup failure, and it is exactly what routine restore testing is designed to expose.

Cloud and hybrid estates add a dependency worth naming in the schedule. When the failing component belongs to Microsoft, Amazon or your connectivity carrier, your provider’s obligation changes from fixing to managing: raising the vendor case at the correct severity, chasing it, communicating updates, and implementing whatever workaround is available. Write that obligation down. Without it, “third-party outage” becomes an exclusion that ends the conversation rather than a category of incident with its own defined handling.

Connectivity deserves a specific mention because it is the dependency most often assumed rather than designed. If a single circuit failure takes a site offline, no support SLA can restore service faster than the carrier’s own repair commitment, which for a standard business broadband service is measured in days rather than hours. Where that is unacceptable, the answer is a second path, and the design questions are covered in our guide to business broadband failover and redundancy. The support SLA should then govern how quickly failover is detected, confirmed and communicated — a much more achievable commitment.

Common mistakes when negotiating an IT support SLA

The failures below recur across UK managed service relationships regardless of provider size. None of them are exotic; all of them are cheaper to avoid at contract stage than to fix at renewal.

• Comparing headline response times across providers. Two agreements advertising a one-hour P1 response can differ by hours in practice depending on clock definitions, pause rights and reclassification. Compare the definitions, then the numbers.
• Buying uniform speed across all priorities. Paying for a fast response on password resets funds urgency where nobody needs it. Concentrate the commitment on a listed set of critical systems and accept standard targets elsewhere.
• Treating service credits as compensation. Credits are typically capped at 5–10% of a monthly fee and function as a governance trigger, not a financial remedy. If financial protection is the objective, that is a business interruption insurance conversation.
• Leaving priority setting entirely with the provider. Unilateral triage classification is the mechanism by which compliance percentages improve without service improving. Retain the right to set initial priority and audit the reclassification rate.
• Ignoring the exclusions appendix. The list of unsupported systems, excluded scenarios and out-of-scope work defines the real boundary of the service. Review it annually; legacy systems have a habit of quietly entering it.
• Not testing the out-of-hours route. Emergency numbers change, answering services get replaced, and rotas move. An untested escalation path is an assumption, and it fails at the least convenient moment.
• Omitting a chronic failure or exit clause. Without a defined trigger, persistent underperformance produces a series of uncomfortable meetings and no leverage. A right to terminate for repeated breach changes the character of those meetings.
• Never reviewing the agreement after signature. Estates change, headcount changes, and systems become critical that were not critical when the schedule was written. An SLA reviewed once a year against a current criticality list stays useful; one filed after signing does not.

A worked example — a 62-person Leeds manufacturer

A precision engineering business with 62 staff across an office and a production floor held a standard managed service agreement: one-hour P1 response, 09:00–17:30 cover, four-hour target fix, credits capped at 10%. On paper the provider was performing well, reporting 94% compliance for eleven consecutive months. Internally the perception was the opposite, and the finance director could not reconcile the two views.

The reconciliation exercise took a morning. Production started at 06:30, so the two hours in which a fault most disrupted output sat entirely outside the hours of cover. The works order system had been classified as a standard business application rather than a critical system, so its failures were logged as P2. And because a large share of tickets were paused as “awaiting customer” whenever an engineer needed to visit the shop floor — where the affected operator was working and not at a desk — the reported elapsed times bore little relation to the real ones. Nothing in the provider’s reporting was inaccurate; it was measuring a service the business had not intended to buy.

The renegotiated agreement changed four things and left the price broadly flat. Cover was extended to 06:00–18:00 on weekdays, funded by moving from a blanket one-hour P1 target to a thirty-minute target on a named list of six critical systems and a two-hour target on everything else. The works order system, the ERP and the label printers used for despatch went onto the critical list. Pause rights were bounded, with shop-floor access treated as a provider logistics matter rather than a customer delay. Escalation became time-triggered at sixty minutes with the operations director copied automatically.

The reported compliance figure fell, from 94% to 89%, because it was now measuring something harder. Reopened tickets fell as well, and the number of incidents that reached the operations director’s attention as complaints rather than as automatic escalations dropped to near zero over the following two quarters. The finance director’s summary at the annual review was that the business had stopped buying a percentage and started buying a response.

We had spent three years arguing about a number that turned out to be measuring the wrong hours, the wrong systems and a clock that stopped every time our engineer walked onto the shop floor. Fixing the definitions cost us nothing and changed more than any discount would have.

The transferable lesson is that the gap between reported and experienced service is almost always a definitional gap rather than a performance one. Before changing provider — an expensive, disruptive process with its own transition risk — check whether the existing provider is being measured against the service you actually need. In a significant proportion of cases they are not, and the remedy is a redrafted schedule rather than a procurement exercise.

The 12-point IT support SLA review checklist

Work through this list against any existing agreement or draft proposal. Each item should produce a written answer that can be pointed to in the contract, not an assurance given in a meeting.

1. Criticality list. A named, dated list of systems classified as critical, important and standard, reviewed at least annually and owned by a business person rather than by IT.
2. Cost-of-downtime model. An hourly cost figure for each critical system, built from productivity, revenue, recovery and regulatory components, and signed off by finance.
3. Priority definitions. Four levels defined by business impact, with a named-role override for time-critical individuals and an automatic P1 rule for suspected security incidents.
4. Clock definitions. Explicit start point at ticket creation on any agreed channel, explicit stop point at substantive human response, and bounded, reported pause conditions.
5. Response and resolution stated separately. Response as a guarantee; resolution as a target with a mandatory update cadence during open incidents.
6. Hours of cover. Matched to actual working patterns including early shifts and weekend operations, with bank holiday calendars stated per site and the Christmas schedule agreed annually.
7. Engineer capability on P1. A minimum skill level or team specified for critical incidents, with automatic third-line escalation at a defined elapsed time.
8. Escalation appendix. Named contacts on both sides with stated decision authority, deputies, and a documented de-escalation rule. Reviewed quarterly, tested twice yearly.
9. Third-party handling. A defined obligation covering how vendor and carrier cases are raised, at what severity, by whom, and how they are chased and reported.
10. Reporting pack. Monthly compliance by priority, reclassification rate by direction, reopen rate, repeat-cause analysis, and elapsed time to service restoration on P1 and P2.
11. Remedies and triggers. Service credit mechanism with automatic application, plus a chronic failure clause giving a right to terminate for defined repeated breach.
12. Exit provisions. Documentation, credential and tenancy transfer obligations, timescales and costs, with administrative ownership of all cloud tenancies retained by your organisation throughout.

At a glance — IT support SLA essentials for UK businesses in 2026

How Cloudswitched approaches IT support SLAs

Cloudswitched works with UK businesses to build support agreements from the risk position outwards rather than from a tier sheet inwards. That means starting with a criticality list and a cost-of-downtime model produced with your finance and operations teams, translating those into priority definitions and response targets that concentrate speed where it changes the outcome, and writing the escalation, measurement and reporting mechanics that make the commitment enforceable. Where an existing agreement is already in place, the same exercise usually identifies definitional changes that improve the experience without increasing the fee.

Frequently Asked Questions

What is a good IT support SLA response time for a UK SME?

For most UK SMEs of 20 to 150 staff, a one-hour P1 response during extended business hours is a reasonable baseline, with a thirty-minute target on a short named list of critical systems. The right answer depends on your cost of downtime rather than on a market average: if an hour of total outage costs you £2,000 in lost productive time, the difference between a four-hour and a one-hour response is worth roughly £6,000 per incident, which usually justifies the tier difference after two or three incidents a year. If your critical systems have failed twice in three years and both were resolved quickly, a standard tier is likely to be adequate and the money is better spent on resilience.

What is the difference between response time and resolution time in an SLA?

Response time is a commitment to acknowledge a ticket and begin substantive work within a stated window. Resolution time, sometimes called fix time, is a commitment to restore service. In UK managed service agreements, response is almost always a guarantee backed by service credits, while resolution is expressed as a target with substantial exclusions covering third-party dependencies, hardware lead times and anything outside the provider’s control. Many SME agreements contain no resolution commitment at all. Always check which of the two the headline number in a proposal refers to, because providers quote response and buyers frequently hear resolution.

How should priority ticket levels be defined?

Define them by business impact, not by technology. A workable four-level scheme treats complete loss of a business-critical service or any suspected security incident as P1, significant degradation with a slow workaround as P2, a single user unable to perform part of their role as P3, and requests and cosmetic faults as P4. Add two overrides: a named-role clause so time-critical individuals such as a payroll administrator at month-end escalate automatically, and a rule making any suspected compromise a P1 regardless of how many users are affected. Avoid schemes with five or more levels, as mislabelling increases sharply and mislabelled tickets are the main source of SLA disputes.

Are IT support service credits worth negotiating?

They are worth having but should not be mistaken for compensation. Credits in the UK market are typically capped at 5 to 10 per cent of a monthly fee, which for a £4,000 monthly contract means a maximum remedy of a few hundred pounds against an outage that may cost tens of thousands. Their real value is as a governance trigger: an automatic credit forces a conversation and creates a written record of underperformance. If you have limited negotiating capital, spend it on time-triggered escalation, a mandatory update cadence and a chronic failure termination right rather than on raising the credit percentage.

When does the SLA clock start on a support ticket?

That depends entirely on the wording, which is why it is one of the first clauses to check. The customer-favourable position is that the clock starts when the ticket is received on any agreed channel — portal, telephone, email or an automated monitoring alert — and stops when a named engineer posts a substantive human response. Provider-favourable wording starts the clock at triage, at the start of the next business hour, or on receipt of sufficient information, and stops it on an automated acknowledgement. Two agreements advertising the same response time can differ by hours in practice purely on this definition.

Do we need 24/7 IT support cover?

Answer it by counting hours rather than by comparing prices. Identify the hours outside your standard working day during which an unresolved incident would cause material harm, and how many such hours occur in a year. Many UK professional services firms find the figure is under fifty hours, concentrated around month-end, which makes a defined-window extension or a P1-only out-of-hours retainer far better value than continuous cover. Businesses with early shifts, weekend trading, overnight processing or regulated availability obligations generally do need full cover. Note that a 24/7 support SLA is not monitoring; it governs how fast a provider responds to something you report, not whether anyone is watching.

How do we know if our provider is meeting the SLA?

Compliance percentage alone is insufficient because it can be improved by reclassification and generous pause rules without service improving. Ask for a monthly pack containing compliance by priority level, the reclassification rate broken down by direction, the reopen rate within five working days, repeat-cause analysis, and the average elapsed time from ticket creation to users being able to work again on P1 and P2. Downward reclassification above roughly 8 per cent at triage and a reopen rate above 10 per cent both warrant investigation regardless of what the headline compliance figure says.

What should an IT support escalation process actually contain?

Three things at every level: who is contacted, what that person is empowered to decide, and the maximum elapsed time before the next level is engaged. A list of names and telephone numbers is a communication tree, not an escalation process. During procurement, ask specifically whether the technical lead can pull engineers off project work, whether the service delivery manager can commit an out-of-hours team without a purchase order, and whether the account director can authorise same-day on-site attendance. Escalation should also be time-triggered so it happens automatically rather than depending on a customer noticing and chasing.

Can we change our SLA mid-contract?

Usually yes, and more easily than most businesses expect. Definitional changes — clock start points, bounded pause conditions, priority definitions, escalation timing, update cadence and reporting content — cost a provider very little and are frequently agreed at a service review without a price change. Changes that alter the cost base, such as extending hours of cover or tightening response targets, are commercial and normally land at renewal. Bring specific drafted wording rather than a general request; providers respond far better to a marked-up schedule than to a complaint about service quality.

How does an IT support SLA relate to our disaster recovery plan?

They need to be reconciled, because they are usually written separately and often contradict each other. For any system with a documented recovery time objective, the support response target should be a small fraction of it — no more than about one eighth is a workable rule — and the escalation checkpoints should fall inside the recovery window. A four-hour recovery objective supported by a four-hour response target is arithmetically impossible. The SLA should also define how the provider handles restores: who authorises them, how quickly they are initiated, and whether the restore path has been tested at full scale rather than assumed.

What happens if a third party causes the outage?

Check whether your agreement treats third-party outages as an exclusion or as a category of incident with defined handling. The customer-favourable position is that the provider’s obligation changes from fixing to managing: raising the vendor or carrier case at the correct severity, chasing it, maintaining the update cadence with you, and implementing any available workaround. Without that written down, “third-party outage” ends the conversation rather than triggering a process. Ensure the provider holds current vendor support contract references and case-raising details for every third party in your critical path.

Should we switch provider if the SLA is being missed?

Not before checking whether the provider is being measured against the service you actually need. A large share of reported-versus-experienced service gaps turn out to be definitional: the hours of cover do not match when people work, a critical system was never classified as critical, or pause rules are absorbing real elapsed time. Redrafting the schedule is cheaper and less disruptive than a transition, which carries its own risk during the handover period. If performance remains poor against a correctly defined agreement, a chronic failure clause gives you a clean exit route, which is why it is worth negotiating one before you need it.

Related reading

Support response times sit alongside the resilience, recovery and security decisions that determine how often you need them. These guides cover the adjacent questions most often raised during an SLA review.

• Backup Restore Testing: A UK Business Guide to Proving Your Cloud Backups Actually Work in 2026
• Azure Disaster Recovery: A UK Business Guide to Building a Tested Failover Plan for Cloud Servers in 2026
• Business Broadband Outages: A UK SME Guide to Building Failover and Redundancy Into Your Internet Connection in 2026
• Email Security in Microsoft 365: A UK Business Guide to Stopping Phishing, Spoofing and Business Email Compromise in 2026
• Zero Trust Network Access for UK Businesses: A Practical Guide to Replacing VPNs with ZTNA in 2026