Why Most Proposals Get Skimmed and Filed
The average procurement reader spends about ninety seconds on a proposal before forming an opinion. Sometimes less. That ninety seconds is not enough to read the introduction, the methodology, the team bios and the appendix on prior work. They will skim for the answer to four questions:
- What exactly is being delivered?
- When will it be delivered?
- How much does it cost?
- What does it require from us?
Everything else is a comprehension tax. The proposals that close are the ones where those four answers are easy to find and feel proportional to the budget. The proposals that lose are the ones where the buyer has to dig.
This post walks through how to structure a proposal that respects that ninety seconds. The free project proposal template follows the structure exactly so you can fork it and ship.
Five Sections, In This Order
A proposal that closes has five sections in a specific order. The order is not stylistic; it's about answering the buyer's questions in the order they ask them.
1. Overview
Two paragraphs maximum. What's the project, who's it for, why now. This is not the introduction to your company. It's the orientation to the work.
The mistake here is making the overview a sales pitch about your firm. The buyer already knows who you are; they invited you to pitch. What they want to verify is that you understand their situation. Two or three sentences proving that, then move on.
2. Scope of Work
A bulleted list of deliverables. Not phases, not methodology, just what they're getting. Each bullet is a noun phrase: "Customer interview synthesis report," "Revised information architecture," "Deployed prototype on staging environment."
Three to seven deliverables is the right number. Fewer feels thin; more reads as scope creep. If the project legitimately requires more, group them into themed buckets and list the buckets here, with full detail later.
The buyer is checking: does this match what we asked for? They will compare line by line against the brief. Every deliverable should map cleanly to something they explicitly requested or you've explicitly added with rationale.
3. Timeline
A table with three columns: phase, duration, deliverables. Three to five rows. This is where you commit to dates implicitly without locking yourself into a specific start.
The pattern that works:
| Phase | Duration | Deliverables |
|---|---|---|
| Discovery | 2 weeks | Requirements document, stakeholder interview synthesis |
| Development | 6 weeks | Working prototype, technical documentation |
| Launch | 2 weeks | Production deployment, training materials |
Two notes on timeline:
- Duration over dates. "2 weeks" is more flexible than "March 1 to March 14." If they sign late, the proposal still applies.
- No buffer. Don't pad the timeline with a "contingency" row. It reads as a hedge. If you need buffer, build it into individual phases.
4. Pricing
A table with two columns: line item, cost. Bold the total row. Numbers right aligned.
This is the section the buyer will read first, then last. Make it scannable.
The pattern that closes:
| Item | Cost |
|---|---|
| Discovery phase | $5,000 |
| Development | $15,000 |
| Launch support | $3,000 |
| Total | $23,000 |
A few principles:
- One total. Don't show monthly breakdowns, annual breakdowns and project totals in the same table. Pick the one that matches how the buyer thinks about money for this project.
- Itemize at the phase level. Itemizing at the deliverable level invites negotiation on individual deliverables, which usually shrinks the scope without shrinking the work.
- No taxes. Add a single line under the total, "Plus applicable VAT" or "Excludes 25% Swedish moms", rather than complicating the table.
If you need to offer tiers (basic vs premium scope), put each tier in its own pricing block with its own total. Don't combine tiers into one table.
5. Terms
Three to five lines. Payment terms (Net 30 is the safe default), payment schedule (50/50 is common), and proposal validity period.
The validity line is non negotiable. "This proposal is valid for 30 days" protects you from a buyer signing in six months at numbers you wrote when costs were different. Most signers won't even notice the line; the ones who do will respect it.
What to Leave Out
These sections kill proposals that would otherwise close:
- Company background. They invited you. They know who you are. If you must include it, make it an appendix.
- Team bios. Same logic. If a specific person on your team is the reason they're hiring you, mention them by name in the overview. Otherwise the bios are filler.
- Methodology deep dive. "Our 7-step approach" is comprehension tax. They want to know what they get, not how you'll arrive at it.
- Long case studies. A two sentence reference to past work in the same domain is enough. Full case studies belong on your website.
- Quote at the front. A quote from a happy customer at the top of the proposal is a tell that you don't trust the proposal itself to close. The proposal closes. Quotes are for the website.
The version that wins is short. Two to four pages for a known scope, eight to fifteen pages for a complex enterprise statement of work with appendices. Anything between those ranges is usually padded.
Sending and Tracking
A few operational notes on the send:
- PDF, not Word. Word documents look unfinished. They also reveal track changes if you forgot to accept them. PDFs read as polished and tracked changes are private.
- Trackable link, not attachment. Tools like HubSpot, PandaDoc, Proposify or DocSend let you see when the proposal was opened and which pages were spent on. The pricing page is usually the longest dwell. That signal tells you when to follow up.
- Personal follow up after 3-5 business days. Not a calendar invite. A short note: "I saw you spent some time on the pricing section, happy to walk through the assumptions if useful."
If you're sending many proposals with similar structure, the API on Quaterio's Business plan batch generates up to 1000 PDFs per call. For agencies with templated SOWs across many similar projects, the workflow is: keep the structure in a template, pass per client variables, get back a personalized PDF per row. The proposal stays on brand and you skip the copy paste work that introduces typos.
When the Proposal Is Not the Bottleneck
A reality check. Sometimes the proposal is fine and the deal still doesn't close. Common reasons that aren't about the proposal:
- Budget mismatch. The buyer can't actually afford the work at the level they need it. A proposal can't fix this; only a different scope can.
- Wrong stakeholder. You're pitching the project lead but the budget owner is two steps up. The proposal doesn't reach them in a form they'll act on.
- Bad timing. The right answer arriving at the wrong time of quarter, year, fiscal cycle. Usually not your fault and usually not fixable from inside the proposal.
If you've sent a structurally clean proposal and the deal stalls, the diagnostic is rarely "make the proposal longer." It's usually about who's reading it, when, and what budget they can actually authorize.
Try It
The free project proposal template follows this structure exactly. Sign up free, fork the template, replace the placeholders with your scope, timeline and numbers, and export a PDF. The first proposal takes about thirty minutes. Subsequent ones take five, the structure is the work.
For longer engagements like service agreements, the service agreement template handles the legal terms separately. For project status updates after the proposal closes, the business report template is the natural follow up.
