Managed Services Proposal Templates - Getting Started

My belief that IT companies and Managed Service Providers (MSPs) should NOT be writing proposals is well documented (See Sales Proposals: The Good, The Bad and the Ugly).

In most cases, when the prospect says “Can you put that in a proposal?” they are actually saying “I’m not convinced, but I want to be polite to you, and anyway, a written proposal will help me to shop around elsewhere”.

But I’ll admit that there are occasions when writing a proposal is necessary. For instance, many non-profit organizations have a general manager, but also a board of trustees who need evidence and to sign-off on business before they can go ahead.

So with that in mind, what should a good proposal document look like?

Problem statement

A proposal should start by demonstrating an understanding of the client's challenges.

It should highlight the:

• Client Needs – what problems do they want to solve?
• Client Objectives – why and how do they want to solve these problems?
• Client Goals – how will the client know they’ve succeeded?

I’m a big fan of using the client's own words and phrases here – it demonstrates that you are listening and you understand how they feel. It’s also worth using emotive words (See How Using Emotive Words Can Help Your MSP Win More Business) to highlight the real feelings involved. Remember, people buy based on emotions, not on logic.

Recommended solution

The next part of a good MSP proposal should state the recommended solution.

Re-iterate the client's objectives and goals, and state how this solution will specifically resolve them.

Demonstrate the expected state of affairs after the solution has been implemented. Show the client clearly how they will know the solution has resolved their challenges.

Further, demonstrate how the world will look to the client in the time well after the solution has resolved their challenges. Is it saving them time? Money? If so, how much time, and how much money? Be specific.

In short, paint a picture of what the client's business looks like after you’ve deployed the solution.

Pricing information

Be open and honest here. Regardless of how good your MSP proposal is, the bottom line is a client will want to know what it costs them.

Be clear over what is included, and what isn’t. For larger projects, define what is “in scope” and what is “out of scope” – so what is likely to come under additional charge. This can make the difference between a profitable project and a series of “while you are here, can you just do this too?” issues for your engineers.

Give a summary of all the costs.

I’m not a fan of breaking individual projects down into component parts with individual pricing. It encourages clients to “shop around” and “pick and choose”.

If you’ve not already got a clear idea of budget, then don’t write a proposal. You are setting yourself up for a fall.

If the client doesn’t want to pay for the solution you’ve suggested, you can discuss with them what has changed since you first spoke, and if necessary, which parts of the work they want you to remove, and which parts of their problem they want to keep…

Estimated project schedule

Set realistic timescales, and be explicit about the expectations of the client.

In other words, if the client drags their heels making a decision, the subsequent delay is their problem, not yours.

Don’t be bullied into shortening timescales because the client is in a rush. You’re setting yourself up for a lose-lose scenario. If you agree and you fail to deliver the work on time (because, frankly, it was never going to happen) then the client blames you. If you do miraculously deliver on time, the client will take it for granted.

Next steps

One of the most important parts of a proposal, and yet the one many miss off is: What happens next?

What next step should the client take, and what can they expect to happen after that?

If the client has questions, who should they call to discuss?

If the client is ready to proceed, what documentation should they sign and return? What will you do once you’ve received this documentation?

Make it easy for the client to understand what they need to do next, and what you will do in response. It will give them the confidence to move forwards, and the impetus to avoid ignoring a decision.

T&Cs and company information

If you want to include Terms & Conditions, do so, but at the end of the document.

Likewise, if you want to include company information about yourself, feel free – but realize that while you are interested in who you are, for the client it comes secondary to what you can do for them. So again, include this information near the back of the proposal.

Templates

A tip: the first time you write a proposal of this nature, create a template with your company branding, based on the structure we’ve looked at here. Save that template for future use, then populate it with your actual proposal.

Don’t make the mistake of writing a proposal, then using that for future proposals. If you do, you run the risk of sending some confidential client info from a previous proposal out to another client. Trust me, it happens all the time!

Conclusion

I’m still a firm believer that you should avoid writing proposals wherever possible.

They give away free consulting to a client, and encourage a client to shop around. This is wasting your valuable time.

But where proposals are a necessary evil, follow the structure we’ve looked at in this blog post - it could mean the difference between you winning business, or handing the business to your competitors