What belongs in a freelance proposal, and what to leave out

A proposal that wins work carries eight things: the problem in the client's own words, the scope, an explicit list of what is not included, deliverables with dates, the price and payment schedule, what you need from the client, your assumptions, and a validity date with one next step. Everything else — your biography, a methodology essay, a stock photograph of a laptop — is padding.

Order matters as much as contents. Clients read the first page and skim the rest, so the first page has to carry the problem, the price and the date. For work under about €10,000, six pages is generous.

The eight parts

1. The problem, in their words

Open by restating what the client told you, in their vocabulary rather than yours. If they said "our booking page loses people", don't translate it into "conversion funnel underperformance". This does two jobs: it shows you were listening, and it pins down what you are being paid to fix before anyone argues about method. If you can't write this paragraph from your notes, you didn't have enough of a conversation to quote the work.

2. Scope

Specific verbs, countable outputs. "Audit the checkout flow" is not scope. "Review the six checkout screens on desktop and mobile, test three payment paths, and record each issue with a screenshot and a severity rating" is scope. Countable things are the only kind that can be marked finished.

3. What is not included

The section that prevents most disputes, and the one most people skip. Name three to six things a reasonable client might assume are covered: implementation of the fixes, copywriting, new photography, changes after sign-off, third-party licence costs, anything ongoing. This isn't defensiveness. It is the cheapest way to keep the price honest, and clients who have been burned before read it with relief.

4. Deliverables and dates

Name the artefact and its format. "A 12-page PDF report and a 40-minute walkthrough call" beats "recommendations". Keep dates relative where the start depends on the client: "within 10 working days of receiving access". A fixed calendar date you don't control is a promise you will break.

5. Price and payment schedule

One number per option, gross or net stated consistently, with when each part falls due. "€4,000. 50% to begin, 50% on delivery of the report" ends more questions than a page of justification. If the price genuinely depends on something unresolved, say what it depends on and give the range rather than burying it in a footnote.

6. What you need from them

Access, content, a named decision-maker, a review turnaround. Late projects are usually late here. Give it a heading of its own and put a deadline on it: "staging and analytics access within five working days of signing".

7. Assumptions

A short list of what you treated as true when pricing. "The site runs WordPress 6.x." "One round of consolidated feedback." "Content is supplied in English." If an assumption turns out to be wrong, this list is what lets you reprice without an argument.

8. Validity and the next step

A date the price holds until, and one action. "Reply to this email to accept and I'll send the agreement and the first invoice." Offer three possible next steps and you will get none.

If you would rather start from a skeleton than a blank page, we sell a Consultant Proposal & Scope Pack — the proposal in Google Docs and Word with the scope and out-of-scope sections already structured, plus a one-page version for small jobs. It is a working document skeleton, not a legal document and not a contract; the agreement you sign afterwards is a separate thing and worth having a lawyer read.

What to leave out

• Your life story. One short paragraph of relevant background, near the end, if at all.
• A methodology essay. Method is how you justify the price to yourself. Clients are buying the deliverable.
• Logo walls. A single line naming comparable work does more than a grid of client marks, and doesn't invite "did you work on that, or did your agency".
• Stock photography. It reads as filler because it is.
• Terms copy-pasted from somewhere. Boilerplate you have not read is worse than no boilerplate. Either it is your agreement or it is noise.
• A price that only appears on page five. People scroll to it anyway, and the build-up reads as nerves.

The three-tier trick, and when it costs you money

The standard advice is to always present three options and let anchoring do the work. It does work — when the client already knows what they want and the tiers are genuinely different answers to the problem.

It fails in three situations that come up constantly. When the client has not decided what the project is, three options hand your job back to them, and the usual response is silence. On referral work, where trust already exists, tiers read as an upsell and can cost you the goodwill that got you the introduction. And when the tiers differ only by hours or by "number of revisions", you have not offered a choice, you have published a discount menu — the client picks the cheapest and now expects the middle one's outcome.

If you use options, make each one a different approach, not the same approach in three sizes. Two is usually enough.

A worked example

Say a small e-commerce business tells you customers are abandoning the checkout. A proposal for that job might run: page one, the problem as they described it, the price of €4,000, and the start date. Page two, scope — six screens reviewed on two devices, three payment paths tested, analytics for the last 90 days reviewed, findings recorded with severity. Page three, what is not included: implementing the fixes, new product photography, anything touching the payment provider's own hosted pages. Page four, deliverables — a PDF report with each issue ranked, a one-page summary for their board, a walkthrough call within 10 working days of receiving access. Page five, what you need from them, the four assumptions the price rests on, the payment split, and a validity date.

Five pages. No bio, no case studies, no method chapter. Everything a person needs to say yes.

After you send it

Send a PDF, and put the price and the date in the two-sentence email body — some people decide without opening the attachment.

If the client asks for changes to scope, reissue the whole document with a new version number and date rather than quietly editing the file. "v2 — 14 July" settles arguments that "the proposal you sent me" cannot.

If they ask for a lower price, take scope out rather than reducing the number. A discount teaches the next client what your rate really is; a smaller project does not.

Related

• Client tracking: when a spreadsheet is enough
• Structuring an SOP people actually follow
• Documents and decks in the shop: Documents & Decks