Almost every effective proposal contains the same nine parts, in roughly the same order. The order is not arbitrary: it follows the sequence of questions a client asks themselves while reading. Do they understand my situation? What are they proposing? What exactly do I get? When? For how much? What could go wrong? What do I do next? Answering those questions in that order is most of what separates a proposal that gets a reply from one that gets left open in a browser tab.
1. Executive summary
The executive summary is a short section at the top — three or four paragraphs at most — that states the client's problem, your proposed approach, the headline outcome, and the commercial shape of the engagement. It exists because the person who first reads a proposal is frequently not the person who approves it. A finance director or a business owner may see only this section before deciding whether the rest is worth their time.
Write it last, once you know what the proposal actually says, and write it as a summary rather than an introduction. It should be possible to read only the executive summary and come away with an accurate, if incomplete, picture of the whole document. Avoid using it for credentials or company history; those belong later, if at all.
2. Client goals
Restate what the client is trying to achieve, in their language, before you say anything about your own work. This section performs two functions. It proves you were listening, which is the fastest way to build confidence, and it establishes the criteria against which the rest of the proposal will be judged.
Be careful to distinguish goals from deliverables. “A new website” is something they want to buy; “stop losing enquiries from mobile visitors” is why they want to buy it. When goals are written as outcomes, the proposal has a spine: every deliverable can be traced to a goal, and anything that cannot be traced is probably scope you added out of habit. If your understanding differs from what the client said on the call — because you have seen the pattern before and suspect the real problem is elsewhere — this is the section to say so, carefully and with reasons.
3. Proposed solution
This is where you describe your approach and, more importantly, why it is the right one for this situation. Clients can rarely evaluate methodology on its technical merits, but they can evaluate whether the reasoning makes sense to them. Explain the shape of the work, what happens first and why, and what alternatives you considered and set aside.
Keep it readable. Jargon in this section is a common failure: it feels like precision to the writer and reads as evasion to the client. Where a technical decision matters commercially — a platform choice that affects future costs, a phased approach that lets them stop after stage one — say what the consequence is rather than only naming the choice.
4. Scope of work
Scope is the boundary of the engagement, and it needs both an inside and an outside. The inside lists the activities and areas covered. The outside — the exclusions — is the part most proposals skip, and it is frequently the most valuable paragraph in the document.
Common exclusions worth naming explicitly: copywriting, photography and video, translation, hosting and domain costs, third-party licences and subscriptions, integration with systems you have not inspected, data migration, training beyond a stated number of sessions, and support after handover. None of these need to be excluded — but each should be either clearly in or clearly out. Scope should also record what the client is responsible for supplying, and by when, because a schedule that quietly depends on an unassigned task will slip through no fault of yours.
5. Deliverables
Deliverables are the tangible things the client receives. The test is whether the item can be handed over and pointed at. “Six weeks of development” is not a deliverable; “a deployed application with user registration, an admin dashboard, and exported documentation” is.
Write them as a list, one per line, with quantities and formats attached: number of pages, number of concepts, file types, number of reports and their frequency, whether source files are included. Specific deliverables reduce misunderstandings in both directions. They stop a client from expecting something you never priced, and they stop you from under-delivering something the client believed was central. They also make the proposal feel more substantial, because a list of concrete items reads as more valuable than the same work described in prose.
6. Timeline
A timeline should show structure, not just an end date. Break the work into milestones that correspond to something visible: discovery complete, first concepts presented, feedback consolidated, build complete, testing complete, launch. Give each a date or a week number, and make clear which ones require something from the client.
Set expectations you can actually meet. It is tempting to quote the fastest possible schedule, particularly when you suspect you are competing against someone who will. But a missed milestone in week two costs more trust than a longer estimate costs at signature. Where genuine uncertainty exists, express it as a range and explain what would resolve it. And state the assumptions the schedule rests on — typical feedback turnaround, availability of stakeholders, holiday periods — so that if the plan slips, the cause is already documented.
7. Pricing
Present pricing so that its composition is visible. Depending on the work, that might be a single fixed fee with a summary of what it covers, prices attached to phases, a monthly retainer with defined inclusions, or a day rate with an estimated number of days and a stated process if more are required.
Keep costs that are not your fee visibly separate — media spend, licences, printing, stock assets, hosting — so the client can see what is going to you and what is passing through. Include payment terms in the same section: deposit, the schedule of remaining payments and what triggers each, invoice terms, and how long the price remains valid. If you offer options, keep them to two or three and make the differences substantive rather than cosmetic. A long menu transfers your job — recommending an approach — onto the client.
8. Terms and assumptions
Every plan rests on conditions. Writing them down is not pessimism; it is the difference between a renegotiation and a reference to a paragraph both parties already read. Typical assumptions include the client providing content by a given date, feedback consolidated into a single response per round, one named point of contact with authority to approve, access to necessary accounts, and third-party services behaving as documented.
Terms cover the conditions of working together: ownership of the work and when it transfers, confidentiality, what happens if the project is paused or cancelled, how additional work is quoted and approved, and the handling of expenses. Keep this section factual and brief. It rarely persuades anyone, but its absence is what turns a small disagreement into an expensive one.
9. Next steps
Finish by telling the client exactly what to do. Say how to accept, who to contact with questions, what happens immediately after acceptance, what you will need from them first, and when work could realistically begin. If the price has an expiry, state it here rather than burying it in the pricing section.
This section costs almost nothing to write and has a disproportionate effect on response rates. A proposal that ends with “let us know your thoughts” invites the reader to postpone. One that ends with a specific, small, obvious action — reply to confirm, or book a fifteen-minute call to walk through the scope — gets answered, including by the clients who are going to say no, which is information worth having early.