MSP Change Order Template: Approve Scope Before Work Starts

Get the scope change approved before your team starts the added work.

A client asks to include another office in the network refresh. The engineer says it looks straightforward. Your account manager says you'll sort out the paperwork later. Delivery now has a larger project and the original labor budget.

Use this MSP change order template when the job changes after approval. It gives the vCIO, delivery lead, sales admin, and client approver a shared record of what changed and what happens next. You can copy it into your current document workflow; no new software required.

Start by deciding whether the request actually changes the agreement. Your team taking longer than expected does not automatically create a billable client change.

Classify the work before you price it

Compare the request with the signed scope, exclusions, assumptions, and acceptance criteria. Bring the delivery lead into that check. A client asking for an included deliverable may be clarifying the agreement rather than expanding it.

Treat ambiguity as a review problem. If the SOW never made a boundary clear, saying "out of scope" louder will not resolve it.

ScopeStack's guidance on out-of-scope IT requests recommends discussing the request, documenting its budget and timeline effects, obtaining client approval, and updating the delivery plan. The form below adds an internal classification so an estimating mistake does not quietly become a client addition.

Copy this MSP change order template

Replace the brackets. Delete irrelevant fields deliberately rather than leaving a price or approval condition open to interpretation.

CHANGE ORDER

Client: [legal client name]
Project: [project name and PSA project reference]
Original agreement: [SOW title, version, approval date]
Change reference: [unique change ID and version]
Requested by: [name, role, request date]
MSP owner: [account manager or vCIO]
Delivery reviewer: [name]
Client approver: [authorized name and role]

Reason for the change
[What changed after the original approval?]
Classification: [changed assumption / client addition / separate initiative]
Original boundary: [exact SOW deliverable, exclusion, or assumption]
Evidence: [request, discovery finding, or confirmed environment change]

Revised work
Added: [named sites, systems, users, tasks, and deliverables]
Removed or replaced: [work this change supersedes, or none]
Unchanged: [original deliverables that remain in force]
Excluded: [related work not included in this change]

Dependencies and responsibilities
MSP provides: [work and evidence]
Client provides: [access, decisions, contacts, and dates]
Third party provides: [dependency, owner, and required date]
Work may begin when: [approval and prerequisites]

Commercial impact
Added labor/services: [description and agreed price]
Hardware/licenses/third-party fees: [included items and price, or excluded]
Credits for removed work: [amount, or none]
Net price change: [amount and currency]
Payment terms: [terms under the applicable agreement]
Internal commercial approval: [reviewer and approval reference]

Schedule impact
Original affected milestone: [milestone and date]
Revised affected milestone: [milestone and date or scheduling condition]
Effect on other work: [what moves, what continues]
If the change is declined: [original plan or alternative next step]

Acceptance
[Observable result and validation evidence for each added deliverable]
Client acceptance owner: [name and role]
Handoff/support boundary: [what happens after acceptance]

Approval
This change takes effect when [required approval conditions].
Added work will not begin before [approval and prerequisites].
Client approval: [written approval reference and date]
MSP approval: [written approval reference and date]
Final approved version: [version and storage location]

This is an operational template. Have counsel review the approval mechanism and terms against your MSA and SOW. A copied form does not establish who has authority to change a contract.

Show the client the difference, not the whole project again

The approver needs to understand the change without comparing two documents line by line.

Name the original commitment, the new request, and the consequence. Include removed work and credits as clearly as additions. If a new design replaces the original design, review the remaining labor and procurement commitments before carrying both prices forward.

Illustrative scenario: the approved network refresh covers the main office. The client asks to add a warehouse after approval. The warehouse has its own internet handoff, device inventory, access arrangements, and operating hours.

The account manager should ask delivery to validate that site before offering a price. "Same switches" leaves open installation, configuration, testing, documentation, and cutover work.

A useful change summary would say:

The approved scope covers the main office. This change adds the warehouse device installation, configuration, site testing, and updated network documentation. Warehouse access and a maintenance window must be confirmed before we schedule it. The main-office plan remains unchanged unless the revised delivery schedule says otherwise.

Add the actual price, scheduling effect, and acceptance evidence once reviewed. Do not fill the commercial blanks from a previous client's project.

For the original agreement's structure, use the MSP scope of work template. Keep the change form focused on the delta.

Give the vCIO a talk track that preserves the relationship

Acknowledge the request and describe the decision in plain language:

We can assess adding the warehouse. The approved project covers the main office, so we'll confirm the warehouse requirements and show you the added work, price, and schedule impact before you decide. We'll also identify which parts of the original project can continue while you review it.

If the issue is your own estimate, own that first:

We missed effort required for the deliverable we agreed to provide. We're reviewing the recovery plan internally and will explain any effect on the schedule. Separately, we'll document the additional warehouse work you requested so the two issues stay clear.

The client should be able to accept, decline, or defer a change with a stated consequence. Avoid making a request feel compulsory because the team already started it.

Reconcile the approved change with delivery and billing

Written approval is the gate. It still needs to reach the people doing and invoicing the work.

For an MSP using Connectwise Manage, use the following as a reconciliation checklist for your existing project and finance process. It does not assume a particular configuration or automatic sync:

• Store the final approved change and link its reference to the relevant project record.
• Confirm that delivery is working from the approved version, including removed work and exclusions.
• Update the work plan, labor allocation, dependencies, and affected milestones through your normal project controls.
• Have sales admin reconcile approved hardware, licenses, service items, credits, and payment terms with procurement and billing.
• Give engineers a clear way to identify time spent on the added work.
• Tell the support owner what becomes ongoing support after acceptance and what remains a separate obligation.
• Check that the client approver, account manager, and delivery lead have the same next step.

Asana's scope-management guidance treats scope validation and scope control as separate parts of project delivery. Apply that distinction here: agreeing to the change and keeping the working plan aligned are both required.

Keep unresolved changes visible

Maintain a short change log beside the project: reference, request, owner, status, next decision, and approved version. Use statuses your team can act on, such as assessing, awaiting client decision, approved, declined, or deferred.

A deferred request should have a next review point. An approved request should have a delivery owner. "Discussed with the client" is neither.

At closeout, compare the original scope and approved changes with the delivered work. Bring recurring discovery gaps into your project scoping process. That gives the next quote better assumptions instead of another identical surprise.

Scopable's assessment and scoping workflow connects client context, findings, and recommendations to reviewable scope before quoting. Use that context to define the original job clearly; keep the approval and reconciliation steps above in your project controls.

To evaluate that assessment-to-scope workflow on your own client work, start Scopable for free.