What managed IT support should actually include, and what quietly gets left out

The awkward thing about buying IT support is that you find out what you bought at the worst possible moment: the morning nothing works. That is when the phrase in the brochure gets tested against the clause in the schedule, and the two are not always the same document.

None of this is about anyone being dishonest. A provider has to draw a line somewhere or the maths does not work. The problem is when it is drawn quietly.

Ask for response times in writing. Everyone will give you them. Then read what the number attaches to, because response and resolution are different promises and only one is usually being made.

A response time is how long before a human acknowledges your ticket. An acknowledgement is not a fix, and a contract that only commits to response is committing to answering the phone. Better contracts add a target to start work and a target to resolve, with wider bands and honest caveats, because nobody can commit to fixing a problem they have not yet seen.

Then look at the clock itself. Is it counting working hours or real hours? If cover is nine to five on weekdays and you raise something at half past four on a Friday, a four hour response can legitimately land on Monday morning. That may be perfectly acceptable. It is not acceptable to discover it on the Monday.

Check who decides the priority, too. If the provider grades every ticket themselves, the response times are whatever they choose. Reasonable contracts define severity by business impact: all users down, one user down, one user inconvenienced.

A named engineer is the biggest quality difference in small business IT support, and it is the thing most often implied rather than promised. There is a large gap between someone who already knows that your line of business software hates the newest print driver, and a stranger reading your history cold while you wait.

So ask what happens when that person is on holiday, ill, or busy with someone else's outage. The honest answer is not that you always get the same person, because nobody can keep that promise. It is that a second engineer is also familiar with your setup, and that your documentation is good enough that a third could pick it up without ringing you for the passwords.

That is the real test. A provider who genuinely knows your business has written it down. If it all lives in one person's head, you are renting a memory rather than buying a managed service.

Patching is the least interesting line in any contract and the one that does the most work. It is also where scope quietly narrows, because there are several layers and a contract can cover one while implying all of them. Windows updates on staff laptops are the easy layer. The layers underneath get patchier: server operating systems, the third party software everyone actually uses, firmware on the firewall and the switches, and the line of business application that needs a vendor engineer and a scheduled outage.

Ask two practical questions about it. When do reboots happen, and who tells the staff? A patch downloaded but never applied because nobody restarts the machine is not a patch. And is there a monthly report listing what is compliant and what is not? Patching you cannot see is patching you are taking on trust, and the point of paying someone is that you no longer have to.

The companion test is the asset list. Ask for a list of what you own: every laptop, desktop, server, firewall, switch, access point and printer, with who has it, what it runs, when the warranty ends and when the software goes out of support. If a provider can produce that within a few weeks of starting, they are watching your estate. If they cannot produce it after a year, nobody is.

Onboarding a new starter is the visible half and it gets attention, because someone is standing there on their first morning waiting for a laptop. Offboarding is the invisible half, and it is where the risk sits.

A leaver who is not properly offboarded keeps a live mailbox, a live login, access to shared files, a licence you are still paying for, and often a device at home. Weeks later nobody is sure whether the account was disabled or just hidden from the address book. That is the account that turns up in an audit, or in a breach.

A contract should say who does what here, and how fast. In our experience a workable arrangement is that you tell the provider before the last day, accounts are disabled rather than deleted, mail is redirected so nothing is lost, the licence is reclaimed at the next billing point, and the device is collected and wiped with a record that it happened. Ask whether that sits inside the per user fee or is billed as an extra. Both are legitimate; only one is what you assumed.

None of these are unreasonable exclusions. They only become a problem when you find out about them during an incident. Ask about each one specifically and write down the answer.

You do not need to be technical to do this well. You need to be specific, and you need to write the answers down so that the conversation you had is the same as the one in the file.

Good support is boring. Things break less often, what does break gets fixed without a negotiation about whose job it was, and once a quarter someone explains in plain English what is ageing and what belongs in next year's budget.

Our own managed service is priced per user, in a published band of £55 to £150 per user per month. If you want a second opinion on a contract you already have, send us the schedule and we will tell you what it does and does not commit anyone to.