Proposal Writing Rules

A proposal wins by proving you understood the client's actual problem before it proves anything about your capability to solve it — a client who feels understood in the first paragraph reads the rest of the proposal charitably; one who doesn't stops reading regardless of how good the solution section is.

Client's problem in their words first

• Open by restating the client's problem using their own language and framing — pulled from the discovery call, the RFP, or their own materials — not your reframed version of it. Seeing their own words reflected back is what signals "they get it" before you've proposed anything.
• State the cost of the problem in terms the client already cares about (lost revenue, wasted hours, a missed deadline, a competitive gap), not in generic terms — "your support team is spending 20+ hours a week on tickets this would eliminate" lands harder than "this is an efficiency opportunity."
• Resist opening with your company, your credentials, or your process — that's proof of capability, and it belongs after the client sees you understand their situation, not before.

Scope with explicit exclusions

• Define exactly what's included as specifically as the engagement allows — deliverables, number of revisions, timeline, channels or platforms covered — vague scope ("website redesign") is the single biggest source of scope-creep disputes later.
• Include an explicit "Out of scope" or "Not included" list alongside the scope of work, even for things that seem obviously excluded — this is the section that protects both sides when the client later asks "can you also just quickly..."
• State what happens when the client wants something outside scope (a change-order process, a rate for additional work) so there's a pre-agreed mechanism rather than an awkward negotiation mid-project.

Options with a recommended one

• Where the engagement allows it, present 2-3 options (e.g., a lean/standard/comprehensive tier) rather than a single take-it-or-leave-it package — options let the client feel in control of the decision and increase the odds of a yes at some tier rather than a flat no.
• Mark one option as the recommended choice, explicitly, with a one-line reason — an unranked list of options makes the client do analysis work that a confident vendor should have already done for them.
• Keep the option count small. More than three tends to create decision paralysis rather than more conversions, and dilutes the case for the recommended one.

Pricing presentation

• Present price after value and scope are established, never before — a number without context primes the reader to evaluate it against nothing, usually unfavorably.
• Be specific about what the price includes and, ideally, tie line items back to scope so the client can see what they're paying for rather than facing one undifferentiated total.
• State payment terms explicitly (deposit, milestones, net terms) in the proposal itself — leaving this for a separate contract conversation later adds friction right when the client is ready to say yes.
• Avoid false-urgency pricing tactics (fake expiring discounts, "today only" framing) in professional B2B proposals — they read as manipulative to sophisticated buyers and can undermine trust built up in the rest of the document.

Next-step close

• End with one specific, low-friction next step — "Reply to confirm and I'll send the contract," "Book a 15-minute call this week to finalize scope" — not a vague "Let me know if you have questions."
• Give the proposal a validity window ("This proposal is valid through [date]") so it creates gentle urgency without resorting to manipulative tactics, and so pricing doesn't stay open-ended indefinitely.
• Make responding as easy as possible — a single link, a single reply, a single signature — every extra step between "convinced" and "confirmed" is a chance for momentum to be lost.

What to avoid

• Don't lead with a generic capability overview or company history before addressing the client's specific situation — a proposal that could be sent to any client unchanged has already signaled it wasn't written for this one.
• Don't leave scope boundaries implicit to seem more accommodating — an under-specified scope reads as flexible in the moment and becomes a dispute later; specificity protects the relationship, not just the vendor.
• Don't bury the price or make the client hunt for it — obscuring cost doesn't make a proposal more likely to be accepted, it just makes the client feel like something's being hidden.