Over the last eight years, I have written hundreds of proposals for WordPress website projects. In the early days, most of them were terrible. Then I started paying attention to what I was putting out and the feedback I was receiving. I started making small incremental changes to my proposals until I found a formula that worked for me.
In this article, I’m going to share everything I’ve learned from writing proposals over the last eight years to help you write better proposals for your prospects and win more projects.
Disclaimer: my clients are predominantly small to medium-sized businesses. If you’re dealing with enterprise clients you may need to include more detail in your proposals, however, I still think the framework I’m sharing with you here is a good place to start.
A Proposal Needs To Propose Something
Most proposals I have seen over the years look and feel like fancy brochures or very boring technical documents. I’ve realized that a proposal is actually a document that formalizes what you and the client have already agreed upon. Just like a printed invitation to a wedding that you’ve already agreed to attend. It outlines the details and formalizes the agreement.
I think the reason a lot of proposals miss the mark is because the proposer feels like they need to sell themselves in the proposal, when, in reality, if you are using a proposal to sell yourself, then you have failed in your marketing. By the time a client asks you for a proposal, they should already be convinced that you are right for the job.
The job of a proposal is to propose a clear and obvious solution to help the client achieve their objectives and solve their problems.
It is not a sales document. It is not a marketing brochure. It is not a functional specifications document.
Proposals Do Not Need To Be Beautiful
When I first started out, I would send proposals as a Word document attached to an email, which in theory could still work. Then I thought my proposals needed to look beautiful because I was selling design services, so I would spend hours in InDesign producing beautiful proposals worthy of a design award (it’s amazing what you can do with a template). Nowadays, when I see a proposal that has been “designed” I immediately wonder what’s missing and what they are compensating for.
I’m not suggesting that your proposals should not be aesthetically pleasing to look at, however if there’s too much style and not enough substance then there’s a clear problem. Put your effort into making sure your proposal is easy to read, easy to understand, and actually proposes a solution.
What To Include
Let’s talk specifically about what to include in your proposal. These are the nine sections that I now include in every proposal, in the order in which I include them.
The snapshot is simply a one to two sentence paragraph that outlines who the client is, the business they are in, and the fact that they have approached you to build a new website for them.
This section outlines why the business needs a new website. Generally speaking, I will include three to five bullet points here based on what the client has told me. It’s important to understand how the client is going to measure success and include those factors in this section.
This is your opportunity to show your client that you care about their success and helping them achieve a return on their investment.
This section outlines the target audience for the website and what they need from it. If your client is a brick and mortar business, for example, the target audience will need to find an address and trading hours.
Alternatively, if your client is a dance studio, then the target audience will need to find class timetables and pricing. The more you demonstrate that you understand the target audience and why they need to use the website, the more value you are adding to your client’s business.
This is where you get to flex your creative muscle and propose a solution to help the business and its target audience achieve their needs. Try to resist listing the features of the website. Demonstrate how these features will benefit the client’s business. For example, opt-in forms may not mean as much to the client as generating new leads.
This has been one of the most profitable changes I have made to my proposals over the years. My advice is to practice rewriting features into benefits every opportunity you get.
The timeline simply outlines how long you believe the project will take from start to finish and lists any milestones along the way. For a typical website, my timeline usually includes the following milestones and timing:
- Sitemap – One Week
- Prototype – Two Weeks
- Design – One Week
- Development – Two Weeks
- Testing and Deployment – Two Weeks
Of course, timing will vary depending on the complexity of the site.
This is my favorite section. It’s where you get to outline the investment required by the client to activate this proposal and help them achieve their objectives. Hopefully, by this point in the relationship, you have already determined that the client has a realistic budget to achieve their goals. If you are writing proposals without any awareness of the client’s budget then you are wasting everyone’s time. Make sure you qualify your client’s expectations before you spend any time putting together proposals.
I have experimented with many different names for this section including “pricing,” “fees,” “fee structure,” “ budget,” “cost,” “spend,” “rates,” “expenses,” “cashola” (I’m not kidding), “how much is it?”, “what’s it gonna cost,” and even “damage.”
Why it took me so long to find “Investment” is one of the great mysteries, but I promise you that positioning this as an investment will dramatically improve your chances of getting your proposal accepted.
I offer project-based fees these days so I don’t break down line items or components. I once had a client question why “project management” was included in my proposal. She couldn’t understand why we needed to have a dedicated project manager to make sure the project was delivered on time and within budget. So I offered to remove the project manager and add the fee to the development cost. It was a frustrating argument with an inexperienced client but it did make me realize that I had not illustrated the value well enough.
Immediately following the investment section are the frequently asked questions. This is where I list the most common questions I get from clients during the proposal process. I answer all of these questions thoroughly in an attempt to cover any objections the client may have while they are reading the proposal.
What happens once the website goes live? What about hosting? How long will it take me to rank on page one of Google? What about change requests? What about updates? Can I install my own plug-ins? (By the way, the answer to that question is “No”.) Who handles the content? Will you teach us how to use the website?
Every time I get a question from a client during this process I add it to my template for future use.
The next section outlines what the client needs to do in order to activate the proposal and move forward. I use Bidsketch to send my proposals so this section tells the client to push the approved button on the website where they read the proposal (it’s very satisfying to see the email come through from Bidsketch telling you your proposal has just been accepted and usually triggers a five-minute happy dance around the office).
Just like asking blog readers to leave a comment, this very clear call to action is important. In the old days, I actually had more than one client call me up and ask what we do next?
The final section of my proposals is called the mutual agreement. It used to be called terms, however I found that the bit impersonal. This section of my proposals is based on Andy Clarke’s Contract Killer, which he so kindly open sourced back in 2008.
The key changes I have made to Andy’s template are that I do not host websites and that I’m not responsible for keeping their website on my development server for any longer than 30 days if they are not ready to populate their content.
In a perfect world (and most of the time for me these days), the client will have already given all of their content to you before you make a start on the project or you will just do the content for them and charge them accordingly.
Now that you have the sections and the order, there are a few other things to consider when writing your proposals.
I try to keep my proposals as lean as possible. Remember a proposal is not a functional specification document. A proposal can propose that you develop a functional specification document for which you should be paid, however, a proposal is not a functional specification document.
If there are multiple decision-makers in the process, I will provide a one-page executive summary that outlines the key needs of the business and audience and the key benefits of the solution I’m proposing. This can be passed around very quickly at meetings and the proposal can be referenced for greater detail.
Most importantly, I will try to use the client’s language as much as possible throughout the proposal. I record my meetings with clients and have them transcribed so that I can reference their language while I’m writing the proposal. A proposal that is written in a way that resonates with your client is much more likely to be read, understood, and accepted.
Stop Talking About WordPress
I love WordPress. It has provided a fantastic lifestyle for me over the last eight years and I’m very grateful for the amazing community that has grown up around it. However, 95% of my clients don’t know what WordPress is and don’t care. They want a solution to their problem or help in achieving their objectives. Do you know the brand of stethoscope your doctor uses to check your heart rate? Do you know the brand of machinery your mechanic uses to tune your car? Do you know the software your accountant uses to lodge your tax returns?
You get the point. I have found over the years that mentioning WordPress or the names of plugins or theme frameworks only serves to confuse the client and raises questions that they don’t need to be asking. WordPress, theme frameworks, and plugins are optimizations that this clever community has contributed to our manufacturing process. I think of them as raw materials that I add value to as a consultant.
The only time I mention WordPress is if the client indicates it is important to them that we build the solution on WordPress. This happens very rarely.
I’d love to hear what’s working for you in your proposals or if there are any key takeaways from this article that you have found helpful! Good luck in your proposal writing endeavors.