What should an MSP scope of work include?

A strong MSP scope of work should include the project summary, deliverables, exclusions, client responsibilities, assumptions, dependencies, timeline, acceptance criteria, and change order process. If any of those are missing, the job is too vague to price cleanly.

What is the difference between an SOW and an MSA?

The MSA sets the legal rules for the relationship. The SOW defines the specific project, including what work is included, what is excluded, and how the work gets accepted.

When should an MSP use a change order?

Use a change order when the client adds work outside the signed scope, when discovery reveals a new dependency, or when the environment is materially different from the assumptions in the SOW. Do not absorb the extra work for free.

How do MSPs prevent scope creep in a project?

Write the exclusions, assumptions, client responsibilities, and acceptance criteria into the SOW before the quote goes out. If a request falls outside those lines, treat it as a change order instead of an informal favor.

Can I use the same SOW for recurring project work?

You can reuse the structure, but not the assumptions. Update the asset counts, timeline, exclusions, and acceptance criteria for each engagement so the SOW matches the actual project.

MSP Scope of Work Template: An 8-Part SOW That Stops Scope Creep

Most MSP project problems start before anyone signs anything.

The scope gets described in call notes, the quote inherits the guesswork, and delivery is left to absorb the surprise work. That is how margin disappears. It is also how good clients start to feel like bad clients.

If you still need the discovery workflow that sits upstream of the SOW, start with How to Scope an MSP Project (Without Guessing). Once that process tells you what belongs in the job, this template turns it into a document the client can actually sign.

The Short Answer

A solid MSP scope of work should do eight things:

State the project goal in plain language.
List the deliverables the client is buying.
List the work that is out of scope.
Spell out client responsibilities and required access.
Capture assumptions and dependencies.
Define the timeline and milestones.
Set acceptance criteria and done-state.
Explain how change orders work when the job changes.

If the SOW does not answer those eight points, it is not specific enough to price confidently.

The 8-Part MSP SOW Template

Use this as the base structure for almost every project SOW.

Section	What it must say
Project summary	Why the project exists, who it is for, and what success looks like.
In-scope deliverables	The exact work the MSP will perform and the outputs the client receives.
Out-of-scope work	Anything the quote does not include, even if it is related.
Client responsibilities	Access, approvals, contacts, downtime windows, and any prep the client owns.
Assumptions and dependencies	Conditions that must be true for the plan and price to hold.
Timeline and milestones	Key dates, cutover windows, review points, and delivery checkpoints.
Acceptance criteria	What proves the project is complete and who signs off.
Change order process	How new work gets priced, approved, and scheduled.

That list looks simple on purpose. A SOW should be easy to skim and hard to misread.

Copyable MSP SOW Skeleton

Use a fixed template so every project starts from the same baseline.

Project Summary
- Client:
- Project name:
- Business goal:
- Target start date:
- Target completion date:

In Scope
- Deliverable 1:
- Deliverable 2:
- Deliverable 3:

Out of Scope
- Work not included:
- Work requiring a separate project:
- Ongoing support not covered by this SOW:

Client Responsibilities
- Required access:
- Required approvers:
- Required downtime window:
- Required onsite escort or contacts:

Assumptions and Dependencies
- Environment assumptions:
- Third-party dependencies:
- Licensing or procurement assumptions:
- Items that could change the schedule:

Timeline and Milestones
- Discovery complete:
- Implementation window:
- Validation checkpoint:
- Final handoff:

Acceptance Criteria
- What must be tested:
- What documentation must be delivered:
- Who signs off:

Change Order Process
- Any work outside this scope requires written approval before it starts.

That skeleton is not just paperwork. It is the line between a priced project and a support ticket that wandered into billing.

What Each Section Prevents

The reason this template works is that each section blocks a specific failure mode.

The project summary keeps sales, engineering, and the client pointed at the same outcome.
In-scope deliverables stop the quote from drifting into vague promises.
Out-of-scope work prevents "we thought that was included" arguments.
Client responsibilities remove delays caused by missing access or missing decisions.
Assumptions and dependencies expose the hidden stuff that usually blows up the schedule.
Timeline and milestones keep the project from becoming one giant amorphous task.
Acceptance criteria remove the fake finish line where everybody assumes the work is done.
Change order process keeps new work from quietly eating margin.

If one of those sections is missing, scope creep usually finds the gap for you.

What Changes by Project Type

The template stays the same, but the detail changes.

Network refresh

For a network refresh, the SOW should include:

Exact device counts
Hardware models being replaced
Rack access and after-hours windows
Cutover and rollback steps
Testing requirements for each site

The common trap is calling the whole job "replace the switches." That is not a scope. That is a wish.

Microsoft 365 tenant migration

For a tenant migration, the SOW should specify:

Mailbox count and shared mailbox count
Identity source and authentication method
Data migration limits
Cutover window and user communication plan
Validation checklist for mail flow, OneDrive, Teams, and shared resources

If the source and target tenants are not clearly defined, the project can balloon fast.

Firewall replacement

For a firewall replacement, the SOW should cover:

WAN handoff details
VPN tunnels and remote access rules
Public IP changes
Policy migration scope
Cutover testing and rollback criteria

Firewall swaps fail when the SOW assumes the environment is simple. It never is.

Server migration

For a server migration, the SOW should document:

Physical or virtual source systems
Application owners and dependencies
Backup validation before cutover
Downtime tolerance
Post-migration validation and handoff

If the app owner is not named, the project will stall when the first compatibility question lands.

Onboarding project

For an onboarding project, the SOW should define:

Discovery tasks versus remediation tasks
Tools being deployed
Endpoint coverage
Security baseline work
What is excluded until a separate project is approved

This is where many MSPs accidentally promise a full cleanup while pricing only the onboarding phase.

SOW vs MSA

The MSA and the SOW are not the same document.

The MSA sets the legal rules for the relationship.
The SOW defines one specific project.

If the client wants different work, write a new SOW or a change order. Do not keep editing the MSA every time the job changes. That creates legal noise and operational confusion.

Think of it this way: the MSA tells you how the relationship works. The SOW tells you what this job includes.

When to Use a Change Order

Use a change order when any of these happen:

The client adds work that was not in the signed scope.
Discovery reveals a dependency that was not visible during scoping.
The environment is materially different from the assumptions in the SOW.
The client changes the target date and that change adds labor.
The job expands into another site, another system, or another security requirement.

The change order should include:

What changed
Why the change matters
The schedule impact
The price impact
Who approved it

If the extra work starts before approval, you have already taught the client that the scope is optional.

How the SOW Turns Into a Quote

This is the part most teams get backward.

The SOW is not the final sale document. It is the working definition of the job. Once the SOW is tight, the quote becomes much easier:

Convert each deliverable into a line item or work package.
Attach labor hours to each deliverable.
Add risk where the assumptions are thin.
Price exclusions separately if the client wants them later.
Make the acceptance criteria part of the delivery plan.

That is why this article pairs with How to Scope an MSP Project (Without Guessing) and The MSP Proposal Template That Actually Wins Deals. The first gets you to a real scope. The second packages that scope for the buyer.

If your team still builds quotes from memory, old Word docs, and a lucky guess, join Scopable early access. The goal is not more paperwork. The goal is fewer surprises.

Common SOW Mistakes

Mistake 1: Writing goals instead of deliverables

"Improve the network" is not a deliverable. "Replace four access switches and validate wireless coverage in all conference rooms" is.

Mistake 2: Leaving exclusions vague

If the document does not say what is excluded, the client will assume it is included.

Mistake 3: Reusing the same SOW with no edits

The structure can be reused. The assumptions cannot. Every environment has its own risk profile.

Mistake 4: Hiding change order language in legal boilerplate

If change orders are hard to find, people forget to use them.

Mistake 5: Pricing the project before the scope is stable

That is how a simple job turns into unpaid consulting.

Final Take

A good MSP SOW does one job: it makes the quote defensible.

It tells the client what they are buying, tells your team what they are responsible for, and gives everyone a clean way to handle surprises without turning every surprise into margin loss.

If your process still starts with a rough number and a hopeful conversation, fix the scope first. The quote gets better when the input gets better.