What's the difference between an SOW and an MSA?

The master services agreement holds your legal terms like liability, termination, and payment terms and usually doesn't change often. The statement of work describes the specific scope, deliverables, and price for a given engagement. You typically have one MSA and many SOWs under it. Have a lawyer confirm the two documents reference each other correctly.

How do I handle a client who keeps asking for out-of-scope work?

Point to your exclusions list and change control clause. Respond with a quote for the extra work instead of a yes or no. If the SOW says out-of-scope work needs an approved change order before it starts, the request becomes a normal pricing conversation rather than a favor you feel pressured to give away.

Does a change order have to be a formal signed document?

That depends on what your contract says and on your state's law. Many MSPs write their SOW so an email approval counts as a valid change order, which keeps things fast. Confirm what qualifies as binding written approval in your situation with your own attorney before relying on email.

How specific should the scope section be?

Specific enough that someone who wasn't in the sales call could read it and know exactly what you agreed to do. Name asset counts, sites, tenants, and the actions you'll perform. Avoid catch-all words like manage, maintain, and support without defining what they cover.

How to write an SOW that actually stops scope creep

Every MSP owner I talk to has the same story. A client asks for "one quick thing," the tech says yes, and three months later that quick thing has turned into a standing weekly ask that nobody bills for. Multiply that across ten clients and you've got a full engineer's worth of free labor walking out the door.

Scope creep gets blamed on pushy clients. Most of the time the real culprit is a vague statement of work. If the SOW doesn't say what's in and what's out, your team has no ground to stand on when someone asks for more. This post walks through how to write an SOW that holds up, with the specific language and structure that keeps the line where you drew it.

This is general information, not legal advice. Run your actual contract language past a lawyer who knows your state and your business before you rely on it.

Why vague scope costs you real money

Here's the math that should keep you up at night. Say your blended cost for an engineer is $65 an hour. A client asks for a "small" project migration that your SOW didn't cover. Your tech spends 20 hours on it because saying no felt awkward. That's $1,300 gone, and you never sent an invoice. Do that twice a month and you've burned over $31,000 a year in labor you gave away.

The problem compounds. Once you do free work once, the client expects it again. Now it's not a favor, it's the baseline. Your margin on that account quietly drops from 40% to 22% and you can't figure out why the numbers look off at year end.

A tight SOW doesn't make you rigid. It makes the conversation about extra work a normal business conversation instead of an argument.

Start with a scope statement that a stranger could read

The single most useful test for an SOW section: hand it to someone who wasn't in the sales call and ask them what you agreed to do. If they can answer clearly, you're in good shape. If they shrug, you've got a gap.

Bad scope language reads like a mission statement:

"Provider will manage and maintain Client's IT environment and provide ongoing support."

That sentence covers everything and nothing. "Manage," "maintain," and "support" all mean whatever the client wants them to mean at 4:45 on a Friday.

Good scope language reads like an inventory. Name the assets, the counts, the locations, and the actions:

"Provider will monitor and patch up to 45 Windows workstations and 6 Windows servers across 2 physical sites. Provider will manage one Microsoft 365 tenant covering up to 50 licensed users. Provider will maintain and monitor two firewalls (Site A, Site B)."

Now everyone knows what "the environment" means. When the client opens a third site or adds 30 users, the SOW makes it obvious that you're outside the original deal.

The exclusions list is where the real protection lives

Most SOWs spend all their energy describing what you'll do and say nothing about what you won't. That's backwards. Your in-scope list can never be complete, but a short exclusions list catches the requests that eat your week.

Write down the things clients most commonly assume are included but aren't. For a typical MSP that list looks something like this:

Project work: server migrations, cloud migrations, office moves, new site standups
After-hours or weekend work outside the agreed support window
End-user training and one-on-one "how do I" walkthroughs beyond basic support
Application support for third-party software you don't manage (their line-of-business app, their accounting package)
Hardware and software costs, licensing, and vendor fees
Cabling, physical installs, and anything that requires being onsite unless stated
Data recovery beyond the backup retention you agreed to
Cybersecurity incident response and forensics (this one deserves its own SOW or retainer)

The point isn't to refuse this work. The point is to make clear that it's a separate line item with its own price. When a client asks for a migration, you point at the exclusions list and say, "Happy to do it, here's a quote." No friction, no free work.

Define the response, not just the promise

Scope isn't only about what tasks you do. It's about how much of them and how fast. An SOW that says "provider will respond to support requests" invites arguments about what "respond" means and how quickly.

Spell out the service levels in plain numbers:

Support hours: Monday to Friday, 8am to 6pm local time
Priority 1 (site down): response within 1 hour
Priority 2 (single user down): response within 4 business hours
Priority 3 (general request): response within 1 business day
Monthly included hours for ad-hoc requests: 10 hours, billed at $150/hour beyond that

That last line is the quiet workhorse. It tells the client that yes, you'll handle the small stuff, and there's a bucket for it, and the bucket has a bottom. When they blow past 10 hours in a month, the overage bills automatically and nobody has to have an uncomfortable talk.

Put the change control process in writing before you need it

Every SOW that survives contact with reality has a change control clause. This is the mechanism that turns "can you also do X" into a documented, priced decision instead of a favor.

Keep it simple:

"Any work outside the scope described in this SOW requires a written Change Order signed by both parties before work begins. A Change Order will describe the additional work, the cost, and any change to timeline. No out-of-scope work will be performed without an approved Change Order."

Two words in there do the heavy lifting: "before work begins." Without that, your tech does the work, then you try to bill for it after the fact, and now you're the bad guy asking for money for something that's already done. Get the approval first and the whole dynamic flips.

A Change Order doesn't need to be a formal contract every time. An email that says "here's the extra work, here's the price, reply to approve" is often enough, as long as your SOW says email counts. Confirm that with your lawyer, because what qualifies as a binding written approval varies by state.

Assumptions protect you when reality doesn't match the sales call

Your pricing was built on a set of assumptions about the client's environment. Write them down. If any of them turn out to be false, your scope and price get to change.

Useful assumptions to state:

The environment matches the counts and inventory listed in this SOW as of the start date
Existing systems are supported by their vendors and under current warranty or license
The client provides timely access, credentials, and a point of contact for approvals
Existing documentation is accurate, or the client will pay for discovery to build it

That last one saves you often. You quote a monthly rate assuming the network is documented. You show up and it's a mess with no map, undocumented static IPs, and a firewall someone configured in 2016 and lost the password to. The assumptions clause lets you say the discovery work is billable, because the SOW was priced on the assumption the documentation existed.

Tie the SOW to the master agreement, and keep them separate

Keep your legal terms (liability, termination, payment terms, confidentiality) in a master services agreement, and keep the SOW focused on scope, deliverables, and price. One MSA, many SOWs. When you win a new project with an existing client, you write a new SOW and don't reopen the whole legal negotiation.

Make sure each SOW references the MSA by name and date so it's clear which terms govern. And make sure the MSA says the SOW controls on scope while the MSA controls on legal terms, so there's no fight later about which document wins.

A quick checklist before you send

Before an SOW goes out the door, run it through this:

Could a stranger read the scope section and know what you agreed to do?
Is there an exclusions list naming the common "quick favor" requests?
Are response times and included hours stated as numbers?
Is there a change control clause that requires approval before work starts?
Are your pricing assumptions written down?
Does it reference the MSA and say which document controls?

Scope creep is expensive, quiet, and almost entirely preventable at the writing stage. Spend the extra hour on the SOW now and you save yourself the hundred small arguments later.