A ten-person business can lose its entire team within minutes. Not to a disaster, just to Microsoft 365 going down, a key app failing, or a shared drive nobody can reach, with no one answering the phone. Everyone sits there. Nobody bills, sells, or ships anything, and the meter is still running.
Every provider says they offer “fast” support. It’s a meaningless word until you break it into what actually gets measured.
The three clocks that actually matter
A fast acknowledgement email is not the same as your team working again. There are three separate things to time, and a provider who only quotes you one of them is quoting you the easy one.
- Response: an engineer actually owns the issue. Example target: 15 minutes.
- Restoration: users have a safe working service again, even if it’s a workaround. Example target: 4 hours.
- Resolution: the root cause is fixed and documented, not just patched over. Example target: 2 business days.
NCSC guidance on recovering from an attack makes a similar point from the security side: the needs of the business, not solely IT considerations, should drive prioritisation for recovery. Ask any provider to report all three numbers separately. If they can only give you one, it’s worth asking why.
Not everything is an emergency, so stop treating it like one
Set priority by actual business impact: lost revenue, customer harm, legal exposure, or how many people can’t work.
- P1: core systems down, or a live security risk
- P2: a whole team can’t work, but a workaround exists
- P3: one person, limited impact
Review these bands with your provider every quarter as the business changes. It’s the difference between “fast support” as a slogan and something you can actually hold someone to.
Proactive means prevented incidents, not a screen full of green lights
A dashboard that only tells you something’s wrong after a user has already complained isn’t proactive, it’s just a slightly earlier complaint. NCSC’s security monitoring guidance says the same in more formal language: good monitoring is more than simply collecting logs. It also takes appropriate tools and skilled analysis to spot indicators of compromise in a timely way, so that action can be taken.
Ask your provider three things:
- Which alerts trigger an automatic fix, and which need a human?
- Who checks the high-risk alerts, and how fast?
- How do you prove a fix actually worked?
Then ask for a monthly list of incidents that were prevented, not resolved. That list is the real evidence proactive support is doing anything.
Every outage deserves an autopsy, not just a fix
Any outage that actually hits work should get a short review within five working days: what caused it, what it cost the business, what permanently changed as a result, and who’s accountable for that change happening. NCSC’s lessons-learned guidance puts it plainly: the aim should be to address the root cause or systemic problems, rather than fix a very narrow issue. A cause backed by evidence, a permanent control change, and a follow-up that’s actually tested and signed off, that’s the standard. Anything vaguer is a shrug with extra steps.
If it’s in the cloud, “it’s backed up” isn’t good enough on its own
Set a recovery time objective and recovery point objective for each system that matters, not one blanket promise for everything. Payroll might need to be back within four hours. Old file archives can wait a lot longer. Agree the numbers in writing, then actually test them twice a year.
NCSC’s principles for ransomware-resistant cloud backups say a backup service should refuse destructive requests from ordinary customer accounts unless they’re authorised out of band, and should let you test that you can actually restore. Plain cloud storage doesn’t give you either by default, so ask how your provider handles both. Confirm 24/7 alerts on failed backups, real version history, and whether capacity can grow without disrupting the service already running.
What to actually ask before you sign anything
- How fast do you respond, restore, and resolve, as three separate numbers?
- What does the price actually cover: support, monitoring, patching, backups, and where do project limits kick in?
- How do you prove recovery works, and when did you last test it?
- Can I speak to three current clients?
Check after-hours cover and call-out fees before you need them, not after. Price onboarding and exit support separately too, since that’s where surprise invoices tend to live.
A cheap contract can cost far more than a fair one, if it’s critical systems that stay down while you wait. If you’re also comparing this against what an in-house hire would cost instead, the same rule applies: price the whole outcome, not the monthly line item.
Common questions about IT support response times
What is the difference between response time, restoration time and resolution time?
Response time is how quickly an engineer takes ownership of your issue. Restoration time is how long until users can work safely again, even if that is through a workaround. Resolution time is how long until the root cause is fixed and documented. A provider should report all three separately.
What is a good response time for IT support?
It depends on the priority of the issue and the plan you buy, so agree targets by priority level and get them in writing. A critical outage, such as core systems down or a live security risk, deserves a much faster response than a single user with a workaround.
What is an SLA in IT support?
A service level agreement (SLA) is the part of your contract that sets out what the provider commits to: response and resolution targets for each priority, the hours they cover and what happens if they miss them. An SLA normally sets a maximum time rather than an average, so ask how often the provider beats it.
What are RTO and RPO?
Recovery time objective (RTO) is how long you can afford a system to be unavailable. Recovery point objective (RPO) is how much recent data you can afford to lose, measured in time. Payroll might need a four-hour RTO, while an old file archive can wait longer. Agree both in writing for each key system.
How often should I test my backups?
At least twice a year, and after any major change to your systems. The NCSC’s backup principles say system owners should be able to test that they can restore, as part of a regular monitoring process. A backup you have never restored from is only a hope.