What a managed IT agreement should actually say
Most disputes with an IT provider are not about competence. They are about a scope nobody read closely, discovered one quote at a time.
The complaint is rarely that the work was bad. It is that a monthly fee was being paid and the thing that needed doing still came with a quote attached.
That is a scope problem, and it is almost always visible in the agreement if anyone goes back and reads it. The trouble is that agreements get read carefully once, at signing, when everyone is optimistic, and the parts that matter are the parts that only become interesting later.
The questions worth asking before you sign
What counts as included support, and what counts as a project? This is the big one, because it is where “everything is a quote” comes from. Every provider draws a line. A reasonable agreement draws it explicitly and gives examples on both sides. An unreasonable one leaves it to be decided case by case, which in practice means decided by whoever has the commercial incentive.
Is the fee per user, per device, or per site? All three are defensible. What matters is that you can predict the bill when you hire five people or open a second site, and that you know what happens to the fee when someone leaves.
Who owns the licences and the tenancy? If the provider holds your Microsoft tenancy under their own agreement, leaving them is a migration rather than a handover. This is the single most common thing businesses discover too late. Your tenancy, your domain and your data should be yours, with the provider holding delegated access they can be removed from.
What is the response commitment, and to what? A four hour response to an acknowledgement email is not the same as four hours to someone working on it. Ask which one is being promised, and what happens when it is missed.
Who is accountable, by name? Not a queue. If the answer is an 0800 number and a ticket form, then nobody is thinking about your business between incidents, and you will only ever get what you ask for.
What is explicitly excluded? A good agreement has a list. Line of business applications, third party vendor management, out of hours, cabling, hardware supply, anything under a separate vendor’s support contract. Exclusions are not a red flag. Silence about exclusions is.
The parts about leaving
Read the exit clauses before the service clauses. They tell you more about the relationship than the service levels do.
- Notice period. Three months is normal. Twelve is a lock-in.
- Offboarding. Is documentation, credential handover and reasonable transition assistance included, or chargeable at a rate set later?
- Documentation ownership. Network diagrams, asset registers and passwords built up over years are records of your environment. If they leave with the provider, you are paying someone to rediscover them.
A provider confident in the work has no reason to make leaving hard. The ones that do are relying on friction rather than performance, and that tells you what to expect once the honeymoon ends.
What we think an agreement is for
An agreement is not a shield for either side. It is a written answer to “what did we actually agree”, so the conversation in month fourteen is short.
Ours are meant to be readable. Defined inclusions, a stated list of exclusions, your tenancy in your name, named people rather than a queue, and an exit that does not require negotiation. Assessments, roadmaps and system selections are priced on their own, so the recommendation is not shaped by what the monthly fee happens to cover.
If you are reviewing an agreement, yours or someone else’s, the exclusions list and the exit clause are where to start. That is where the surprises live.