freelance_proposal_writing v1.0.0

name: freelance_proposal_writing description: "Writing freelance proposals that win marketplace and direct client work: read the post for the real problem and the hidden instructions, open on the client outcome in the lines the client sees first, place one piece of quantified proof, frame scope with what is in and what is out, price hourly or fixed with milestones, and run a review pass before sending. Use when drafting or reviewing a proposal or bid on Upwork, Fiverr, or any marketplace, replying to a client brief, or turning a short inquiry into a proposal a client can approve. For formal RFP responses use rfp-responder, for turning an accepted estimate into a contract-ready scope use estimate-to-sow, for job application cover letters use cover-letter-writing." metadata: { "version": "1.0.0" }

Freelance Proposal Writing

Purpose

A proposal has one job: get the client to start a conversation or click approve. It is not a resume, not a portfolio dump, and not a contract. Clients read many proposals in a row and decide fast, often from the first lines alone. Upwork's own guidance makes the same point in platform terms: clients first see only the opening lines of the cover letter next to the profile, rate, and badges, and a length of about 200 to 300 words or fewer fits most marketplace projects.

This skill covers two forms with one method. The short form is a marketplace bid: a tight cover letter plus the platform fields for rate, duration, and screening answers. The long form is a direct proposal sent to a client off a brief or a call: the same core, expanded with a full scope, options, timeline, and terms. The method is platform neutral. It works on any marketplace and for direct clients, because it starts from the client's problem, not from one site's form.

Workflow

1. Decide whether to bid at all, before writing a word.

• Check fit first: can you name the deliverable, do you have one relevant proof item, and can you meet the stated deadline with room to spare. If any answer is no, pass or ask a clarifying question instead of bidding.
• Check the client where the platform allows it: hiring history, past feedback from other freelancers, and whether payment is verified. Patterns of harsh feedback or no hires at all are information, not insults to ignore.
• Check the economics: platform fee, your time to write the bid, and whether the budget can hold a fair price for the scope as written. Bidding below a viable price to win, then renegotiating later, burns the relationship and the review.
• A clean pass is a good outcome. Proposal credits, connects, and time are finite on most marketplaces.

1. Read the post for the real problem, in three passes.

• Pass one, the stated ask: the deliverable, quantity, format, deadline, budget shape, and any required skills or tools. Copy these into notes in the client's own words.
• Pass two, the outcome behind the ask: what changes for the client when this work lands. A request for four blog posts is usually a request for traffic, leads, or a launch that does not stall. Name the outcome in one sentence. If you cannot, the post is too vague to price fixed, so propose a small paid discovery step or ask.
• Pass three, the test hidden in the post: required words, questions that must be answered, files to attach, or instructions about how to apply. Follow them exactly. Clients use these to filter out bulk bids, and missing one ends the bid no matter how good the rest reads.
• Note tone and detail level. A short, blunt post earns a short, blunt proposal. A detailed post earns a structured one. Mirror the client, do not out-write them.

1. Build a proof shortlist before drafting.

• Pick one, at most two, proof items that match this problem: a similar deliverable, a similar industry, or a similar result. Relevance beats prestige. A small project in the client's trade outweighs a famous logo from a different trade.
• Write each proof item as work plus result, with a number you can stand behind: pieces delivered, time saved, a rate or score change, a deadline met. If you have no number, use a concrete fact: the format, the volume, the repeat client. Never invent a metric, a client name, or a result. If the work is under a confidentiality duty, describe the problem type and outcome without naming the client.
• If you have no direct match, say what transfers and offer a small relevant sample or a paid trial piece where the platform allows it. Honest adjacency beats a borrowed portfolio.

1. Draft the short form in this order. Target about 200 to 300 words for a marketplace cover letter, less for a simple job.

• Opening, one or two lines, on the client: restate the problem or outcome in the client's terms, with one specific detail from the post that a bulk bidder would not have. This is the text the client sees in the list, so it must carry the fit on its own. Do not open with your name, your years of experience, or a greeting that could be pasted into any bid.
• Proof, two or three lines: the matched proof item from step 3, with its number, plus a link or attachment where the platform allows it.
• Approach, two to four lines or short bullets: how you would do this job, in named steps with the first deliverable and when it arrives. Enough to show a plan, not the whole job done free in the bid.
• Scope and price frame, two or three lines: what the price covers, what it does not, and whether it is hourly or fixed. See step 6.
• Close, one line: one easy next step, a short call, a reply to one specific question, or a look at the attached sample. End with a question only if it is a real question you need answered to start.
• Answer every screening question separately and directly, in the same order the client asked. Short answers with the proof number repeated beat long general answers.

1. Expand to the long form only when the client or the job size calls for it.

• Add: a one paragraph summary of the problem and outcome, a scope section with countable deliverables (quantity, format, length or size, revision rounds), an out of scope list, a timeline with milestone dates rather than one end date, options if step 6 calls for them, and short terms: deposit, payment points, who owns the final files, cancellation, and how extra work gets quoted before it starts.
• Keep the long form skimmable: headings, bullets, and a price table if there are options. A client should be able to approve it from one read without asking what happens next. State that next step at the end: sign, pay the deposit, or book the kickoff.
• The full worked long form is in references/worked-proposals.md.

1. Frame scope and price so the client can say yes without a negotiation round.

• Scope first, price second. The price reads as fair or steep depending on the scope written above it. Every price line names what it buys.
• Write scope as in, out, and client supplies: what you deliver, what is not included (nearby work the client might assume, such as copy for a design job or maintenance after launch), and what the client must provide for the timeline to hold.
• Pick the pricing shape by certainty. Fixed price with milestones when the deliverable is clear and countable. Hourly with a weekly cap and a reporting rhythm when the work is open ended, diagnostic, or depends on the client's feedback speed. A small paid discovery or first milestone when the scope cannot be known yet, with the full price to follow from what discovery finds.
• Offer options only when there is a real scope choice: a core version, the core plus one valued extra, and a fuller version. One price is right for small defined jobs. Do not pad a middle tier with filler to make it look chosen.
• Split fixed price into milestones tied to deliverables the client can check, and state the deposit. On platforms with escrow style protection, confirm the milestone is funded before starting that stage. Upwork's payment protection, for example, covers fixed price work only on funded milestones, and hourly work only when time is tracked with the platform tool and proper memos. Check the current rule on the platform you are using, because protection terms and fees change.
• State your price once, plainly, with no apology and no fake discount. If the budget in the post is below your floor, either pass or bid your price with the scope that fits it, named clearly.

1. Run the review pass before sending. Use references/review-checklist.md and the checker.

• Run python3 scripts/proposal_qa.py check --file proposal.txt. A BLOCK stops the send: a generic opener with no client specific detail, no proof, no price or scope frame, a missing answer marker for screening questions, or text over the hard length ceiling. Warnings are judgment calls to fix or consciously accept.
• Read the first two lines alone. Could they belong to any other bid. If yes, rewrite them from the post notes.
• Read the whole draft against the post, line by line: every stated requirement answered, every hidden instruction followed, every number traceable to real work, every date one you can hit.
• Cut pass: remove any sentence that is only about you and does not connect to this client's problem. Most first drafts lose a third here and get stronger.
• Check names and details character by character: client name, company, product, and the deliverable names come from the post, not from memory or from the last bid you wrote.

1. Send, track, and follow up once with value.

• Log each bid: date, client, job, price shape, proof used, and outcome. Patterns only show up in a log. A trade, price band, or opening style that never gets replies is data, not bad luck.
• Follow up once, after a few days, only where the platform allows contact before hire, and only with something useful: a short answer to a risk in their post, a relevant sample, or a simple note that you can still meet the date. No guilt, no second follow up to silence.
• After a win, restate the agreed scope, price, milestones, and start date in the first message, and get the contract or funded milestone in place before work starts. After a loss with feedback, record the reason in the log and adjust the bid filter in step 1, not just the wording.

Output Contract

Each proposal job produces:

• A bid decision note: fit, client check, economics, and the bid or pass call with the reason in one line.
• Post notes: the stated ask, the outcome sentence, the hidden instructions, and the tone to mirror, in the client's own key words.
• The proposal itself: short form at about 200 to 300 words, or the long form with scope, out of scope, milestones, options where they fit, terms, and the approval step.
• A proof line that names the matched work and a true number or concrete fact, with a link or attachment where allowed.
• The QA record: checker output, the requirement by requirement read, and what was cut in the review pass.
• A log entry for the bid and, later, its outcome.

Operating Rules

• Never invent proof: no made up clients, metrics, testimonials, or portfolio pieces, and no samples passed off as client work when they are personal projects. Label personal work as personal work.
• Never copy a past proposal and swap the names. Reuse structure and proof lines, rewrite the opening, approach, and scope from this post every time.
• Never do the job in the bid. Show the plan and the first step. Full audits, full drafts, and complete solutions given free in a proposal train clients to harvest bids instead of hiring.
• Never promise a date you have not checked against your current load, and never bid a scope you would resent at the price you named.
• Never move a new client off the platform in a way that breaks that platform's terms, and never start unfunded work where protection depends on funding. When in doubt, keep the contract and payment where the protection is.
• Never bad mouth other freelancers, the client's past hires, or the client's current materials beyond one factual, fixable observation tied to the job.
• Keep the client's post details and materials private. Do not reuse one client's brief, files, or results as proof for another client without permission.
• If the post asks for work that is deceptive, such as fake reviews, undisclosed sponsored content presented as personal opinion, or homework or credentials fraud, do not bid. A polite pass costs nothing.
• Price and terms belong in the proposal, not in a follow up after interest cools. A client who cannot see what approval commits them to will delay or dispute later.
• Length is a feature. If a draft passes 300 words for a simple marketplace job, the extra words must earn their place in the review pass or come out.