Structuring a Long Proposal So It Gets Read
Why this matters
A big proposal, a multi-phase commercial job, a whole-property retrofit, a service contract with several tiers, is competing with the reader's inbox, not just their attention. If the structure forces them to hunt for the price, the timeline, or what they are actually agreeing to, they either bounce off it or come back with the wrong questions because they misread the scope. A proposal that loses on structure loses jobs that would have won on merit.
Lead with a one-page summary, even in a long document
The single biggest mistake in long proposals is making the reader dig for the answer before giving them the summary. Put the essentials on the first page, before any detail:
- What you are proposing, in one or two sentences
- The total price or price range
- The timeline
- The key deliverable or outcome
A decision-maker often reads only this page in full and skims the rest. If the summary is buried on page four, most readers never reach it with full attention. Everything after the summary exists to support and justify what the summary already said, not to build up to it.
Order the body by what the reader decides on, not by your workflow
Shops often structure proposals in the order they did the thinking: site visit notes, then materials research, then labor estimate, then price. That order makes sense to the person who wrote it and almost nobody else. Structure instead around what the reader needs to evaluate, roughly in this order:
- The problem or goal, stated back to them so they know you understood the ask.
- The proposed solution, described in plain terms before the technical detail.
- Scope, specific about what is included and, just as important, what is excluded.
- Timeline, with real dates or a realistic range, and any dependency that could shift it.
- Price, broken into phases or line items if the job is large enough that a single number would be opaque.
- Terms, payment schedule, warranty, what happens if scope changes mid-job.
Use headers and short sections, not a wall of paragraphs
A proposal longer than a page needs navigation. Headers let the reader jump straight to the section they care about on a second read, price and timeline for the decision-maker, scope detail for whoever is checking your work against a competing bid.
- One idea per section, with a clear header naming it.
- Short paragraphs, three to five sentences. A proposal is a working document a reader returns to, not a story they read once.
- Bullet lists for anything enumerable: line items, phases, exclusions, deliverables. A paragraph listing five things in a row forces the reader to parse it into a list themselves.
Put exclusions and assumptions in writing, clearly labeled
The section that prevents the most disputes later is the one most proposals skip: what is explicitly not included, and what you are assuming to be true. "This proposal assumes standard soil conditions; rock excavation would be quoted separately" or "does not include permit fees" heads off a mid-job argument about scope. Label this section plainly, do not bury exclusions inside a paragraph of included scope where they will be missed.
Close with a clear, low-friction next step
End the proposal by telling the reader exactly what happens if they say yes, not just asking them to. "To move forward, sign below and return, or reply to this email and we'll get you on the schedule" removes the ambiguity of "let us know if you have any questions," which invites delay rather than a decision. If there is a deadline for the pricing to hold, state it plainly near the end, not buried in fine print.
Length is a tool, not a virtue
A longer proposal is not automatically more thorough or more persuasive. Every section should earn its place by helping the reader decide. If a section exists only to demonstrate effort (padding with generic company history, boilerplate mission statements, stock photography-style filler text), cut it. The proposals that win are the ones a busy decision-maker can act on quickly, not the ones that are hardest to finish reading.
References
- See related: The One-Sentence Summary Every Document Needs
- See related: Writing a Recap Email After a Big Decision Call
- Trade-standard practice for commercial scope-of-work documentation