A Statement of Work Template for Small MSP Projects

Scope: Describe the Result and the Work Included

Write the result the client will receive, then identify the work your team will perform to produce it. Name the affected environment so included work doesn't expand merely because the client has another site or system. Keep a scope reference and version on the document.

Project and version: [reference]. Client and delivery owner: [names]. Intended result: [observable outcome]. Included environment: [named systems or locations]. Deliverables and included work: [the specific work and records the MSP will provide].

For a hypothetical firewall replacement, identify the device and location covered, along with the agreed configuration work and handover records. Decide whether the work includes migration of existing settings or redesign. Those promises require different preparation even when the equipment line is identical.

'As discussed' is an optimistic place to store a scope. Put the decision in the document the engineer will receive. A meeting note can support it, but shouldn't be the only place the boundary exists.

Exclusions: State Where This Project Stops

List the adjacent work the client might reasonably think is included but your team hasn't priced. Keep exclusions specific enough to discuss. An undefined exclusion for everything else won't resolve a disagreement about what the proposed deliverable requires.

This project excludes [named adjacent work]. Work already covered by [the applicable support agreement] follows that service process. A requested change to this project goes to [role] for scope, price, and scheduling review before approval.

For the firewall example, decide whether other sites and application remediation are included. Don't copy an exclusion for either if delivery actually needs that work to produce the promised result. Resolve the contradiction before asking the client to sign.

Keep the change process here as a reference, with the detailed procedure in your project controls. The SOW establishes the baseline. A later change order records how that accepted baseline changes.

Assumptions: Name the Conditions Behind the Estimate

Write what must be true for the proposed plan and price to work. Give each client or supplier dependency an owner. Check what can be verified before the offer goes out rather than using assumptions to avoid ordinary discovery.

This plan assumes [specific verified or outstanding condition]. [Name or role] supplies [required access, information, or approval] before [the dependent milestone]. If the condition changes or cannot be confirmed, [project owner] reviews the impact with the client before affected work proceeds.

Andrew Herbert recommends checking integration connectivity, data availability, and provider cooperation during readiness discussions. He recalls a project delayed while credentials were awaited. That is his practitioner account, and it illustrates why a required dependency belongs in the plan before the start date becomes a promise.

Record the impact of a changed assumption when it occurs. It may require a new plan or a discussion about price, but the effect depends on the agreed terms and the facts. An assumption written into your template doesn't automatically make every overrun billable.

Dates: Separate Effort From the Delivery Window

Show the planned start and completion milestones with the conditions they depend on. Distinguish estimated work hours from elapsed time. A technician can need a limited amount of hands-on work while the project still depends on a client's availability or a supplier delivery.

Planned start: [date and readiness conditions]. Milestones and completion target: [dates and outcomes]. Approved service interruption or change window: [agreed window, if required]. Client and supplier dependencies: [owner and required date]. Scheduling changes are coordinated by [role].

Mike Psenka recommends recording task dependencies and elapsed duration alongside work-hour estimates and assigned resources. That is his vendor planning advice. Use the distinction to keep a labor estimate from becoming an unsupported calendar commitment.

Have the scheduler confirm capacity before the sales team promises the dates. Brendan Rose recommends considering sold project work alongside prospective work and the team's delivery rate when discussing timing. His approach is a planning method, not evidence that a particular date is available in your MSP.

Price: State What Will Be Billed and When

State the project price and its billing basis. If it is fixed price, identify the agreed deliverables that price covers. If it is time and materials, explain the applicable rates and how the client authorizes the work rather than presenting an estimate as a fixed total.

Pricing basis: [fixed price or agreed time-and-materials terms]. Project service price or estimate: [amount and basis]. Equipment and licenses: [included items and price, or separate approved purchase]. Invoice events and payment terms: [the agreed terms]. Authorized client approver: [name or role].

Use the model's $185 blended project rate as the planning input where appropriate, not proof of the cost of every assigned engineer. At the model's 50% project gross-margin target, its labor allowance is $185 multiplied by 0.50, or $92.50 per billed hour. Compare the actual delivery plan and costs with the quote; the rate alone can't establish the job's margin.

Give billing the approved SOW and the invoice events. Don't let the engineer's task description become a different commercial promise. Keep equipment and licensing charges clear so the client can identify what the service price includes.

Acceptance: Agree How the Client Will Verify Completion

Name the person who can accept the completed work and the checks that support that decision. Use observable results tied to the deliverables. The engineer finishing their task list doesn't itself establish that the client has accepted the outcome.

Acceptance criteria: [specific checks linked to the deliverables]. Client verifier and authorized sign-off: [names or roles]. Completion evidence: [test results and handover records]. Open-item process: [how remaining items are recorded, assigned, and resolved]. Completion acceptance: [dated approval against this project version].

For the hypothetical firewall project, agree which connectivity and business-service checks the client needs, who performs them, and what evidence they receive. Have the technical lead prepare the actual test plan. Don't invent a passing criterion after the client reports that an important service still fails.

Don't call this delivery enablement. Say who checks the work and who signs it off. Use the following ownership check before the SOW goes to the client.

• The technical lead checks whether the deliverables, assumptions, and acceptance criteria describe work the team can perform.
• The project lead checks dependencies and keeps the approved scope version with the project tasks.
• The scheduler checks the people and delivery window before dates become commitments.
• The finance owner checks the pricing basis and invoice events against what billing will receive.
• The account owner confirms the client's authorized scope approver and completion verifier.

At completion, compare the estimate with actual task effort and record why it changed. Psenka recommends using that comparison to revise future service templates rather than repeatedly quoting the same unsupported estimate. That is his estimating advice; your own records should establish which change is justified.

Take the next small project through these sections before scheduling it. Resolve the unanswered field with its owner, obtain approval for the same version delivery and billing will use, and carry the agreed acceptance checks into the project plan.