How to structure project proposals

A proposal is not a sales document. It is a shared understanding document. Its job is to create agreement on scope, timeline, price, and expectations — before work begins.

Bad proposals fail because they sell rather than clarify. They list features and benefits while avoiding specifics. The client approves because the proposal sounds good, not because they understood what they were buying. This leads to the most common project problems: scope creep, renegotiation, and late payments.

A good proposal is one the client can reread at any point in the project and understand exactly what was agreed. If your proposals have ever generated the question "I thought you were including X" — the structure in this guide will fix that.

1. Problem summary One to three sentences describing the client's actual problem — in their language, not yours. Restating their problem back to them confirms you listened and understood.

2. Recommended approach A plain-language description of what you will do. Not how you'll do it technically — what you'll deliver and why this approach solves the problem. Avoid jargon here.

3. Scope and deliverables Two lists: what is included and what is explicitly excluded. The exclusion list is just as important as the inclusion list. Every "not included" item is a future conversation you won't have to have.

4. Timeline A milestone table. Three to five milestones with target dates. Do not pad this — realistic dates build trust. If you're unsure, add an explicit buffer and note it.

5. Investment Price, payment terms, and what triggers each payment. Never hide the price at the end of a long document. If the budget is misaligned, better to know in the first read.

6. Acceptance A signature block or a clear instruction for how to approve. Proposals without a clear approval mechanism stay in "review" indefinitely.

The problem statement is the paragraph clients read most carefully, because it's about them.

Write it by completing these three sentences:

1. "Currently, [client/team/process] does X manually..." or "Currently, [client] does not have a way to..."
2. "This means that [specific consequence: time lost, revenue missed, errors introduced]..."
3. "This project will [the change]."

Example:

Currently, your sales team manually copies lead data from your contact form into HubSpot every morning, which takes 20–30 minutes per day and occasionally introduces duplicates or missing fields. This means your team is losing selling time and your CRM data is unreliable. This project will automate the transfer so new leads appear in HubSpot within 60 seconds of form submission, with deduplication and validation built in.

That is a problem statement that makes a client feel understood. It is also the standard the rest of the project will be held to.

The most effective time to address scope creep is in the proposal, before the project begins.

Do this by:

Being specific about deliverables. Not "automation setup" but "a single Zapier workflow connecting [Form] to [CRM] with the steps defined above."

Being explicit about what's excluded. List the top two or three things clients often assume are included: "This does not include data migration of existing records," "This does not include training," "This does not include post-delivery changes."

Defining the revision process. How many rounds of feedback are included? What triggers a change order? If you don't write this, the client will assume unlimited revisions.

Setting a response SLA for blockers. If the project depends on the client providing access or information, specify that delays caused by late responses will extend the timeline accordingly.

Proposals die or survive on how the price is presented, not just what the price is.

Principles that work:

• Anchor with value before price. The investment section should appear after you've described the outcome, not at the top. Let them read what they're buying first.
• Be specific about payment terms. "50% due on signing, 50% due on delivery" is better than "payment due on completion." Vague terms get disputed.
• Offer one price, not three tiers. Multiple packages look flexible but create decision paralysis. If you want to offer options, offer two at most, and make the default obvious.
• Never bury the total. Put the total in bold, on its own line, early in the investment section. Hiding it signals you're not confident in it.

If the client pushes back on price, the correct response is a scope reduction offer — not a discount. "I can do X at [lower price] if we remove Y" preserves your rate and opens a productive conversation.