Why most WordPress proposals lose the job before the client reads the price
Most WordPress project proposals I review for other freelancers share the same three problems. They describe the freelancer instead of the client’s problem. They list technologies instead of outcomes. And they quote a number without explaining what the number includes. The fix is structural, not cosmetic. A proposal is a selling document and an insurance policy at the same time, and it needs to work as both.
This guide is the structure I use on projects in the three thousand to fifty thousand dollar range, which is where most independent WordPress work lives. It has won me projects I expected to lose and filtered out work that would have ended badly. Copy the structure, adapt the language to your voice, and kill the sections that do not apply to your engagement. The eight sections matter more than the specific phrasing.
Before you write a single word of the proposal
No proposal survives contact with a bad discovery call. Before sending anything, you should be able to answer five questions in one sentence each. If any of them are fuzzy, do another discovery call. A second call always costs less than a rewritten proposal. Here are the five:
- What business outcome does the client actually want? Not “a new website.” Something like “double lead submissions from organic traffic by the end of Q3” or “cut the 40 percent cart abandonment rate we have today.” If the client cannot answer this, help them answer it during the call.
- What does success look like in 30, 60, and 90 days? This forces the client to think past the launch and into the actual value the site is supposed to deliver.
- What is the client’s internal bottleneck? Is budget approval the blocker? An anxious CTO? A marketing deadline tied to a product launch? The bottleneck tells you who really has to say yes, and what they need to hear.
- What have they tried before and why did it fail? Every client over $10k has a history. You need to know it. The last agency that burned them is the reason they are hesitating now, even if they do not say so.
- Who is the decision-maker and who is the user? These are often different people. The proposal needs to speak to the decision-maker first, and the user second. I have lost jobs by writing the proposal to the user when the CEO was the one signing.
The eight sections of a proposal that wins
Every proposal I send now has the same eight sections in the same order. The order is deliberate, because client value comes before your credentials, scope comes before price, and risk comes before timeline. Deviating from the order produces proposals that feel like resumes, which is how you lose the job.
1. Executive summary (one paragraph)
Three sentences: the problem in their language, the outcome you are committing to, the approach in plain English. No technology names. If the client can read only this section and still know exactly what they are buying, the summary works. If they cannot, the summary fails, and the rest of the document does not matter because most clients will stop reading at the first section that confuses them.
2. Understanding of the project
Show that you heard them. Restate their situation in more detail than they gave you, including the bottleneck and past attempts. This is the single most effective trust-builder in the document. It proves you were listening on the call, and it tells the client you understand their world well enough to work in it. I have won jobs on this section alone, specifically because the other three agencies bidding on the project went straight into their own capabilities without proving they understood the ask.
3. Proposed solution
Describe the outcome first, then the path. Structure it as follows: what the user experience looks like after launch, what the content editor experience looks like, what technical stack you are proposing and why it fits this specific problem (not “because I like it”), what integrations and third-party services are involved, and what is explicitly out of scope.
The out-of-scope list is the most valuable paragraph in the entire proposal. Most scope creep starts with a client assumption that was never contradicted in writing. Write down everything you are not doing, even if it feels aggressive. Clients rarely complain about an explicit out-of-scope list. They complain constantly about things they assumed were included.
4. Phases and deliverables
Break the project into three to five phases. Each phase has a name, a one-line goal, specific deliverables the client can see and approve, and a duration in weeks not days. I prefer weeks because day-level estimates look artificially precise and set you up for failure the first time something slips.
| Phase | Goal | Key deliverables | Duration |
|---|---|---|---|
| Discovery & Design | Lock in look, feel, and key flows | Wireframes, style guide, approved mockups | 2 weeks |
| Development | Build the site | Theme, custom blocks, CPT config, integrations | 4 weeks |
| QA & Content | Ship-ready | Test plan, content migration, accessibility audit | 2 weeks |
| Launch | Go live | DNS cutover, 30-day hypercare period | 1 week |
5. Investment
Never call this section “Price.” The word “investment” frames the number as something the client is trading for value, not something they are losing. Offer two or three tiers when it makes sense (Lean, Standard, Enhanced is a common pattern). The middle tier is what most clients pick, and it is the tier you should be most comfortable delivering because it is the one you will deliver most often.
Each tier includes a bulleted list of what is in it so the difference between tiers is obvious at a glance. Pricing models worth considering:
- Fixed bid. Good when scope is locked. Highest risk to you, highest certainty for the client. Use this only when you have done the same type of project at least three times.
- Time and materials with a cap. Good for ambiguous scope. Lowest risk for you. The cap protects the client from runaway costs.
- Monthly retainer. Good for ongoing support and development work. Predictable for both sides, and the compounding client relationship is valuable.
- Milestone-based. Fixed bid broken into phase payments. This is what I use on most projects because it matches cash flow to delivery risk.
List your payment schedule inline in the Investment section. The industry default is 50 percent to start, 25 percent at midpoint milestone, and 25 percent on launch. Anything less than 40 percent up front is a red flag for you, not the client.
6. Timeline with dependencies
A Gantt chart is overkill for most projects. A two-column table listing “our tasks” on one side and “client tasks” on the other, per phase, is more useful. The client often does not realize they have homework. List the specific things you need from them (hosting access credentials, Stripe keys, final copy for three pages) and the specific deadline by which you need them.
This single table has saved me more project slippage than any other part of the proposal. When you put “we need the hosting access by end of Week 1” in writing, the client either delivers it on Week 1 or apologizes in Week 2. Either way, the delay is their fault, not yours, and the timeline adjustment is pre-negotiated.
7. Risks and assumptions
An explicit section. List three to five assumptions the proposal depends on (“the existing site has no custom plugins,” “content will be supplied in Google Docs,” “Stripe will be the only payment gateway”) and how you will handle it if an assumption breaks. This section moves the conversation about change orders from “surprise!” to “as we discussed in the proposal.” Both sides are happier.
8. Who you are (last, not first)
Three to five short paragraphs on your team and your relevant previous work. Put it at the end. Nobody buys a WordPress project from a freelancer whose proposal opens with a resume. The credentials section is there to reassure the decision-maker after they already decided they want to work with you. It closes the deal, it does not open it.
The anti-patterns I stopped doing
Things I cut from my proposal template over the last five years because they consistently cost me work or margin:
- “Starting from $X.” Clients read this as the real number and anchor to it. The actual number always feels higher, even if it is fair.
- Unbounded revision rounds. Specify “up to two rounds of feedback per phase” in every proposal. Anything else is a blank check for rework.
- “Additional features quoted separately” without giving sample hourly rates. Leaving the rate blank makes the client assume the worst.
- Sending a PDF with no followup. Always schedule the proposal review call when you send the proposal. A proposal that sits for two weeks is dead. The followup call is not optional.
- Matching the cheapest competitor. Clients who buy on price alone churn within a year. If a competitor underbids you by 40 percent, step out of the deal.
From proposal to Statement of Work
Once the proposal is accepted, the Statement of Work becomes the legal document. It is the proposal with the selling language removed and the contractual language added: intellectual property ownership, hosting responsibility, warranty period, governing law, dispute resolution process. The scope language should copy-paste from the proposal word for word. Do not let the Statement of Work redefine scope, because any change between the proposal and the Statement of Work is a change the client will notice and question.
The contract is a good moment to check in on client onboarding. If you are also offering ongoing support, see my guide to scaling a WordPress freelance business for the retainer pricing structure that pairs well with this proposal model.
The follow-up cadence
Send the proposal. Follow up at day 3, day 7, and day 14. After day 14, move on. Silence after 14 days is a no, regardless of what the client says when they eventually reply. This rule alone has saved me hundreds of hours of hoping, because hoping is the most expensive activity in freelance business development.
Keep a template, save the hours
Keep a Notion or Google Docs template with the eight sections pre-written and only the client-specific paragraphs left blank. A good WordPress project proposal should take two hours to adapt, not two days. If you are spending a full day on every proposal, you are rebuilding the structure each time instead of reusing it, and that is the single biggest efficiency win available to a freelance operation. The template is also what lets you scale later. When you hire your first employee, the proposal template is one of the first things they will use.
Proposals are a solved problem. The hard part of freelance WordPress work is delivery and client communication, not selling. A good proposal gets you out of the selling phase fast, so you can spend your time on the work that actually matters.
AI in WordPress Client Management Content Planning
Last modified: April 14, 2026
