# MSP Statement of Work A professional MSP statement of work (SOW) is the bridge between a vague promise and a profitable, successful project. In the world of managed services, ambiguity is the enemy of margin. If your SOW is unclear, your technical team will lose hours to scope creep, and your client will feel frustrated by unmet expectations. A professional **MSP statement of work** (SOW) is the bridge between a vague promise and a profitable, successful project. In the world of managed services, ambiguity is the enemy of margin. If your SOW is unclear, your technical team will lose hours to scope creep, and your client will feel frustrated by unmet expectations. Having spent more than 15 years building Totality Services from a startup to an eight-figure exit, I’ve seen how a poorly drafted SOW can sink a relationship. Luis Navarro, our founder, learned early on that clients don’t buy technology; they buy outcomes. The SOW is where those outcomes are defined, protected, and priced. It isn’t just a legal document—it’s a commercial tool that ensures everyone is on the same page before the first ticket is opened or the first server is migrated. ## What is an MSP Statement of Work? An **MSP statement of work** is a formal document that defines the specific activities, deliverables, and timelines for a technical project or service engagement. Unlike a Master Service Agreement (MSA), which governs the long-term relationship, the SOW is task-specific. It is the roadmap for a one-time project, such as a cloud migration, a hardware refresh, or a security overhaul. From a commercial perspective, the SOW serves three critical functions: 1. It sets the boundaries of the work to ensure profitability. 2. It manages client expectations regarding what they will receive. 3. It provides a technical blueprint for your engineering team to follow. Without a detailed SOW, "installing a new firewall" can quickly turn into "reconfiguring the entire network and troubleshooting three legacy printers" for no additional fee. Successful MSPs use the SOW to draw a hard line around their labour, ensuring that every hour spent is either covered by the project fee or flagged as out-of-scope. ## The Essential Components of a Profitable SOW To be effective, an SOW must be granular. If a section is vague, the client will naturally interpret it in their favor, and your engineers will likely over-deliver at the expense of your profit. Here is how you should structure the document for maximum clarity and commercial protection. ### 1. Project Overview and Objectives Start with the "Why." Don't just list technical tasks. Explain what the business will gain. If you are implementing Multi-Factor Authentication (MFA), the objective isn't "installing an app"; it’s "securing identity and reducing the risk of unauthorized access to company data." ### 2. Scope of Work (The "Inclusions") This is the heart of the document. Break this down into specific phases. Instead of saying "Setup Office 365," list the exact steps: Domain verification and DNS configuration. Creation of 50 user mailboxes. Migration of up to 500GB of email data. Configuration of Outlook on primary workstations. The more specific you are, the easier it is to point to the document when the client asks for "just one more thing." ### 3. Explicit Exclusions (The "Out-of-Scope") This is arguably the most important section for protecting your margins. Explicitly list what you are NOT doing. If you are migrating email, state that you are not migrating SharePoint data or providing end-user training unless those are separate line items. Common exclusions include: - Remediation of existing hardware failures discovered during the project. - Third-party software support or vendor management. - Post-migration support beyond a specified number of days. ### 4. Client Responsibilities and Assumptions A project can only move as fast as the client allows. You must document what you need from them to succeed. If the project stalls because the client didn't provide admin passwords or sign off on a design, the SOW should protect your timeline and your right to bill. | Category | Requirement | Impact if Not Met | | --- | --- | --- | | Access | Admin credentials and physical site access. | Project delays and additional labour costs. | | Hardware | Client-provided hardware must meet minimum specs. | Performance issues and out-of-scope remediation. | | Approvals | Sign-off on technical designs within 48 hours. | Scheduling bottlenecks and missed milestones. | | Communication | Dedicated point of contact for the duration of the project. | Conflicting instructions and wasted engineering hours. | ## 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. --- Source: https://mspagenda.com/blog/msp-statement-of-work Last updated: 2026-04-13