The Winning Proposal Structure

A 5-part framework that works consistently — with a full worked example.

The 5-part structure

Proposals that get replies follow a consistent arc. Not because there's a magic formula, but because this structure answers the three questions every client is asking — in the right order. For the background on those questions, see Proposal Fundamentals.

Part 1: The hook (2–3 sentences)

Reference something specific from the job post — a detail, a goal, a constraint they mentioned. This is the only part of the proposal the client sees in the list view before clicking. It must be about them, not you.

The strong opener works because it names their specific situation (checkout flow, Q2 launch), references a detail they included (Stripe), and signals relevant experience — all in two sentences.

Part 2: The plan (3–4 bullet points)

Show them briefly how you'd approach the work. This isn't a full spec — it's enough to prove you've thought about it. A freelancer with a plan is less risky than one who says "just tell me what you need."

• Week 1: Discovery call + scope confirmation in writing
• Week 2–3: Build and internal QA
• Week 4: Client review round + revisions
• Week 5: Final handover with documentation

Adjust this to your niche. A content writer might say "Day 1: outline for approval — Day 3: first draft — Day 5: revisions and final." The point is to show a process, not to lock in every detail upfront.

Part 3: Proof (1–2 sentences + attachment)

One relevant result with a number. Numbers make proof concrete. "I have experience with similar projects" is not proof. "I rebuilt the payment flow for a fintech client — their checkout completion rate improved by 18%" is proof.

Attach one relevant portfolio piece. Not five — one. The most relevant thing you have. If it's not perfectly on-topic, note the connection explicitly: "This is a different product category but the same architectural challenge you're describing."

Part 4: Deliverables and timeline (1–2 sentences)

Be specific. "I can deliver a working prototype in 10 days and the final build in 3 weeks, with a 2-week QA buffer built in." That's more trustworthy than "I can finish this quickly" or "delivery time depends on scope." Specificity signals that you've actually thought about the work.

Part 5: The CTA (1 sentence)

"Let me know if you have questions" is too passive — it puts all action on the client. Instead, make it easy for them to take a specific next step.

• "Happy to do a 15-minute call this week to confirm scope before we start."
• "What's the one thing that matters most to you on this project?"
• "I can send you the relevant case study from a similar project — want me to?"

A question at the end invites a reply. A statement that ends with "looking forward to hearing from you" does not.

Full worked example

Here's a realistic job post followed by a proposal applying all 5 parts:

Job post

Rebuild checkout flow — React + Stripe

We're a SaaS company with a 3-year-old checkout built on an outdated React codebase.
It doesn't work properly on mobile and we're losing conversions. We need it rebuilt
from scratch using React 18 + Stripe Elements, with a clean handover including
documentation. Must be done by end of April (we have a big campaign launching May 1).

Budget: $3,000–5,000
Looking for someone with Stripe experience who can work independently.

Proposal applying the 5-part structure

Your checkout is leaking conversions on mobile — I've fixed this exact problem for two
SaaS companies. One was also on an aging React codebase with Stripe; after rebuilding
with React 18 + Stripe Elements, their mobile checkout completion rate went from 51%
to 74%.

Here's how I'd approach this:
- Week 1: Audit the existing flow, agree on component structure, set up dev environment
- Week 2–3: Build and test the new checkout across devices (iPhone, Android, tablet)
- Week 4: QA round with your team + accessibility check
- End of April: Final handover with documented component library

I'm attaching the case study from the fintech rebuild — same stack, different product.

I can have a prototype live in 2 weeks and the final build done by April 25, which gives
you a buffer before May 1.

Would it help to do a 20-minute call this week to confirm scope and make sure I've
understood the existing codebase's constraints?

Answering screening questions

Upwork lets clients add up to 5 screening questions to a job post. Treat these seriously — clients who add questions are specifically watching to see who answers them. Ignoring a question or burying it at the end of a long proposal is an immediate red flag.

Answer screening questions honestly and briefly. If a question is already answered in your proposal, you can say "covered above" rather than repeating yourself — but only if it's genuinely covered, not just adjacent to it.

For a post with the question "Have you worked with Stripe's PaymentIntents API?": don't write two paragraphs about your payment experience. Answer in one sentence — "Yes, I used PaymentIntents on the fintech rebuild I mentioned — happy to walk through how I structured it on a call." That's it.

For common reasons proposals fail despite having a good structure, see Why Proposals Fail. For how to build a reusable template around this structure, see Proposal Templates.