Most proposal guides show you a finished document and tell you to fill in the blanks. That's useful once you know what belongs in each section — but it skips the part that actually trips people up: what to do between hanging up the discovery call and opening a blank document. Here's the process, in the order you actually do it, not the order the final proposal reads in.
Start before you write anything: the discovery call
A proposal is only as good as what you walked out of the call with. Before you open a document, you need four things nailed down, ideally in the client's own words:
- The problem, stated the way they'd state it.Not your diagnosis of it — their framing. You'll use their language in the objective, which is part of why the proposal feels like it was written for them instead of copy-pasted.
- What "done" looks like.Ask directly: "How will you know this worked?" The answer becomes your objective sentence. If they can't answer it, that's useful too — it tells you the scope needs to include a step where you define success together.
- Constraints on timeline and availability. Hard deadlines, board meetings, budget cycles, or stakeholders who are traveling for the next three weeks. These become the dependencies in your timeline section.
- Who actually approves the spend.If the person on the call isn't the decision-maker, ask who is, and consider whether the proposal needs a summary paragraph written for someone who wasn't on the call.
Draft in this order, not the order it reads in
The finished proposal reads objective, scope, timeline, pricing. Writing it in that order is fine for the objective and scope. Where people get stuck is jumping to pricing too early, before the scope is actually locked — which means re-pricing later when the scope inevitably shifts. Draft in this sequence instead:
- Objective first, roughly.Don't polish it yet. Just get the outcome down in one sentence so everything after it has something to point back to.
- Scope second, in full.This is where most of your thinking time should go. List every deliverable, then go back and cut anything that's an activity instead of an artifact (more on that below).
- Exclusions third.While the scope is fresh, write down what you're deliberately leaving out. This is easiest to do immediately after drafting scope, before you move on and forget what you almost included.
- Timeline fourth. Now that deliverables are fixed, you can sequence them realistically against the constraints from the discovery call.
- Pricing last.Once scope and timeline are locked, pricing is arithmetic, not a negotiation with yourself. This is also why pricing should never be the first section you draft — a number written against an undefined scope is a guess wearing a proposal's clothes.
- Objective again, polished.Come back and tighten the sentence you drafted in step one now that you know exactly what you're proposing.
Writing the objective
One or two sentences. State the outcome, not the activity — "reduce onboarding drop-off" rather than "review the onboarding flow." If you genuinely can't state an outcome yet because the engagement itself is a diagnostic, say that: the objective of a diagnostic project is to produce a specific recommendation, not to fix the underlying problem within this engagement.
Writing the scope when it's still a bit fuzzy
This is the part that stalls people the longest. The client hasn't fully defined the problem themselves, so you're tempted to either write scope so broad it protects you from anything, or so specific it might be wrong. Neither is right. The fix is to scope the part you can bound precisely — usually the first phase — and name the uncertainty explicitly instead of hiding it.
Too vague:"Support the sales team in improving their process." This protects you from nothing — it's not a deliverable, and the client can point to any outcome and say it wasn't met.
Falsely precise:"Redesign the sales process to increase close rate by 15%." You don't know yet whether that's achievable, and now you're on the hook for a number you invented before doing any of the work.
Scoped correctly:"Phase 1: Audit the current sales process across the three regional teams and deliver a findings report with a prioritized set of process changes. Phase 2 (proposed separately once findings are in): implement the highest-priority changes." This bounds exactly what you're committing to now — a report — while being honest that the bigger work depends on what the audit finds.
When scope is genuinely uncertain, scoping the diagnosis instead of the outcome isn't a workaround — it's the correct shape for that kind of engagement.
What to have the client confirm before you send it
Don't let the proposal be the first time the client sees these details in writing. Confirm each of these in a quick recap email or message before you draft the formal document:
- The scope summary, in a few plain-language bullet points — not the full deliverable list yet.
- A budget range, even a rough one, so the pricing section isn't a surprise.
- Who needs to sign off, and roughly how long their approval process takes.
- Your earliest realistic start date, so the timeline section isn't aspirational.
If any of these get a surprised reaction, better to find out now than after you've spent an hour formatting a document around the wrong assumption.
Final pass before sending
Read the scope section once more and flag every line that describes an activity ("conduct interviews," "review current process") instead of an artifact ("interview summary," "current-state report"). Then confirm the exclusions section exists — even one line — and that the pricing matches the scope you actually wrote, not the scope you originally imagined on the call.
Once you've written a few of these, the sequence becomes automatic. The free Consulting Proposal Generator handles the formatting once your objective, scope, and pricing are drafted, so you can spend your time on the thinking instead of the layout.