Proposal Checklist: Review Gates Before You Send

A proposal checklist is a review tool, not a writing template. Its job is to catch missing decisions before the document reaches the client. A good checklist asks whether the proposal can be evaluated, approved and turned into delivery without relying on a sales conversation.

This checklist uses a fictional consulting scenario: a firm is proposing a six-week vendor-selection readiness review for a growing healthcare administration business. The client needs to decide whether it is ready to issue an RFP for a new case-management system. The proposal should help the buyer understand the problem, recommended approach, deliverables, exclusions, fees and next steps. It should not pretend to be legal or procurement advice.

Gate 1: Problem and objectives

The opening should make the client's decision visible. If the problem is vague, the whole proposal will feel vague.

Check the proposal for:

• A specific current problem or decision.
• Evidence source, such as discovery call notes or supplied documents.
• An objective the consultant can actually deliver.
• No unsupported claims about guaranteed outcomes.

Example pass

[Client] needs to decide whether it is ready to issue an RFP for a new case-management system by [date]. Current concerns include inconsistent requirements from three departments, unclear approval authority and unresolved data-migration questions. The objective of this engagement is to produce a readiness report that identifies gaps to resolve before the RFP is issued.

Why it passes: The objective is a report and decision support, not "successful system selection." It names the decision date and the issues to investigate.

FAR Part 7 says acquisition planning should ensure the statement of work closely aligns with performance outcomes and cost estimates (Acquisition.GOV, FAR Part 7). This proposal is not a federal acquisition plan, but the review question is useful: does the proposed work align with the decision and likely cost?

Gate 2: Recommended approach

The approach should explain how the team will get from problem to recommendation. It should not be a menu of generic methods.

Check the proposal for:

• Phases or workstreams in a logical sequence.
• Client inputs needed for each phase.
• Decision gates before later work begins.
• Clear treatment of assumptions.

Example pass

Phase 1 confirms current-state requirements and decision owners. Phase 2 tests readiness for RFP release by reviewing requirements, approval route, data-migration questions and vendor evaluation criteria. Phase 3 delivers a readiness report and sponsor workshop. The engagement does not proceed to vendor outreach unless the sponsor approves a separate scope.

Why it passes: It uses a sequence and prevents vendor outreach from becoming implied.

The Oregon Department of Transportation's SOW guide recommends discussing tasks, deliverables, delivery schedule and items provided by the agency during review, and capturing expectations in writing (ODOT SOW Writing Guide). Apply that discipline before sending the proposal: if a client input is needed, it belongs in the approach or assumptions.

Gate 3: Deliverables and exclusions

Deliverables are what the client buys. Exclusions are what prevent adjacent work from becoming accidental scope.

Check the proposal for:

• Each deliverable has a format and reviewer.
• Review rounds are limited or described.
• Common adjacent services are excluded.
• Acceptance or next-step criteria are stated.

Example pass

Exclusions: vendor longlisting, RFP drafting, procurement-law advice, software demonstrations, contract negotiation, data migration planning and implementation support.

Why it passes: The exclusions are specific to vendor selection. A generic "all other work excluded" would not warn the client about likely assumptions.

For federal schedule service orders, FAR 8.405-2 says SOWs include deliverable schedule and applicable performance standards when relevant (Acquisition.GOV, FAR 8.405-2). In a proposal, use that as a pre-contract review: does the buyer know what will be delivered and how it will be reviewed?

Gate 4: Fees, assumptions and change route

Fees are not complete unless the proposal explains what the fee depends on. Assumptions are the bridge between scope and price.

Check the proposal for:

• Fee amount and currency.
• Invoice timing and payment timing.
• Expense treatment and tax note.
• Assumptions behind the fee.
• Written route for extra work.

Example pass

The fixed fee is [currency and amount], invoiced [schedule] and due [number] days from invoice date. The fee assumes up to [number] stakeholder interviews, one consolidated comment round on the draft report and remote delivery. Additional interviews, onsite workshops or RFP drafting require written approval before work begins.

Why it passes: It connects price to interview count, comments and delivery mode. If the client wants more, the change route is already there.

Avoid hiding cancellation, renewal or extra-fee terms. The FTC advises small businesses not to be rushed, to read contracts and to get terms in writing before agreeing (FTC small business contract alert). That guidance is about payment-processing contracts, but the same habit protects proposal approval.

Gate 5: Next steps and approval

The proposal should end with a decision path. "We look forward to working together" is not enough.

Check the proposal for:

• Named approver or approval role.
• Acceptance deadline.
• Start condition.
• First client action after approval.
• Relationship to any service agreement or SOW.

Example pass

To proceed, [Client sponsor] signs this proposal by [date]. Work begins after signature, receipt of the materials listed in Appendix A and confirmation of interview availability. If a master services agreement or statement of work is required, this proposal is subject to those documents being agreed and signed.

Why it passes: It says who approves, by when and what must happen before work starts.

Whether a signed proposal is binding depends on wording, related documents and governing law. If the proposal includes legal terms, route it to qualified counsel for the relevant jurisdiction.

Gate 6: Final document cleanup

The last gate is mechanical, but it prevents embarrassing mistakes.

• Client name, project name and dates are correct throughout.
• Old pricing, old contacts and copied examples are removed.
• Figures in body, tables and appendices match.
• Links and attachment references work.
• Confidential material is appropriate for the recipient.
• Tracked changes and comments are resolved before sending the final version.

Microsoft Support explains that Word tracked changes can be accepted or rejected from the Review tab (Microsoft Support). Use that intentionally before sending a clean client copy.

Add a buyer-readiness check before sending. Ask whether a client sponsor could forward the proposal to finance, procurement or an executive without adding a long explanation. If not, strengthen the proposal before it leaves.

The forwarded proposal should answer: why this work, why now, what decision it supports, what the client receives, what is not included, what it costs and how approval happens. A sponsor who has to rewrite those points in an email is doing work the proposal should have done.

Start from an editable proposal

The consulting proposal template includes editable Word sections for client need and proposed outcome, scope and deliverables, delivery approach and timetable, fees and acceptance, plus review and approval prompts. Use this checklist against the draft before sending so the proposal is ready to evaluate, not just pleasant to read.

Sources: FAR Part 7, Acquisition.GOV, Statement of Work Writing Guide, Oregon Department of Transportation, FAR 8.405-2, Acquisition.GOV, FTC small business payment-processing contract alert, Accept tracked changes, Microsoft Support