What to look for in an IT support contract

Response time vs resolution time: the distinction that matters

Most SLAs define response time – how quickly someone acknowledges the issue. Far fewer define resolution time – how quickly it gets fixed. A 1-hour response SLA with no resolution commitment means someone emails you within an hour – and the problem could still be outstanding three days later.

That distinction matters enormously during an incident. Knowing a ticket has been acknowledged is cold comfort when your team can't access email, your point-of-sale system is down or a client-facing service is unavailable. Acknowledgement without resolution is just administration.

What to ask for: tiered SLAs that define response and resolution targets by severity, with clear definitions of what "critical", "high" and "standard" mean. A critical issue – say, a total network outage affecting the whole business – should have both a response target and a resolution target. Standard issues, such as a single user locked out of an account, can reasonably have longer windows. The important thing is that both targets are written into the contract, not left to interpretation.

What "unlimited support" means in practice

Unlimited usually means unlimited helpdesk calls for standard issues. It rarely means unlimited project work, on-site visits, hardware procurement, server administration or out-of-hours cover.

The word unlimited is used because it's commercially attractive. It implies you can call as often as you like and the bill won't change. That's broadly true for break-fix requests on covered devices – a user can't print, a laptop won't connect to Wi-Fi, an application is throwing an error. It is almost never true for anything that looks like a project: migrating to a new platform, setting up a new office, deploying a new system or rolling out a significant configuration change.

Read the scope definition carefully. What counts as "support" and what is billed separately as a project or out-of-scope work? This is the most common dispute trigger in IT support contracts. Providers aren't always being deliberately misleading – the ambiguity is often a symptom of contracts that weren't written with edge cases in mind. But ambiguity in your favour is rare. When there's a dispute about scope, the provider's interpretation usually wins unless your contract is explicit.

Scope: what's in, what's out

The contract should define the device count, the systems covered, the locations covered and the applications covered. Each of these is an area where assumptions get made and disputes arise.

Cloud platforms are a common exclusion. Microsoft 365, line-of-business applications and third-party SaaS tools may be explicitly outside scope – meaning the provider will help with general access issues but won't support the application itself or troubleshoot integration problems. If your business depends on specific platforms, check whether they're named in the contract.

Out-of-hours and weekend cover is standard for some providers and an add-on for others. If your business operates outside 9–5 or has users in different time zones, understand exactly what you're getting and what it costs. The same applies to on-site visits: some contracts include a certain number of on-site days per year, others charge per visit. If your team can't resolve things remotely, you need to know what a call-out costs.

New employees and device setups are another frequent grey area. Onboarding a new starter – setting up their device, creating accounts, configuring access – is a standard task in most businesses. Whether it's included in your monthly fee or billed per setup varies. In a business that hires regularly, this adds up.

Exit clauses and data handover

Most SME IT support contracts run for a minimum of 12 to 36 months, with notice periods of 30 to 90 days. Understand both before you sign. The minimum term sets the floor on your commitment; the notice period determines how far in advance you need to act when that term ends. Some contracts roll over automatically if notice isn't served in a specific window – meaning a missed deadline locks you in for another year.

What happens at the end of the contract is equally important. Your provider should commit in writing to providing all admin credentials, documentation, licence keys and system access at exit. This is often absent from standard contracts and needs to be added before you sign.

Some providers use access to credentials as leverage to prevent switching. This ranges from being slow to respond to handover requests to, in more serious cases, maintaining control of domain accounts or cloud tenancies registered in the provider's name rather than yours. It's a red flag – both as a practice and as a signal about how that provider thinks about client relationships. If a provider objects to including a clear credential handover commitment in the contract, treat that as a reason to walk away.

If data return obligations are mentioned in the contract, document what format the data will be returned in and by what deadline. If they're not mentioned, negotiate this before you sign. After you've signed or served notice, your leverage is considerably reduced.

Hidden costs to watch for

The headline monthly fee is rarely the full picture. The areas where additional charges appear most often:

• Per-incident charges that apply after a monthly incident cap – some contracts limit the number of tickets before overage billing kicks in
• Travel and call-out fees not mentioned in the headline price
• Licence costs passed through at margin – software and subscription renewals procured on your behalf at above-list prices
• Hardware at above-market prices, particularly for commodity items like switches, access points and cables
• Out-of-scope charges for work that wasn't made clear at signing – particularly onboarding, project work and platform migrations

A useful test: ask the provider for three real examples of work that would be billed outside the monthly fee. How they answer tells you a lot. A confident, specific answer suggests they've thought about scope clearly. Vagueness or reluctance suggests the boundary between included and billable isn't well defined – and that ambiguity will cost you at some point.

Before you sign: the questions to ask

Due diligence before signing an IT support contract takes an hour or two. Undoing a bad contract takes months. These are the questions worth asking before you commit:

• Can you speak to two or three existing clients of similar size? Not just the references the provider volunteers – ask specifically for customers who have been with them for at least two years.
• What is the escalation path if first-line support can't resolve the issue? Who picks it up, how quickly and what happens if it's still unresolved after 24 hours?
• What is the process for reporting and tracking issues? Is there a ticketing system you can log into? Can you see the status of open tickets without calling?
• How is out-of-hours contact handled? Is there a number to call, or a process to follow? What's the expected response time and who responds?
• What documentation will you maintain and hand over at contract end? System diagrams, credential records, asset registers – what gets written down and where is it kept?

A provider who answers these questions clearly and specifically – without hedging or redirecting – is likely to be straightforward to work with. One who struggles with basic process questions at the sales stage will not become more organised once you're a paying customer.