What's the difference between a deliverable and an outcome in an SOW?

An outcome describes the client's end state ("email works in Microsoft 365"). A deliverable is a countable, bounded unit you can check off ("migrate up to 25 mailboxes under 50GB each from a single source tenant"). Outcomes invite interpretation; bounded deliverables give you a number to point at when extra requests show up.

How do I bring up a change order without damaging the client relationship?

Tie the change order to the specific numbers already in the SOW. When the request exceeds "up to 25 mailboxes" or hits a named exclusion, you're not making a judgment call, you're applying language the client already agreed to. The number does the confronting, so the conversation stays mechanical instead of personal.

Should exclusions or inclusions get more attention in an SOW?

Exclusions usually catch more creep. Inclusions tell the client what they're buying; exclusions stop the "I assumed that was part of it" requests. Name specific systems and volume limits where you can, and write them in plain language the client can understand without a lawyer.

Is this legal advice I can rely on for my contracts?

No. This is general operational guidance from one MSP operator to another, not legal advice. Have your own attorney review your SOW template and any clause language before you use it.

Scope Creep in SOWs: How to Write Deliverables That Actually Hold the Line

Scope creep almost always starts in the deliverables section of your SOW, and the fix is to write deliverables as countable, bounded units with an explicit exclusions list and a change-order trigger. A deliverable that says "migrate email to Microsoft 365" will cost you unpaid hours. One that says "migrate up to 25 mailboxes, each under 50GB, from a single source tenant" gives you a line to point at when the client shows up with 40 mailboxes and a shared archive.

That's the whole game. Vague deliverables are free options you hand the client. Specific deliverables are where you draw the line before the work starts, when nobody's annoyed yet.

A quick note before we go further: this is general information, not legal advice. I'm an operations person writing for other operations people. Have your own attorney review your SOW template and any language you borrow from this post.

Why "scope creep" is really a drafting problem

When an MSP owner tells me a project went sideways on scope, they usually describe it as a client problem. The client kept asking for more. The client "didn't understand what was included."

Nine times out of ten it's a drafting problem. The SOW named an outcome instead of a bounded unit of work, so there was no number to compare the extra request against. If the document says "set up the new firewall," and the client has three sites, who's right about whether that means three firewalls? Nobody, because the document didn't say.

The client isn't creeping. They're reading an ambiguous document in their own favor, which is what everyone does.

Write deliverables as bounded units, not outcomes

An outcome is "the client's email works in Microsoft 365." A bounded unit is a thing you can count and check off. Rewrite every deliverable so it has at least three attributes: a quantity, a boundary, and a done condition.

Here's the pattern:

Quantity: how many. "Up to 25 mailboxes." "Two firewalls." "One site."
Boundary: the edge of the unit. "Under 50GB each." "Single source tenant." "Excluding public folders."
Done condition: how we both know it's finished. "Client signs off that test user can send and receive." "Firewall passes the agreed port-scan checklist."

Compare these two:

Deliverable: Migrate email to Microsoft 365.

Deliverable: Migrate up to 25 user mailboxes (each under 50GB) from a single source Exchange environment to Microsoft 365. Shared mailboxes, public folders, and third-party archives are out of scope (see Exclusions). Complete when the client confirms a test user can send and receive, and all in-scope mailboxes show "synced" in the migration tool.

The second one is longer. It's also the version you can enforce. When mailbox 26 shows up, or someone mentions the 80GB archive, you have a number and a named exclusion to point at.

The exclusions list does more work than the inclusions list

Most SOWs spend all their energy describing what's included and skip what's excluded. Flip that habit. An exclusions list is where you catch the "I assumed that was part of it" requests before they happen.

For a typical MSP project, I'd want exclusions covering:

Work at additional sites or locations not named in the SOW
Data over the stated volume (mailbox size, device count, GB of file data)
Legacy or unsupported systems (name them if you know them: "Server 2008 R2," "the on-prem fax server")
Third-party vendor coordination and their fees
After-hours or weekend work unless scheduled in writing
End-user training beyond the stated hours
Rework caused by client changes after sign-off

Plain language works better than legalese here. "Migrating data from any source not listed above is not included in this project and will be quoted separately." A client can't claim surprise about something that's spelled out in a bullet they initialed.

Give the change order a trigger, not just a process

Almost every SOW has a change-order clause buried in the boilerplate. Almost none of them say when it fires. So the process exists on paper and never gets used, because invoking it feels like a confrontation.

Tie the change order to the specific numbers in your deliverables. That makes it mechanical instead of personal.

Change orders: Work beyond the quantities or boundaries stated in Section [Deliverables], including any item listed in Section [Exclusions], requires a written change order signed by both parties before work begins. Change-order work is billed at $[185]/hour unless otherwise quoted. No change-order work is performed on a verbal request.

Now when mailbox 26 appears, you're not arguing about whether it's "extra." You're pointing at "up to 25" and sending a one-paragraph change order for the rest. The number does the confronting for you.

One more piece that saves real money: say that undisputed work pauses if a change order sits unsigned. Something like "If a required change order is not signed within 5 business days, the affected work is placed on hold and the project timeline extends accordingly." Otherwise clients learn they can keep you working while they "think about" the change order.

Assumptions are scope clauses in disguise

Every project rests on things you're assuming are true. The client will provide admin credentials. The environment matches what you saw in discovery. There's one domain controller, not four. When an assumption turns out false, your effort balloons, and without a clause you eat it.

Write an assumptions section and connect it to the change order:

This SOW is based on the assumptions below. If any assumption proves incorrect, the resulting additional work is handled through the change-order process.

Client provides Global Admin credentials within 2 business days of kickoff.

The environment consists of a single Active Directory domain with one domain controller.

All workstations run Windows 10 (22H2) or Windows 11 and are domain-joined.

Internet circuit delivers at least 100 Mbps upload at the primary site.

The assumption about credentials is the one I'd never skip. Half of project delays trace back to waiting on access, and if you don't name it, the stalled clock becomes your problem instead of theirs.

How do I write deliverables that actually prevent scope creep?

Short version, the thing you'd put on a sticky note:

Rewrite every deliverable with a quantity, a boundary, and a done condition.
Build an exclusions list in plain language, and name specific systems where you can.
Add a change-order clause that triggers on the exact numbers in your deliverables, with an hourly rate and a "written and signed before work" rule.
Add an assumptions section, especially around access and environment, and route broken assumptions to the change order.
Put a sign-off checkpoint on each major deliverable so "done" is a date, not an opinion.

Do those five and most creep either disappears or converts into billable change orders. Both outcomes beat the status quo.

The sign-off checkpoint most SOWs forget

A deliverable without a sign-off never really closes. The client keeps "noticing" things weeks later and treats them as warranty on an open project. Attach an acceptance step to each major deliverable:

Client has 5 business days after a deliverable is submitted to report defects in writing. Absent a written report in that window, the deliverable is accepted and considered complete. Issues reported after acceptance are handled as new work.

This isn't about being rigid. It's about having a clean line between "finishing the project we agreed to" and "starting a new conversation." Without that line, the project never ends, and the margin you quoted keeps leaking.

Make it a template, not a per-deal rewrite

None of this works if you rebuild it from scratch on every deal. The deliverable pattern, the exclusions list, the change-order trigger, the assumptions, and the acceptance clause should live in a reusable SOW template. Your project team fills in the numbers, not the legal structure. That way the enforceable language ships on every engagement, even the small ones that "didn't seem worth a full SOW," which are exactly the ones that creep.

Keep a short library of exclusions and assumptions by project type (email migration, firewall refresh, server upgrade) so the right boundaries are one click away. The goal is that writing a tight SOW takes ten extra minutes, not an hour.

Scope creep isn't a client character flaw. It's the natural result of a document that left room for interpretation. Close the room, and most of the problem closes with it.