It was a dark and dreary night... well actually, it was a question raised in an online discussion that resulted in what I hope will be a helpful guide for anyone faced with writing an MSP proposal.
My name is Matt Topper and I'm the Director, Security at Gradient MSP.
I have spent over a decade wearing multiple hats at an MSP that grew from small to large; one of my responsibilities, in addition to my security role, was to run the Professional Services department, starting from zero.
Learning to prepare proposals that consistently close and prevent the implementation team from running into unpleasant surprises along the way is something I had to perfect through trial and error. The ideas presented here are ones that were implemented successfully. My intention is to help provide a roadmap for other organizations so that they do not need to start from zero.
Writing proposals for MSP projects is tough. What makes it worse is the mountain of nebulous advice that comes your way, without any concrete examples to guide you.
The format described here is time-consuming, but it is crucial to note that the planning is as important as the outcome and will save you time in the long run.
In other words, the thought required to complete all sections inherently requires proper planning. When potential roadblocks or headaches come up during the initial discussion or planning phase, the need for change orders or scope creep reduces dramatically – in fact, by taking great care in the planning stage, change orders almost never pop up.
When writing a Statement of Work (SOW), the number one objective is to remove ambiguity. There shouldn't be any open questions as you move forward. Questions such as, "is this part of the project?" or "when do we close this?". If there is doubt or hesitation, you missed something.
The purpose of this section is to explain the background information that led to the project and provide a high-level explanation of your proposed actions.
Only a few sentences are needed here. This section should also explain why this solution is being proposed over others.
If there are other obvious solutions, here is where you explain why this particular one is being proposed over and above any others. For example, if the suggestion is for a cloud migration, briefly explain the benefits of that vs. a replacement physical server.
Example:
This project is a migration from the existing on-prem Exchange server to hosted Microsoft 365. 25 mailboxes on one domain will be migrated. There is one application that sends email and two copiers that scan email. This was suggested over a server replacement due to the organization's overall migration towards SaaS services.
This section is where you’ll find the meat of the proposal. It explains what is going to happen and in what order. It’s best to do this as an outline with each outermost item representing a phase.
The level of granularity should roughly map an item to an individual step or ticket in a project. For example, if setting up a new server, something like "provision virtual machine", "install operating system", etc., would be sufficient. You don't want to go more granular than that.
When working with very specific items within a collection, list each item by name. For example, itemize the applications you are moving during a server migration or specific file shares that are being migrated. This is something of a judgment call – there is no need to list each individual mailbox during a Microsoft 365 migration if you are moving every mailbox.
Your project templates will be more granular. For example, in your own documentation system, there would be a guide on how to install Windows, including required configurations. But you don't need steps like "input activation key" in your SOW.
Example:
This section should be a list of items that the MSP specifically isn't performing as part of the project.
This is all about setting expectations and ensuring that there are no surprises. To generate these, ask yourself, "what are things that a client might expect to happen that we haven't included in the estimated labor?" These might change during the discussion with the client before the proposal is signed.
Remember, the goal is to remove ambiguity so that everyone is clear. Items can always be added later, with a corresponding adjustment in the labor estimate, or a change order if the project has already started.
Finally, note that the last statement includes a catchall of anything that is not listed in the scope as being out of scope. While this technically makes listing the specific items redundant, this section limits surprises by listing items that a client might consider to be in-scope that are not accounted for in labor charges. I have never pointed to this last item during a billing dispute; it's there for expectation setting only.
Examples:
This is a list of conditions that must be true for the labor estimate to hold. In other words, if something in this list turns out to be not true, expect a mid-project change order.
This section is often the longest, with the exception of the scope, and it's where you can avoid most project landmines. Below are example scenarios where an assumption will help you in the long run. [these actually happened]:
Is the client handling any part of the migration themselves? This refers to anything that the client needs to do that you aren't managing (or billing for) as part of the project.
It doesn't automatically translate into "things the client is doing to cut the project cost down", though if you have any of those, here is where you’ll put them. It’s more about what actions the client needs to take to ensure a successful outcome.
Anything in this section can also go into the assumptions section but separating them out and placing them here improves project clarity. It would cover items such as:
Note about vendor professional services: There is a difference of opinion on whether to resell vendor services for migrations. Taking care of the coordination and packing everything up into one quote is good for the client. However, a vendor's poor support becomes a reflection of you and your company when you resell it. Whether you do this depends on the client and the vendor.
This section falls into two categories and describes vendor-specific requirements:
Example:
This section gets everyone on the same page about sections of the project that will cause downtime. It also helps when determining labor estimates for portions that will need to occur after hours. Finally, if there is a section that has the potential to cause downtime, indicate that here.
This is also an opportunity to save yourself from requests such as, can this be done at 11:00 PM New Year's Eve? without necessitating a discussion on how that will impact pricing.
Example:
When this application migration begins, no employees will be able to access it until completion. Migration is expected to take 4 hours and will start at 6:00 PM on a date agreed upon.
The goal of this section is to make the end of the project clear and objective. Here are some examples resulting from that comment I mentioned earlier.
Example:
One of the problems with big migration or implementation projects is that it can get "sticky", where little items keep getting lumped in as "we shouldn't be billed for this as it was really part of the project". If you weren't clear up front about what the scope is, you end up eating those hours and not being able to bill for them. A somewhat moot point if the client is on an all-inclusive plan, but it does skew the profitability of your professional services department. Actually, that's another really good point. More mature MSPs will track the finances of professional services and break/fix separately. So, if you, the professional services team, do something that causes the support desk and the "managed services" department to receive a zillion phone calls, you are going to screw up their metrics just from doing the project and being very clear about what is/isn't in the project. Just avoid this.
The most important item in the closing criteria section is the last one specifying a time limit after which support calls are no longer "part of the project". It creates a clear demarcation point not open to interpretation – it's closed two weeks after cutover.
Always go over the proposal with the client in an online or in-person meeting, rather than just emailing it and hoping for the best. This is not a pitch – the client should already be on board with the idea of doing the project if you're writing a formal proposal.
This is the chance for everyone to discuss any missing elements. Sometimes a training session is needed. You can add it as part of the project and discuss how it will impact the final project cost
When sending these out, be sure to do it via your quoting system or an e-signature tool so that there is evidence of agreement. Ideally, it should be part of the quote if your quoting system allows for that.
With every item there is an unwritten "reasonableness rule" and the proposal is not intended as a bludgeon for your client. You don't need to start the change order paperwork for something that will cost you an extra 30 minutes. In fact, I can count on one hand the number of times we ever went back and pointed to something being in the "out of scope" section—and those were for egregiously unreasonable requests.
Who should write these and how do you decide what to scope/quote? The answer to that will be provided in part 2.
For more great resources, or to find out how Gradient can simplify your business, check us out.