MSP Statement of Work Template: What a Managed Services SOW Needs (and What Gets MSPs Sued)

Every MSP has a story about the client who assumed the monthly fee covered the new office build-out, the server that was never on the contract, or the "quick question" that became forty hours of project work. Almost every one of those stories starts with a statement of work that did not say.

The SOW is not the legal document — that is the master services agreement, and your lawyer should own it. The SOW is the operational one: what you will do, what you will not, what the client has to do, and what it costs. It is the document the client actually reads, and it is the one you will be pointing at in eleven months.

This is a template, section by section, with notes on what each section is for. Copy the structure; write the content for your stack.

The Structure

A managed services SOW that holds up has nine parts, in this order:

1. Parties, date, and reference to the MSA
2. Environment summary
3. Services in scope
4. Exclusions
5. Service levels and support hours
6. Client responsibilities
7. Onboarding and transition
8. Pricing, billing, and adjustments
9. Term, changes, and termination

Everything below maps to one of those.

1. Parties and Reference

One paragraph. Client legal name, your legal name, effective date, and a sentence stating that the SOW is governed by the MSA dated whenever. If you do not have a signed MSA, stop and fix that first; an SOW without one is a proposal with a signature line.

2. Environment Summary

The section most MSPs skip, and the one that ends the most arguments.

State what you are taking on: number of users, number of workstations, servers by name and role, network sites, Microsoft 365 tenant, line-of-business applications you will support and those you will not. Count it during discovery and write it down.

This section is the baseline for the price. When the client adds twelve users and a second server eight months in, the SOW says what was covered and the pricing section says what changes.

Template language: "Services are priced for the environment described in Schedule A: 22 users, 28 managed workstations, 2 managed servers, 3 network sites. Changes to the environment are handled under Section 8."

3. Services in Scope

Be specific, and be boring. "Managed IT services" is not a scope. A list is.

For each service, one line stating what it is and how often it happens:

• Workstation management — monitoring, OS and third-party patching (monthly, critical patches within 72 hours), remote support.
• Endpoint protection — managed detection and response on all managed devices, with isolation and remediation of detected threats.
• Server management — monitoring, patching within the maintenance window, monthly health review.
• Backup — image-based backup of the servers listed in Schedule A, local and cloud copies, daily, with a quarterly restore test.
• Microsoft 365 — tenant administration, user lifecycle (add, change, remove), licence management, security baseline.
• Network — management of the firewalls and access points in Schedule A: firmware, configuration, policy changes.
• Help desk — unlimited remote support for covered users during support hours, defined in Section 5.
• Vendor management — acting as the client's technical contact with their ISP, printer vendor, line-of-business software vendors.
• Reporting and review — a monthly report and a quarterly business review.

If you offer tiers, the SOW lists the services in the tier the client bought, not all of them.

4. Exclusions

The section that pays for itself. Everything a reasonable client might assume is included and is not:

• Projects: migrations, office moves, new-site build-outs, server replacements — quoted separately.
• Hardware and software purchases, and any licensing not listed in Section 3.
• On-site visits beyond the included allowance (state the allowance).
• Devices not in Schedule A, personal devices, devices running unsupported operating systems.
• Support for applications not listed, beyond "best efforts" to get the vendor engaged.
• Data recovery for systems not covered by the backup service.
• Work caused by the client bypassing security controls you recommended in writing.
• Anything outside support hours unless the client has purchased after-hours coverage.

Phrase them plainly. A client who reads "new office build-outs are quoted separately" in month one does not send an angry email in month nine.

5. Service Levels and Support Hours

State the support hours (e.g. 7:30–18:00 local, business days), then a response-and-resolution table by priority. Keep it to three or four rows and make the targets ones you actually hit:

Two things every SLA section needs and most lack:

What "response" means. A human acknowledging the ticket and starting work — not an auto-reply.

What happens when you miss. Credits, if you offer them, are a percentage of that month's fee, capped, and claimed by the client in writing within 30 days. If you do not offer credits, say the targets are goals and the remedy is escalation. Either is fine; silence is not.

6. Client Responsibilities

The section clients most often ignore and the one you most need when things go wrong:

• Provide a primary point of contact with authority to approve changes and spend.
• Maintain internet connectivity and power at each site sufficient for the services.
• Keep hardware within the supported lifecycle (state it: e.g. workstations under 5 years, no end-of-life operating systems).
• Notify you of new users, departing users, and new devices within an agreed period.
• Follow the security controls in place — MFA, password policy, no local admin — and accept that work caused by bypassing them is billable.
• Provide access: physical, administrative credentials, vendor logins.

7. Onboarding and Transition

What happens in the first 30–60 days, and what it costs. Onboarding is a project and should be priced like one — a one-time fee covering agent deployment, tenant hardening, documentation, and the first backup and restore test.

State the phases with rough weeks, and state that the monthly fee begins on the effective date, not at the end of onboarding. Then say what happens at the other end: on termination, you provide administrative credentials, documentation, and a data export within a stated period, and offboarding assistance beyond that is billable.

8. Pricing, Billing, and Adjustments

The numbers, split the way the client thinks about them:

Recurring. Per-user rate, per-device rate for servers and network hardware, any add-on services, and the monthly total for the environment in Schedule A. Billed monthly in advance.

One-time. Onboarding fee, any hardware or project work in this SOW, deposit terms.

Adjustments. How the recurring total changes when the environment does: added users and devices billed pro-rata from the month they are added, at the rates above; a true-up at each quarterly review. And an annual price adjustment clause — a stated percentage or an index — so you are not negotiating from scratch every renewal.

If you got the arithmetic right upstream, this section writes itself. Our guide to pricing managed services covers finding the cost floor those rates need to clear.

9. Term, Changes, and Termination

Initial term (twelve months is standard), renewal (automatic, annual), notice period for non-renewal (60–90 days), and termination for cause with a cure period.

Then a change-control sentence: material changes to scope are made by a written amendment or a new SOW, signed by both parties. This is the sentence that turns "can you just also…" into a quote.

What Gets MSPs in Trouble

Having reviewed a lot of these, the failures cluster:

Scope by implication. The SOW lists services in general terms and the client fills in the gaps in their favour. Specific services, explicit exclusions.

An SLA you cannot meet. Fifteen-minute response, 24/7, written to win the deal. It is a liability from the day it is signed. Write the SLA you hit on a bad day.

No environment baseline. Price based on 20 users, environment grows to 35, nobody notices until the renewal argument.

Client responsibilities missing. When the client refuses MFA and gets phished, the SOW should already say whose problem the cleanup is.

Copy-paste drift. The SOW for the new client was made from the last one, and the last one had a clause specific to a different environment. Every SOW gets a read-through, or gets generated from the deal and quote rather than from a document.

Generating It Instead of Writing It

The reason SOWs drift is that they are written by hand from a copy of the previous one, while the real details — environment, services, pricing — live somewhere else. NeroEngine generates the proposal package, including the SOW, from the deal and the quote: the environment section comes from the discovery data on the deal, the services and pricing sections from the quote's line items, and your MSA language from your own template. It is still yours to review, but the numbers in the SOW are the numbers in the quote by construction, and the structure above is the structure it produces.

Common Questions

Is an SOW the same as a contract? No. The MSA is the contract — liability, confidentiality, governing law, payment terms. The SOW sits under it and describes the specific engagement. One MSA, then an SOW per engagement or per major change.

How long should an MSP SOW be? Four to eight pages. Shorter and it is not specific enough; longer and the client will not read it, which defeats the purpose.

Should the SOW include the price? Yes. Some MSPs separate a "service description" from a "pricing schedule", which is fine as long as both are signed. A scope with no price, or a price with no scope, is where disputes start.

Do I need a lawyer for the SOW? For the MSA, yes. For the SOW, a lawyer should review your template once; after that it is an operational document you should be able to produce from the deal without legal involvement each time.

For the document that wraps the SOW — the proposal itself — see how to win more MSP proposals. For where the SOW sits in the sales motion, the MSP sales process guide covers proposal to signature.