MSP Scope of Work Template: 8 Parts for Clearer Projects
A proposal tells the client what they are buying. A scope of work tells everyone what happens when reality gets involved.
Most project margin does not disappear because a technician worked slowly. It disappears because the job was priced before anyone named the sites, systems, data, approvals, and cleanup that came with it.
Use this template after discovery, before the quote. It gives sales, delivery, and the client the same version of the job. It also gives you a clean place to put a request when it belongs outside the price.
If discovery still lives in call notes and old project folders, start with how to scope an MSP project. If the scope is already known, use the template below.
The eight-part SOW template
A usable SOW answers eight questions. Keep the sections in this order so the client can scan the work, the boundaries, and the approval path without hunting through legal language.
| Section | The question it answers |
|---|---|
| 1. Project summary | What are we doing, for whom, and why now? |
| 2. Deliverables | What exact work and outputs are included? |
| 3. Exclusions | What related work is not in this price? |
| 4. Client responsibilities | What access, decisions, contacts, and windows does the client own? |
| 5. Assumptions and dependencies | What has to be true for the plan and price to hold? |
| 6. Timeline and milestones | What happens when, and where do we stop to review? |
| 7. Acceptance criteria | What proves the work is complete, and who accepts it? |
| 8. Change order process | What happens when discovery or the client adds new work? |
Copy this before you price the job
Replace the brackets. Do not leave a section blank because the answer feels obvious. That is usually where the free work gets in.
Project summary
Client: [legal client name]
Project: [plain-language project name]
Business outcome: [what changes when the project is complete]
Project owner: [MSP owner]
Client approver: [name and role]
Deliverables
- [specific system, site, user group, or output]
- [specific system, site, user group, or output]
- [documentation, training, validation, or handoff included]
Exclusions
- [related work that is not included]
- [cleanup, remediation, or migration beyond the stated count]
- [ongoing support, licenses, hardware, or third-party fees not included]
Client responsibilities
- Provide [access, credentials, contacts, and approvals] by [date]
- Confirm [downtime or cutover window]
- Make [business owner or application owner] available for validation
Assumptions and dependencies
- This price assumes [asset count, environment condition, or source data]
- This work depends on [licenses, vendor access, procurement, or client action]
- A change to [condition] may affect schedule or price
Timeline and milestones
- Discovery confirmed: [date]
- Implementation window: [date or range]
- Validation review: [date]
- Handoff: [date]
Acceptance criteria
- [test or result] is complete
- [documentation or deliverable] is delivered
- [named approver] accepts the work in writing
Change order process
Work outside this SOW requires a written change order that states the added work,
schedule impact, price impact, and approver before that work starts.
Fill each section with something a technician can use
1. Project summary
Name the client, the project, the business reason, and the two people who can make decisions. "Microsoft 365 migration" is a category. "Move 84 named mailboxes from Tenant A to Tenant B, preserve the stated shared-mailbox data, and cut over after the Friday accounting close" is a project.
This section stops sales from promising an outcome that delivery interprets as a different job.
2. Deliverables
Write deliverables as observable work and outputs. List quantities where they matter. Name the sites, systems, user groups, hardware models, or application owners that define the effort.
Weak: "Improve network performance."
Useful: "Replace four access switches at the Raleigh office, apply the approved VLAN plan, test wireless in the conference rooms, and deliver the updated network diagram."
A deliverable can include documentation, training, or a handoff. If it matters at the end of the project, put it in the scope rather than hoping someone remembers it during closeout.
3. Exclusions
An exclusion is not rude. It is a boundary the client can see before they approve the price.
List related work that people often assume comes with the project: after-hours work beyond the named window, unsupported applications, endpoint cleanup, new cabling, data repair, vendor coordination, licensing, hardware, or ongoing support after the agreed handoff. If the client later wants one of those items, you have a clean conversation instead of an argument about what was "obviously included."
4. Client responsibilities
Projects stall when the client has not named an approver, made an application owner available, or confirmed a downtime window. Those are not delivery failures. They are dependencies.
State who provides access, who approves the plan, who confirms the cutover window, and who validates the outcome. Add dates where an unanswered request can move the schedule.
5. Assumptions and dependencies
Assumptions are the facts you used to build the price. Dependencies are the things other people or systems must provide before you can proceed.
For a firewall replacement, that can mean current WAN handoff details, a complete tunnel inventory, valid vendor support access, and a client-approved maintenance window. For a Microsoft 365 migration, it can mean named source and target tenants, known mailbox counts, working admin access, available licenses, and a business owner to validate mail flow.
Do not hide thin assumptions in a spreadsheet. Put them in the signed scope. When one proves wrong, the change-order section tells everyone what happens next.
6. Timeline and milestones
A timeline should show more than a start date and a hopeful finish date. Use milestones that create decision points: discovery confirmed, implementation scheduled, cutover complete, validation reviewed, and handoff accepted.
Tie dates that depend on the client to the client responsibility that unlocks them. That protects the schedule without pretending the MSP controls every input.
7. Acceptance criteria
"Project complete" is not a test.
Define what gets tested, what evidence or documentation gets delivered, and who can accept the work. For a server migration, that may include application-owner validation, successful backup confirmation, and an updated runbook. For a network refresh, it may include an agreed test plan, service validation at each named site, and the final diagram.
Acceptance criteria make closeout a real handoff instead of a vague feeling that the tickets have gone quiet.
After delivery, use the MSP project acceptance checklist to record actual test results, unresolved items, the client's response, and support ownership against those criteria.
8. Change order process
A change order is the normal response when the job changes. Use one when the client adds work, discovery exposes a material difference from the stated assumptions, the schedule changes in a way that adds labor, or another site or system enters the project.
The change order should state four things: the added work, why it is outside the signed scope, the schedule impact, and the price impact. Name the approver. Get the approval before the work starts.
Starting first and sorting out the price later teaches everyone that the SOW is optional. Do not build that habit into the account.
The detail changes by project. The structure does not.
For every project type, the eight sections stay put. The evidence inside them changes.
| Project | Detail worth naming before you quote |
|---|---|
| Network refresh | Device counts and models, sites, rack access, cutover and rollback, test locations |
| Microsoft 365 migration | Source and target tenants, mailbox and shared-mailbox counts, data limits, authentication, cutover, validation |
| Firewall replacement | WAN handoffs, public IP changes, tunnel inventory, remote-access rules, rollback criteria |
| Server migration | Source systems, application owners, backup proof, downtime tolerance, validation and handoff |
| Client onboarding | Discovery tasks, baseline work, tool deployment, endpoint coverage, remediation held for a separate project |
The template is reusable. The assumptions are not. Copying last quarter's SOW without checking the current environment is how an old client project becomes a new margin problem.
For the Microsoft 365 row, the tenant-to-tenant migration scope template turns those details into a copy-ready scope.
Keep the MSA and SOW separate
The MSA sets the relationship-level terms. The SOW defines this job: the work, boundaries, responsibilities, timeline, and acceptance path.
Your counsel should own the legal language and the contract terms that apply to your business. Keep the practical distinction clean: do not keep editing the MSA every time the client wants a different project. Use a new SOW or a change order so the delivery team has a current definition of the work.
Turn a signed SOW into a better quote
Once the scope is stable, pricing gets more honest:
- Turn each deliverable into a work package or line item.
- Add labor where the scope actually requires it.
- Price the risk created by thin assumptions rather than pretending it is free.
- Offer excluded work separately when the client asks for it.
- Carry the acceptance criteria into the delivery plan.
Scopable helps MSPs turn findings, client context, and recommendations into a reviewable scope before the quote gets built. See the assessment and scoping workflow. When the scope is approved, see how it carries into quoting.
After signature, the SOW is the first document in the new client onboarding checklist. Read the exclusions out loud in the sales handoff before anyone talks to the client.
Turn this SOW into scoped work
Scopable carries client context through scope, products, and quote review. Start for free with no credit card.
Frequently Asked Questions
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.
