How to Write a Freelance Proposal That Wins the Work

Most freelance proposals lose the job in the first paragraph, and they lose it the same way: they start talking about the freelancer. A short introduction, a list of technologies, a paragraph about the studio's philosophy, and then — three pages in — something about the client's actual problem. By then the reader has skipped to the number.

A proposal that wins does the opposite. It opens by demonstrating that you understood the problem better than the person who described it to you, and everything after that is logistics. Price, timeline and scope still matter enormously, but they are decided in the client's head after they have decided you get it. Get the order wrong and you are competing purely on cost.

This guide covers the difference between a proposal and a quote, the discovery questions that make the writing almost automatic, a seven-part structure with a length budget for each part, how to draw scope boundaries that survive contact with a real project, how to present price, what to do when the client goes quiet, and when to walk away. There is a compressed worked example at the end.

A quote answers "how much". A proposal answers "why you"

These are different documents and most freelancers send the wrong one. A quote is a price against a specification someone else wrote. It is appropriate when the client genuinely knows what they want, has written it down, and is comparing like for like — replacing a WordPress theme, migrating a mailbox, cutting forty product photos.

A proposal is what you send when the client has a problem rather than a specification. It argues for a particular way of solving it, and the price is the last of seven things it does rather than the only thing. If you send a quote into a situation that needed a proposal, you have volunteered to be judged on a single axis — and on a single axis there is always someone cheaper.

The tell is easy. If you could hand the client's brief to three freelancers and get three documents that differ only in the number at the bottom, the brief needed a proposal and nobody wrote one. Your opportunity is to be the one who does.

None of this applies before you have a lead worth writing for. If that is where you are, getting your first freelance clients is the more useful problem to solve first — a brilliant proposal sent to nobody is an expensive hobby.

The proposal is written on the discovery call

The single biggest predictor of whether a proposal is easy to write is whether you had a real conversation before writing it. Freelancers who dread proposals are almost always trying to write them from a two-line enquiry form, which means guessing — and guesses read as guesses.

Thirty minutes on a call gets you the raw material. You are not there to pitch. You are there to collect the client's own sentences, because the proposal will be built out of them.

The questions that do the most work

• What made you start looking for someone this month? The trigger. There is almost always a specific event — a funding round, a bad quarter, a person leaving, a launch date — and it tells you what urgency you are working with.
• What happens if this does not get fixed? The cost of inaction. This is the number your price is compared against, whether or not anyone says it aloud.
• What have you already tried? Saves you proposing something they abandoned last year, and tells you what they believe about the problem.
• Who else has to be happy with this? Names the people who will review your proposal without having spoken to you. Write for them too.
• What does done look like? Push until you get something observable. "A better website" is not done. "Our sales team can send a link they are not embarrassed by" is done.
• What cannot change? The existing CMS, the brand guidelines, the person who owns the copy, the date of the conference. Constraints are gifts — they narrow the work and make your reasoning legible.
• Have you budgeted for this? Ask it plainly. A range is fine. A refusal to give any indication is itself information.
• When do you want to decide? Gives you a follow-up schedule you did not have to invent.

The sentences you are listening for

During the call, write down the client's phrasing verbatim — not your paraphrase. When they say "it takes us three days to get a quote out and half of them never go", that sentence goes into the proposal in quotation marks or very close to it.

Two things happen when a client reads their own words back. They stop evaluating whether you understood, because the evidence is right there. And the problem starts to feel like something already half-solved, because someone else is now holding it.

If you did not get a call — some clients will not give you one — send three questions by email before you write anything. Three is small enough to answer and enough to avoid the worst guesses. A short delay to ask is cheaper than a confident proposal about the wrong problem.

The seven parts, with a length budget

Here is the structure. The budgets are deliberately tight, because the failure mode is not brevity — it is a fourteen-page document that reads like a defence of the price.

Seven parts. Two pages. Anything longer is negotiating against yourself.

1. The problem, restated — 100 to 150 words

Open with their situation, in their language, including the constraint and the trigger. No greeting paragraph, no company boilerplate, no "thank you for the opportunity". The first sentence of the document should be about them.

This section is doing something specific: proving you listened well enough to be trusted with the next section. If the client reads it and thinks yes, that is exactly it, everything after is a formality. If they read it and think close enough, you have already lost half the advantage.

2. The proposed approach — 150 to 250 words

How you intend to solve it, and — this is the part people miss — why this way rather than the obvious way. Two or three moves, in order, with a reason attached to each.

This is where expertise becomes visible. A client cannot evaluate your code or your typography from a document, but they can absolutely evaluate whether your reasoning sounds like someone who has done this before. Naming an alternative you considered and rejected does more for your credibility than any list of past clients.

3. Scope — 150 to 250 words

What is included, what is explicitly not, and how changes are handled. This section is covered in detail below because it is the one that determines whether the project is pleasant or awful.

4. Deliverables — 60 to 100 words

A plain list of the things that will exist at the end that do not exist now. Files, pages, accounts, documents, a trained team member, a handover call.

Be concrete enough to be checkable. "Design system" is a category; "a Figma library with 22 components, documented, shared to your workspace" is a deliverable. The test is whether a third party could confirm you delivered it without asking your opinion.

5. Timeline — 80 to 120 words

Phases with dates, and — critically — what you need from them and by when. Most freelance overruns are client-side waits, and the timeline is where you make that visible before it becomes a grievance.

6. Price — 40 to 80 words

Short. A number, what it covers, the payment schedule, and what happens if scope changes. Do not justify it here; the justification was sections one to five. A price paragraph that argues with itself invites the reader to argue back.

7. The next step — 30 to 40 words

Exactly one action, with a date. "If this looks right, reply and I'll send the contract and an invoice for the first 50%. I'm holding the week of the 14th until Friday." Ambiguity at the end of a good proposal is the most expensive kind.

Restating the problem is the highest-leverage move you have

If you change one thing about how you write proposals, change this. Almost every freelancer summarises the brief. Very few restate it in a way that adds something.

The difference is that a summary repeats what you were told, while a restatement shows what you noticed. Compare:

You are looking for a new website for your consultancy, with a modern design and a blog, to be completed before the end of the quarter.

Your site was built for a two-person consultancy and you now have nine people and three service lines it cannot describe. The immediate pressure is the September conference, where your team will hand out cards with a URL on them. The blog matters less than the services pages, because the problem you described — "people arrive knowing our name and leave not knowing what we sell" — happens before anyone reaches a blog.

The second version has not made a single promise yet, and it is already more persuasive than most complete proposals. It reproduces the client's own sentence, identifies the real deadline, and quietly reprioritises the work with a reason the client can agree or disagree with.

That last part matters. A good restatement is falsifiable — it says something the client could correct. Sections that cannot be wrong cannot be right either.

Scope: the included, excluded and change-request split

Scope disputes are the leading cause of freelance projects that end badly, and they almost never start as disputes. They start as a small favour, then another, and then a conversation about why the project is three weeks late that neither party enjoys.

The fix is structural. Split the scope section into three explicit lists rather than one.

The excluded column is the one that saves the project.

Included

Concrete and countable. Not "design work" but "five page templates: home, services index, service detail, about, contact". Not "revisions" but "two rounds of revisions per template, collected as a single consolidated set of comments each round".

Numbers are what make this section function. Anything unbounded — pages, rounds, meetings, integrations — will be tested at some point in every project, usually by a well-meaning person who does not realise they are testing it.

Excluded

This is the column freelancers leave out because it feels negative. It is the one that saves you. Excluding something is not refusing it — it is saying it is a separate decision with its own price.

Example lines that earn their place in most projects:

• Copywriting — you supply final text for each page by the date in the timeline; I can quote separately if you would rather I wrote it.
• Photography, illustration and stock licensing.
• Migration of blog posts older than the current site.
• Third-party integrations beyond the two named above.
• Ongoing hosting, maintenance, plugin updates and security patching after handover.
• Support for Internet Explorer, or for browser versions older than the current two releases.
• Changes requested after the final round of revisions has been signed off.

Every one of those is something reasonable clients assume is included, right up until the moment they discover it is not. Reading a list like this at proposal stage costs the client thirty seconds. Discovering it in week five costs both of you the relationship.

Change requests

Say what happens when they want something outside the list, because they will, and because wanting it is legitimate. The mechanism matters more than the rate.

A version that works: "Anything outside the scope above is a change request. I'll estimate it in hours at my standard day rate, in writing, before starting — you can approve it, defer it to a second phase, or drop it. Nothing outside scope gets built without written approval, and nothing gets invoiced without it either."

That paragraph does two jobs at once. It protects your time, and it reassures the client that no surprise invoice can appear. Clients who have been burned by open-ended contractor billing find this genuinely comforting, which is not the reaction most freelancers expect from the scope section.

Presenting the price

Two decisions here: what the number is, and how many numbers there are. The first is a much larger subject and we have a separate guide on how much to charge as a freelancer. What follows is only about presentation.

One price or three options

A single price is the right default when the scope is genuinely settled and the client has told you their budget. It is clean, it is confident, and it does not invite a shopping conversation about a project you have already agreed the shape of.

Three options are useful when you are unsure of the budget, when the client has not decided how far they want to go, or when there is a version of the work that is obviously better but might be out of reach. Structure them as increasing scope, never as increasing quality — nobody wants to buy the version where you try less hard.

Our recommended shape, offered as judgement rather than a rule: a lean option that solves the stated problem, a middle option that solves it and removes the most likely follow-on problem, and a larger option that includes an ongoing element. Most clients pick the middle one, but the value of the exercise is not the tier they choose — it is that the conversation moves from "is this too expensive" to "which of these do we want", which is a much better conversation to be having.

Practical rules for the price paragraph

• Give a total, not a rate for project work. Hourly rates invite scrutiny of your speed rather than your outcome, and they punish you for being good.
• State the payment schedule in the same breath. A deposit before work starts is standard and you should not apologise for it — 50% up front and 50% on handover, or thirds across a longer project.
• Put an expiry on it. "Valid for 30 days" is normal commercial practice and prevents a proposal being accepted six months later at last year's rate.
• Never bury it. Hiding the number on page nine reads as embarrassment. It is the section they will find first regardless.
• Say what happens on late payment if you have been burned before. One sentence.

The timeline, and building in slippage honestly

Freelancers routinely quote the timeline in which everything goes right, then spend the project apologising for a world in which it did not. There is a better option than either optimism or padding you feel guilty about.

Quote in phases with dates, and attach the client's dependencies to each one. Something like: "Discovery, week of 3 March. Designs for review by 14 March — I need final copy for the services pages by 10 March. Build 17–28 March. Review and handover, week of 31 March."

Then add one honest sentence about how slippage works: "Each round of feedback that arrives more than three working days late moves the handover date by the same amount." This is not a threat; it is arithmetic, and stating it in advance converts every future delay from an argument into a shared fact.

Two more things worth doing. Build a real buffer — most people underestimate, so a week of contingency on a six-week project is prudence rather than padding, and you do not have to itemise it. And name your availability: if you are working three days a week on this, say so, because a client who assumes they have your Mondays will be unhappy in week two.

What to attach, and what not to

The instinct is to bulk out the document. Resist it. Every attachment is something the reader has to triage, and the ones that do not obviously help make the ones that do harder to find.

Attach, at most, two things:

• One relevant case study — not three, and specifically the one closest to their problem. This is the strongest single piece of evidence you own, and it is worth writing properly before you need it; how to write a portfolio case study has a skeleton with word budgets.
• A link to your portfolio, so the people you have not spoken to can form a view. If that link goes somewhere thin, fix the site before you send the next proposal — a freelance portfolio website that wins clients covers what belongs on it.

Do not attach a company profile, a methodology deck, a list of every technology you know, testimonials from unrelated sectors, or a page about your values. None of these answer a question the client is asking at this moment.

Send it as a PDF or a plain web page, not an editable document, and not a platform that requires an account to view. If a proposal tool sends you read notifications, use the information quietly — reading a proposal twice does not mean someone is about to say yes, and referencing it in a follow-up is unsettling.

What to cut

Almost every proposal that gets sent is too long, and the excess is remarkably consistent. Delete these:

• The introduction about your company. Nobody has ever been hired because their proposal opened with "Founded in 2019, we are a small studio passionate about…".
• The methodology section. Your five-stage process with named phases is interesting to you and invisible to them. Where a step matters, it belongs in the approach with a reason attached.
• The technology list. Unless the client asked, or the stack is a constraint they named, it is noise.
• Every testimonial except the most relevant one. Volume reads as insecurity.
• Adjectives about your own work. "Bespoke", "cutting-edge", "world-class", "seamless". They are unverifiable, which means a careful reader discounts everything near them.
• Duplicate versions of the price. One place, one number.
• The terms and conditions. Those belong in the contract that follows, not in the document meant to get you a yes.

A useful final pass: read the proposal and highlight every sentence that could appear unchanged in a proposal to a different client. If more than a quarter of the document is highlighted, it is a template with a name swapped in, and it will read like one.

When they go quiet

Silence after a proposal is normal and almost never means no. Budgets need approval, the person who has to sign is on leave, a fire started somewhere else. The freelancers who close more work are usually not the ones who write better proposals — they are the ones who follow up without embarrassment.

A sequence that works, offered as our practice rather than a law:

• Day 3 or 4. Short, useful, no pressure. Offer something rather than asking for something.
• Day 10. Reference the timing constraint honestly if there is one.
• Day 21. The closing note that makes it easy to say no.

Then stop, and put a reminder in the calendar for two months out. Proposals get revived far more often than people expect, usually when the trigger that started the search gets worse.

An example of the first message, kept deliberately short:

Hi Priya — no rush on the proposal. One thing I forgot to mention: the services-page structure I suggested is the same approach I used for the consultancy in the case study I attached, and their sales team ended up using the individual service pages as leave-behinds. Might be relevant to the conference. Happy to walk through any of it on a call if that is easier than reading it.

And the third, which is the one most people cannot bring themselves to send:

Hi Priya — I assume this has moved down the list, which is completely fine. I'll close the file for now so I'm not chasing you. If it comes back around, send me a line and I'll tell you honestly what my availability looks like then.

That message reliably produces a reply, because it removes the obligation. Sometimes the reply is "actually, can we talk this week".

Red flags that mean you should not write the proposal at all

Writing a proposal costs two to four hours of unpaid work. Some briefs are not worth that, and recognising them early is a skill worth developing.

• No budget indication after you asked twice. Sometimes genuine inexperience. Often a plan to collect numbers and go cheapest.
• "Just a rough idea of cost" with no call. They want a quote, not a proposal, and the specification does not exist yet. Offer a range and see whether a real conversation follows.
• An unmovable deadline that was already unrealistic when they set it. You will absorb the shortfall, then be blamed for it.
• Three previous freelancers who all "didn't get it". Ask what happened. Occasionally bad luck. Frequently a pattern with a single common element.
• The decision-maker will not join the call. You are writing for someone whose priorities you will only ever hear second-hand.
• Payment terms dictated before scope. A client leading with "we pay 60 days after project completion" is telling you how the whole engagement will go.
• Spec work. A request for designs, an audit or a sample "as part of the pitch". Declining costs you a small number of opportunities and a large amount of unpaid labour.

Declining is easier than it feels: "This one is not the right fit for me — the timeline and the budget do not quite meet. Happy to point you towards someone if that helps." Freelancers who decline clearly get referred by the clients they turned down more often than they expect.

A compressed worked example

Here is the skeleton filled in, shortened. The client and project are invented — the shape is the point, not the details.

The problem. Northfield Advisory's site was built when there were two of you and now describes about a third of what the firm does. The specific pressure is the trade conference on 22 September, where the team will hand out cards with the URL on them. In your words: "people arrive knowing our name and leave not knowing what we sell." The internal constraint is that the site runs on a CMS your operations manager knows and does not want to relearn.

Approach. Three moves. First, restructure around the three service lines rather than the current single "What we do" page, so a visitor who arrives interested in one thing lands on a page about that thing. Second, rebuild the templates inside your existing CMS rather than migrating — a migration would consume most of the available time and hand your operations manager a new tool eight weeks before your busiest quarter. Third, write the services pages last, once the structure is agreed, because the structure is where the confusion is and the copy inherits it.

Scope. Included: five page templates (home, services index, three service detail pages), responsive across current mobile and desktop browsers, two rounds of consolidated revisions per template, a one-hour handover session recorded for your team. Excluded: copywriting beyond editing what you supply, photography and stock licensing, migration of the pre-2023 blog archive, any change to the CRM integration, ongoing maintenance after handover. Changes: estimated in writing at my day rate before any work starts, approved by you or dropped.

Deliverables. Five live page templates in your CMS; a short written guide to editing them; the recorded handover session; source files for the two new diagrams.

Timeline. Structure agreed week of 4 August. Designs for review by 15 August — I need your service descriptions by 11 August. Build 18–29 August. Review, revisions and handover in the week of 1 September, leaving three weeks of margin before the conference. Feedback arriving more than three working days late moves the handover by the same amount.

Price. £6,400 for the scope above. 50% to book the August dates, 50% on handover. Valid for 30 days.

Next step. If this looks right, reply and I'll send the contract and the first invoice. I am holding the weeks of 18 August and 1 September until Friday the 25th.

That is roughly 480 words of proposal. Notice what it does not contain: no introduction about the freelancer, no methodology, no technology list, no adjectives. Every paragraph is either about the client's situation or about a commitment that can be checked.

Frequently asked questions

How long should a freelance proposal be?

Two pages for most freelance projects, or roughly 600 to 900 words plus one attached case study. Longer documents are common in agency work with procurement departments, but for an individual freelancer writing to a founder or a marketing lead, length reads as padding rather than thoroughness.

Should I use a freelance proposal template?

Use one for the structure — the seven parts above — and write the content fresh every time. The parts that can be templated are the scope exclusions, the change-request paragraph and the payment terms, which barely change between projects. The problem restatement and the approach cannot be templated, and they are the two sections that actually win the work.

What is the difference between a proposal and a statement of work?

A proposal is a persuasive document written to win the engagement. A statement of work is a contractual document, usually attached to or referenced by the contract, that defines deliverables, acceptance criteria, schedule and payment in binding terms. In practice a good proposal's scope and deliverables sections become the statement of work almost unchanged, which is a reason to write them precisely the first time.

Should I put the price in the proposal or wait until they ask?

Put it in. Withholding the price to force a conversation is a tactic that irritates buyers and delays the decision you want. If you are genuinely unsure of the budget, give a range with what each end includes, or offer the tiered options described above.

How many revision rounds should I include?

Two, defined as a single consolidated set of comments each — the definition matters more than the number. Unlimited revisions sound generous and reliably produce a worse project, because feedback with no cost attached arrives in fragments and never converges.

What do I do if the client asks me to lower the price?

Reduce the scope rather than the rate. "I can do it for that by dropping the two service detail pages to a single combined page and one revision round" keeps your pricing intact and gives them a real choice. Discounting the same work teaches the client that your first number was not serious.

Do I need a contract if I have a signed proposal?

Yes. A proposal is written to persuade; a contract exists to be read when something has gone wrong. They cover different things — intellectual property transfer, liability, termination, late payment, confidentiality — and an accepted proposal on its own leaves most of those undefined. Get proper advice on the contract for the jurisdiction you work in.

---

How we put this guide together

Bunfolio builds portfolio sites for freelancers, so most of what we see is the stage just before a proposal — the enquiry that arrives because someone read a case study, and the follow-up conversation it starts. The structure above reflects that vantage point and the consistent pattern in what buyers say they were looking for when they chose one freelancer over another: a demonstration that the problem was understood, and a clear boundary around what was being bought.

The length budgets, the seven-part order and the follow-up sequence are our recommendations, calibrated to what freelancers actually finish and send rather than to any external standard. The worked example is invented; it is there to show the shape of a proposal, not to report on a real engagement.

We have deliberately not quoted close rates, win rates or "proposals with X are Y times more likely to convert" figures. Numbers of that kind circulate widely on this topic and almost none of them trace back to an identifiable study of freelance proposals — repeating them would make this guide less trustworthy rather than more. Where we make a claim about what works, it is presented as our judgement so you can weigh it as such. On the commercial side — contracts, payment terms, tax treatment — take advice from someone qualified in your own jurisdiction rather than from a blog post.

Related reading: how much to charge as a freelancer, getting your first freelance clients, and building a freelance portfolio website that wins clients.