How to read a managed services agreement

Most managed services agreements are not adversarial documents. They are drafted by providers who intend to do good work, and the contentious clauses are usually there because the provider was burned once and added a paragraph. That does not make them harmless to sign unread.

The clauses that cause problems are rarely the ones about money. Price is visible, comparable, and negotiated hard by everyone. The clauses that cause problems are the ones defining what is in scope, what happens when something ambiguous breaks, who owns the operational knowledge, and how the relationship ends. These are less visible, harder to compare, and frequently accepted as boilerplate.

This is written from the provider's side of the table, which is an unusual vantage point for this advice. We would rather clients understood what they were signing, because in our experience the disputes that damage a relationship are almost always disputes about expectations that were written down clearly and never read.

Scope: the covered and the ambiguous

Every agreement lists what is covered. Fewer are explicit about the boundary conditions, and the boundary is where the arguments happen.

Ask what happens with a problem that is inside your environment but caused by a third party. Your line goes down; it is the ISP's fault. Does your provider coordinate with the carrier, or hand you a ticket number and step back? Both are defensible positions. Only one of them is what you probably assumed.

Ask about applications. Infrastructure support is well-defined. Application support is not. If your ERP is behaving oddly, is that in scope? Usually the answer is that the provider supports the platform it runs on and will escalate to the vendor, which is reasonable — but "we support the server, not the software" is a sentence best heard during procurement.

Ask about the count. Per-user and per-device pricing both have edge cases. Does a user with a laptop, a desktop and a phone count once or three times? What about a shared workstation used by twelve shift workers? What about a service account? Get the counting rule written down, because it determines your bill.

Ask about project versus support. This is the most common source of unexpected invoices. Routine support is included; projects are billed. The boundary is usually defined by effort or by whether the work constitutes a change rather than a restoration. A vague boundary means every substantial request becomes a negotiation.

Exclusions worth finding

Read the exclusions before the inclusions. It is a faster route to understanding the agreement.

Security incident response is very often excluded from standard managed services, or included only to a defined number of hours. This surprises people, because "you manage our security" reads as though a breach is covered. Forensic investigation, legal coordination, regulatory notification and rebuild are specialist, expensive, and normally a separate engagement or a retainer. Find out which, in advance.

Out-of-support software is usually excluded, and reasonably so — no provider can commit to securing something the vendor no longer patches. But if you are running an application that requires an old operating system, that exclusion may cover a system you consider central. Name it explicitly and agree what happens.

Acts of the client. Most agreements exclude problems caused by unauthorised changes made by client staff. Fair. But it means your internal team's administrative access is a contractual question, not just a technical one. If your developers have production access, that should be acknowledged in the agreement rather than discovered during an incident.

Data ownership and access

This section is short, and it is the one to get right.

Your data is yours. That should be stated explicitly, including monitoring data, logs, ticket history, documentation and configuration backups generated during the engagement. If the agreement is silent, it is worth adding a sentence.

Documentation deserves particular attention. Over three years of a relationship, your provider accumulates the operational knowledge of your environment: network diagrams, dependency maps, runbooks, credentials, why that firewall rule exists. That knowledge is a substantial asset, and where it lives determines your leverage. We take the position that it is client property and provide it on request in a portable format, because the alternative is a relationship sustained by hostage-taking rather than by quality of service.

Credentials should never be held solely by the provider. If the only path to your domain administrator account runs through your MSP's password vault, you have a dependency that a contract dispute converts into an emergency.

Exit is the clause you negotiate at the start

Nobody wants to discuss the end of a relationship at the beginning of it. Do it anyway, because your negotiating position will never be better than it is before you sign.

The mechanics that matter are notice, transition support, and handover. A thirty-day notice period sounds generous until you try to migrate a full environment in thirty days while the outgoing provider has no commercial reason to be helpful. Sixty to ninety days is more realistic for anything substantial. Transition assistance should be defined — hours, scope, and whether it is included — rather than left to goodwill.

A provider who resists a clean exit clause is telling you how they intend to retain you. That is useful information, and it is cheaper to learn it now.

Reading the SLA honestly

The service level section usually contains impressive numbers. A few things to check.

What does uptime measure. If it measures the provider's monitoring infrastructure rather than your services, it is not a commitment about anything you care about. If it excludes maintenance windows, check who schedules them and how much notice you get.

Does the clock pause. Most SLAs pause when a ticket is waiting on the customer. Reasonable in principle; check who can set that state and whether you are notified when they do.

What happens on a miss. Service credits are the norm, usually a percentage of the monthly fee. They are rarely large enough to compensate for a serious outage, and that is broadly unavoidable — no provider can underwrite your business losses at these price points. The useful question is not the size of the credit but whether repeated misses give you a right to terminate without penalty. That is the clause with teeth.

What we would want you to ask us

If you are evaluating us, or anyone: ask for a redlined comparison against the last three agreements the provider signed. Ask what they most often get asked to change. Ask what clause they refuse to move on and why.

A provider who answers those questions directly is one who has thought about the document as a working agreement rather than as protection. That is the relationship you want — one where the contract sits in a drawer because both parties understood it, rather than being retrieved during an argument by whoever read it more recently.