How to structure a freelance proposal

Try SpecBot free — keep your proposal structure in your offers and send it for one-click acceptance.

The structure of your proposal determines whether the client can make a decision. A proposal that buries pricing at the end, hides the scope in dense paragraphs, or leads with your credentials instead of their problem — these structural mistakes cost deals before the client even gets to evaluating your price.

Good proposal structure makes it easy for the client to find the information they need, in the order they need it. Here’s exactly how to structure a winning freelance proposal, section by section.

The right order matters more than you think

Clients don’t read proposals linearly from top to bottom the first time. They scan. They jump to pricing. They check the timeline. Then they go back and read the executive summary.

Your structure should work for both:

1. The client who scans in a non-linear order
2. The client who reads start to finish

The way to do both: structure each section so it can be understood independently, while also telling a coherent story from start to finish.

Here’s the structure that does this:

1. Executive summary
2. Scope of work
3. Deliverables
4. Timeline
5. Investment (pricing)
6. Assumptions
7. Next steps
8. About / credentials (optional — keep it short)

Section 1: Executive summary

What it is: A 2-4 paragraph overview that demonstrates you understand the client’s situation, goals, and what you’re proposing.

What it is NOT: Your introduction. It’s not “we are pleased to submit this proposal.” It’s not a list of what you’re going to do. It’s a summary of the client’s situation and how your work addresses it.

Why it’s first: Clients need to know immediately that they’re reading a proposal that understands their specific problem — not a generic document with their name swapped in.

What to include:

• What you understand about the client’s current situation and challenge
• What they’re trying to achieve (the business goal, not just the project task)
• What you’re proposing and why this approach
• Expected outcome (what success looks like)

Example opening (from a web design proposal):

“Meridian Consulting’s current website doesn’t reflect the quality of work you do or the clients you serve. Prospective clients checking you out after a referral are landing on a site that looks older than your portfolio and doesn’t make a clear case for why you’re the right firm.”

This is specific, honest, and shows you paid attention during the discovery call. It’s far stronger than “We are excited to present this proposal for your website redesign project.”

Keep it to 2-4 paragraphs. If your summary is longer, something from the body sections has crept in here.

Section 2: Scope of work

What it is: A precise definition of what work this project includes and what it doesn’t.

Why it’s the most important section: The scope of work is what you’ll be held to. Ambiguous scope = scope creep. Scope creep = working for free.

Structure:

What’s included:

• Specific deliverables with quantities, formats, and constraints
• Number of iterations/revisions
• Who does what (who provides content? who handles technical setup?)

What’s explicitly excluded: This part is as important as the inclusions. State clearly what you’re not doing:

• Copywriting (if not in scope)
• Photography
• SEO optimization
• Additional pages beyond those listed
• Ongoing maintenance after launch

Write exclusions as if the client assumes everything is included. Because they often do.

Example scope language:

Included: Design of 6 website pages (home, about, services, case studies, blog template, contact). Mobile responsive. Two design concept directions presented; one selected for refinement. Two rounds of revisions on the selected direction.

Not included: Copywriting for any pages (client provides all text). Photography or stock images. Logo design. WordPress plugin development or custom code beyond standard theme functionality. Ongoing maintenance after site launch. Any pages beyond those listed above.

Section 3: Deliverables

What it is: A concrete list of what the client receives, in what format, by when.

The difference from scope: Scope defines what work is included. Deliverables define what physical outputs the client receives.

Be specific:

• Not “website files” → “Final WordPress theme files, child theme folder, and exported database backup”
• Not “logo” → “Primary logo, secondary logo, icon mark, all in SVG, PNG (transparent), and PDF”
• Not “report” → “Monthly performance report as PDF, covering organic traffic, keyword rankings, and backlink growth”

Section 4: Timeline

What it is: A phase-by-phase breakdown of when things happen, with dates.

Use actual dates, not just “Week 1, Week 2.” A timeline that says “Week 1: Discovery” is harder to hold anyone to than “Week of March 10: Discovery and wireframes.” Actual dates create accountability.

Include review windows: The timeline should show not just when you deliver, but when the client needs to respond. “Client review: 5 business days” makes the client’s responsibility clear.

Add a dependency note: “This timeline assumes client provides [content/access/feedback] within the windows above. Delays push all subsequent phases.”

Example structure:

Section 5: Investment (pricing)

Why it’s called “investment” not “cost”: “Investment” frames the money as something that generates returns. “Cost” frames it as an expense. Word choice matters.

Structure your pricing, don’t just quote a number:

Include payment schedule: Don’t just state the total. State when and how each payment is due.

• Project-based: 50% upfront, 50% on delivery (or 50/25/25 for longer projects)
• Retainer: Monthly, invoiced on [date], Net 7

Address budget conversations: If you know the client has budget concerns, acknowledge them here. “If the full scope is above your current budget, I can suggest priority phases.”

Section 6: Assumptions

What it is: A list of things you’re assuming to be true that, if they turn out not to be true, would affect the scope, timeline, or price.

This section protects you legally and practically. It’s not about covering your ass — it’s about making clear what the project is based on.

Common assumptions:

• Client provides all content (copy, images) by [date]
• Client provides admin access to [platform] within [X] days of signing
• Timeline assumes [X] business day feedback windows are honored
• Scope is based on [X pages / X hours / the requirements described above] — changes in scope require a revised proposal
• Third-party costs (hosting, plugins, fonts, tools) are not included unless stated

Keep it readable: Use a bulleted list. Dense paragraphs in an assumptions section don’t get read.

Section 7: Next steps

What it is: One clear action the client needs to take to move forward.

The mistake to avoid: Listing multiple next steps. “Sign the agreement, submit the deposit, schedule a kickoff call, and send us access to your accounts.” This creates decision fatigue.

The right approach: One primary action.

“To proceed, sign the proposal below and submit a 50% deposit of $[X]. I’ll follow up with your kickoff call invite and onboarding checklist within 24 hours.”

Include a clear approval mechanism. Whether it’s an electronic signature in your proposal tool, a DocuSign link, or a written reply, make the approval path frictionless.

Section 8: About / credentials (optional)

Keep this short. A 2-3 sentence bio and 1-2 brief client references or case studies is enough. Clients don’t want to read your resume — they want to know if you can solve their problem. The executive summary already started to answer that.

If you have highly relevant past work, mention it briefly:

“I’ve done similar work for [comparable client type]. [Outcome in one sentence]. References available on request.”

Don’t put this section first. The most common structural mistake in freelance proposals is leading with credentials. The client cares about their project first. Credentials are supporting evidence, not the main event.

What to cut

Long about sections. If your “About” section is longer than your “Scope” section, something is wrong.

Generic company descriptions. “I am a passionate designer with 10 years of experience helping clients achieve their goals” — this is filler. Cut it.

Attachments. Case study PDFs, portfolio links, capability decks — rarely read. If you need to demonstrate expertise, do it in-line, in 2-3 sentences. Don’t attach a 20-page deck.

Legal boilerplate in the body. Your payment terms, IP ownership, and liability clauses belong in your contract, not your proposal. Keep the proposal focused on the project.

Start free on SpecBot — SpecBot turns your offers into proposals clients accept in one click, with a signed PDF for both sides. Free is 3 proposals a month with every feature; Pro is unlimited proposals at €12/month, or €9/month billed yearly. Write them in the web app, by voice, or inside ChatGPT and Claude.