What to include in a freelance proposal: the complete guide

"What should a freelance proposal include" is one of the most-asked questions in this trade, so here is the answer, in full, with nothing held back.

Seven parts. Their situation, restated in their language. The scope, including what is not in it. The deliverables, described precisely enough that "done" is not arguable. The schedule. The price. The terms: deposit, payment points, what happens if feedback stalls. And a way to say yes that takes one action.

That took forty seconds and it is the least useful true thing anyone can tell you about proposals, because every guide on the first page of results gives you the same list and freelancers keep losing work anyway. The list is not where proposals go wrong. What follows is the part underneath it: who is actually reading the document, what to take out of it, and where those confident close-rate percentages you keep being quoted actually come from.

Not a pitch, and not a contract

Three documents get muddled here and the muddle is expensive.

A pitch shows speculative creative work. Don't send one. The canonical ending to that story circulates in every designers' forum in some version, and one thread has it verbatim: free concepts handed over, followed by "thank you for the idea. My nephew has Photoshop, and he'll take it from here." Giving away the thinking teaches the buyer that the thinking is the free part.

A contract carries the legal terms: liability, ownership, termination, what happens if either side walks. That comes after the yes, and the clauses that earn their place are a separate subject.

A proposal is a written offer: their problem, your solution, what it costs, when it lands. That is the whole genre. Keeping the three apart is dull administrative hygiene and it prevents a specific, common disaster, which is a document that reads as a legal instrument to a buyer who was expecting an answer.

A proposal is a conversation that can be forwarded

Here is the thing that changes how the document should be written, and I have not found it stated in any of the guides currently ranking on this query.

Your proposal has two readers. The first is the person you spoke to, who already likes you, remembers the call, and needs the document mostly as a receipt for a decision they have half made. Almost every proposal ever written is written for this person. They are not the problem.

The second reader was not on the call. They are a business partner, a finance person, a board member, a spouse. They receive your document as a forwarded attachment with about nine words of context above it, usually "what do you think about this?" They have no idea who you are, they did not hear you be impressive, and they are deciding in the time it takes to scroll.

Everything difficult about proposal writing follows from that second reader existing. It is why the opening paragraph has to restate their situation rather than introduce you: the second reader needs to know, in one paragraph, that whoever wrote this understood the problem. It is why the price has to be findable in five seconds without reading anything above it. It is why "as we discussed" is a trap — the second reader did not discuss anything with you, and every reference to a conversation they were not part of quietly marks them as an outsider to a decision they are being asked to approve.

There is a cheap test for this. Put the opening paragraph and the price on one page, hide everything else, and hand it to somebody who knows nothing about the project. Ask them two things: what is this company trying to do, and does that number appear to be attached to it. If they can answer both, the document will survive being forwarded. If they cannot, no amount of craft further down the page will rescue it, because further down the page is exactly where the second reader stopped.

Write for the person who was not there. The person who was there will forgive you.

The seven parts, and what each one is actually for

Their situation. Their words, from your notes, before anything about you. If you took the call properly you have phrasings you could not have invented: the specific complaint, the deadline nobody wants to say out loud, the competitor who keeps coming up. Use them. This paragraph is doing one job and it is not flattery: it is proving comprehension to a reader who has no other evidence of it. Getting that material out of the call is upstream work, and it is the reason good proposals feel effortless and bad ones feel like forms.

The scope, with its exclusions. The included half is easy. The excluded half is the one that saves you, and it should name the tempting adjacent things specifically rather than generically: not "additional work is out of scope" but the actual list. Copywriting. Photography. Migrating the old blog. The exclusions are also a comprehension signal, because listing the right adjacent things proves you know what this kind of project usually swallows. Plutio's guide has a useful test for whether a scope line is written well enough. They call it the done test, and it asks whether both parties would agree the item is finished without needing a conversation about it. Steal it.

Deliverables. Formats, quantities, and what completion means. "Brand identity" is not a deliverable. "A primary wordmark, one stacked lockup, and a two-page usage sheet, supplied as vector files" is one.

The schedule. Dates, and the dependency almost everyone omits: what the timeline assumes about their feedback. A schedule that does not say "this assumes feedback within three working days" is a schedule you will be blamed for missing.

The price. One number per option. Findable without scrolling past your biography.

The terms. Deposit, payment points, what happens when a stage stalls. Two or three lines, in plain sentences.

A way to say yes. One action, described in one sentence. Not "let me know your thoughts," which is an invitation to have thoughts.

The proposal you write without a call

Sometimes there was no call. An enquiry form arrives with three sentences in it. A marketplace brief goes up and forty people answer it. A public tender lands with a submission deadline and a rule against contacting anyone before it.

A proposal written without a conversation is a guess with formatting on it. The scope is guessed, the price is guessed, and the one paragraph that does the real work has nothing to restate, because nobody told you anything. Sending a full document anyway feels productive and mostly is not.

So write a different, much shorter document, and give it one job: buy the conversation. Name what you think the problem is and say openly that you are inferring it. One short paragraph on how you would approach it. Then a bracket rather than a price, phrased so that correcting you is the natural response — work of this shape usually lands in a range, the range depends on two or three things you cannot know yet, and twenty minutes on a call settles which end. A bracket gives them something to respond to. A precise number invented from nothing usually gets no reply at all.

When the rules genuinely forbid a conversation, price defensively and write your assumptions down as assumptions, numbered, in the document. Every assumption you record is a change order later. Every one you leave in your head is your problem later. It is a dull piece of admin and it has saved more money than most of the advice on this page.

One thing worth saying plainly about the marketplaces. Their ranking systems reward responding to a great many briefs quickly, which is an incentive to send weak proposals in volume. That is the platform's economics, not a professional standard, and it is worth knowing which one you are obeying when you send the fortieth.

What to cut, in order

Most proposals are too long, and they are too long in a predictable order, so cut in that order.

Your process diagram. Nobody has ever bought anything because of a five-stage arc with arrows. It tells the buyer you have a method, which they assumed, and it costs a page.

Your company backstory. You are one person. Founded-in language on a solo proposal reads as costume.

Your client list, if it is doing decoration rather than work. A logo wall convinces nobody who was not already convinced. One relevant sentence about one relevant project beats twelve badges.

Your credentials, down to almost nothing. There is a Hacker News answer I think about a lot, from someone asked what they charge for machine-learning consulting. The reply, in full: "250. Never had a client tell me it was too much. East Coast. PhD." Fourteen words, three of them credentials, and more persuasive than any capabilities deck. Confidence takes up very little room on a page. Padding is what uncertainty looks like in a document.

What survives: their situation, the scope line, the numbers, the dates, and the way to accept. A correctly cut proposal is shorter than the one you started with and does better, which is counterintuitive until you have watched a few of them get forwarded.

The parts-list problem

Here is where I disagree with most of the well-ranked advice on this query, including the guide I recommended a test from two sections ago.

The common recommendation is to itemise: every deliverable, its own line, its own price. It looks transparent. What it actually does is hand the buyer a shopping list, and a shopping list invites removals. The moment a price sits on its own line next to "usage guidelines," you are going to spend a call explaining why the usage guidelines are not optional, and you will lose some of those calls, and the project that ships will be the worse for it.

Detail and itemisation are not the same thing. Describe everything the bundle contains, exhaustively, in prose or bullets. Attach one price to the bundle. If the buyer needs a cheaper way in, give them a smaller bundle that is genuinely a smaller job: three tiers, walked through with the arithmetic on the page, not the same job with pieces sawn off.

About the close rates you will be quoted

You will read, in more than one place, that the average freelance proposal closes at 43%, a figure credited to Proposify that is not from any Proposify report. It is worth knowing what happened there, because it is a good illustration of how a number travels.

Proposify does publish real data, and quite a lot of it. Their State of Proposals 2024 reports an average close rate of 36% across 1,280,657 proposals in 27 industries, with an average closed deal of $13,656. The 2026 edition reports 34% across 742,137 proposals in 30 industries. Those are large samples and there is no reason to doubt them.

Two problems. The circulating figure is not from either report; it has been attached to Proposify's name somewhere along the chain and repeated since. And more importantly, the population is businesses using a B2B sales-proposal tool, most of them sales teams at companies, and it is not freelancers. Nobody is measuring freelance proposal outcomes. There is no register, no sampling frame, and no mechanism by which anyone could know.

Which matters beyond pedantry. Freelance work has enough sources of self-doubt without an imported figure from somebody else's industry setting the pass mark. Track your own rate over a year and compare it to itself.

One number from those reports is genuinely useful, though. The gap between a buyer first opening a proposal and the deal closing runs at about two and a half days in the 2026 report, and 51 hours in the 2024 one. Whatever else is true, the decision happens fast once the document is open. The usual advice to follow up after a week or two is calibrated to the wrong clock. Better than any cadence: put the next conversation in both diaries before you send anything, which turns the follow-up into an appointment instead of an act of nerve.

North drafts the document itself from your call notes — the restatement, the scope line and its exclusions, the priced options, the dates — and leaves you to edit and send it. If you would rather build your own, the blank version of this structure has the sections and none of the padding.

Write the first paragraph for someone who was not on the call. If that paragraph works, the rest is admin.