MSP Statement of Work

Managing the Commercial Reality of Scope Creep

Scope creep is the silent killer of MSP profitability. It usually starts with a small, reasonable request that takes "only ten minutes." But ten minutes across ten tasks for five engineers adds up to a significant loss of billable time.

Your MSP statement of work should include a formal "Change Control" process. This doesn't mean you say no to the client; it means you say, "Yes, we can do that, but it is outside the current SOW, so here is the additional cost and the impact on the timeline."

Luis Navarro often says that at Totality Services, the goal was to be "commercial, not combative." By having a clear Change Control clause, you aren't being difficult; you are being professional. It creates a framework where the client understands that extra work has a price, which often makes them rethink whether they actually need that "extra thing" right now.

Handling "While You Are Here" Requests

We’ve all been there. An engineer is on-site to swap a switch, and the CEO asks them to look at their slow home laptop. Without an SOW that defines the mission, the engineer might feel obligated to help. A clear SOW empowers your team to stay focused on the project objectives while politely referring side-requests to the helpdesk or the account manager for a separate quote.

The Link Between SOWs and Security Reviews

One of the best ways to generate high-quality projects that require an SOW is through regular Security Reviews. When you sit down with a client to discuss their current risk profile, you aren't just looking for problems; you are identifying the next strategic project.

An MSP statement of work is the natural evolution of a recommendation made during a QBR or security assessment. If your review shows that the client’s backups are not meeting the desired Recovery Point Objective (RPO), the resulting SOW for a backup overhaul is already half-sold because the client understands the risk of doing nothing.

At MSP Agenda, we focus on making this transition seamless. By standardising how you present risk and recommendations, you make it much easier to move the client from "identifying a problem" to "signing an SOW." When the SOW is directly linked to a business risk identified in a review, the price becomes less of an obstacle.

Step-by-Step Guide to Drafting Your Next SOW

Creating an SOW from scratch every time is a waste of resources. You should have templates for your most common projects, but each one needs to be tailored to the specific client environment.

Step 1: The Discovery Phase

Never write an SOW based on a five-minute phone call. Perform a mini-discovery to understand the current state. Check the firmware on the old firewall. Verify the data volume for the migration. Assumptions made during the sales process are the primary cause of project losses.

Step 2: Define Milestones and Deliverables

Break the project into phases. For a server migration, these might be:

• Phase 1: Environment Readiness and Staging.

• Phase 2: Data Migration and Testing.

• Phase 3: Cutover and Go-Live.

• Phase 4: Post-Migration Support and Documentation.

Step 3: Assign Costs to Milestones

Whenever possible, tie your billing to milestones rather than a lump sum at the end. This improves cash flow and ensures that if a project is delayed by the client at Phase 3, you have already been paid for Phases 1 and 2. It also makes the total cost feel more manageable for the client.

Step 4: Review for Technical Accuracy

The salesperson might promise the world, but the Lead Engineer has to deliver it. Every SOW should be reviewed by a technical lead to ensure the labour hours are realistic and the technical dependencies are accounted for.

Step 5: The Commercial Review

Before sending it to the client, look at the SOW through a commercial lens. Is the margin healthy? Are the payment terms clear? Is there a clear path to completion? If the project takes twice as long as expected, does the SOW protect your business?

Common Pitfalls in MSP Project Management

Even with a good MSP statement of work, things can go wrong. Understanding common mistakes allows you to build defences into your document.

• Underestimating "Old" Problems: If you are installing new software on an old server that hasn't been patched in three years, you will run into issues. Your SOW should assume the underlying infrastructure is sound and state that fixing it is billable.
• Vague Acceptance Criteria: When is the project "done"? If you don't define this, a client can hold up final payment because of a minor, unrelated issue. Define "Completion" as the delivery of specific items, not a subjective feeling of satisfaction.
• Communication Gaps: If the client’s main contact goes on vacation for two weeks mid-project, does the project stop? Address the need for an alternate contact in your SOW.
• Failing to Document Changes: If you agree to a change verbally but don't update the SOW or a Change Order, you have no recourse if the client later disputes the invoice.

Advanced Insight: The "Discovery Project" SOW

Sometimes a project is too complex to quote accurately. If a client has a massive, undocumented mess of a network, don't guess the labour hours. Instead, sell a Discovery Project. This is a small, fixed-fee engagement where the deliverable is a detailed report and a subsequent SOW for the actual remediation.

This approach does three things:

1. It gets you paid for your expertise during the planning phase.

2. It removes the risk of underquoting a massive project.

3. It demonstrates your professionalism and builds trust with the client.

Many MSPs are afraid to charge for discovery, but the best ones realise that their time and diagnostic skills are their most valuable assets. A client who won't pay for a discovery project is often a client who will be difficult to manage during a major implementation.

Pricing Strategies within the SOW

How you price your SOW depends on your risk tolerance and the clarity of the project. There are two main approaches:

Fixed Fee

The client pays a set price regardless of how many hours it takes. This is great for standardised projects you’ve done a hundred times (like an MFA rollout). The risk is entirely on the MSP, but the reward is higher margins if you are efficient.

Time and Materials (T&M)

The client pays for the hours worked. This is better for unpredictable projects like emergency disaster recovery or deep-dive troubleshooting. The risk is on the client, but most clients prefer the certainty of a fixed fee, so T&M can be a harder sell for standard projects.

The "Hybrid" Approach

Some MSPs use a fixed fee for the core deliverables but include a T&M provision for anything that falls outside the specific scope or for post-go-live support beyond a certain threshold. This offers the client some budget certainty while protecting the MSP from open-ended support requests.

The Importance of a Standardised Approach

Luis Navarro built Totality Services on the principle of standardisation. When you standardise your technology stack, your service delivery becomes predictable. The same applies to your MSP statement of work. By using standard templates and processes, you reduce the administrative burden on your team and ensure that no critical protections are missed.

Standardisation also makes your business more valuable. If you ever decide to sell your MSP, an acquirer will look at your project history. They want to see that projects were well-defined, consistently profitable, and documented through clear SOWs. High-margin, predictable project revenue is a significant multiplier for your business valuation.

MSP Agenda was designed to bring this level of consistency to your client interactions. By providing a structured way to review security and make recommendations, we help you feed your project pipeline with well-defined opportunities that naturally lead into solid SOWs.

Legal vs. Commercial Language

While an SOW is a legal document, it shouldn't read like one. Your client—the business owner or the Finance Director—needs to understand what they are signing. Avoid excessive jargon and legalese where a simple explanation will do.

Instead of: "The party of the first part shall indemnify the party of the second part in the event of unforeseen latency in the packet transmission," use: "We are not responsible for slow internet speeds caused by your service provider, but we will help you coordinate with them to resolve it."

The goal is clarity. If a client understands exactly what they are getting and what is expected of them, the chance of a dispute drops to almost zero. Credibility comes from being straightforward, not from hiding behind complex language.