A step-by-step process for solo consultants to convert discovery call notes into a tailored, client-ready proposal — faster and with less rewriting.
The discovery call went well. The client is engaged, the problem is clear, and there's real budget behind this.
Then you open a blank document.
Everything you just learned — the exact words they used, the downstream consequences they mentioned, the timeline pressure they dropped toward the end of the call — is sitting in scattered notes that don't yet look like a proposal.
This is the gap most consultants fall into. The information is there. The translation is the work.
Here's a process that closes that gap.
Right after the call ends, resist the urge to immediately start writing the proposal. Spend five minutes capturing the raw material first.
Write down (or pull from your transcript if you use a tool like Granola or Fathom — see The Best AI Transcription Tools for Consultants):
This five-minute capture is the foundation of a specific proposal. Skip it, and you'll end up paraphrasing your own impressions instead of working from what the client actually said.
A consulting proposal has a predictable structure: problem statement, proposed approach, scope, timeline, investment, next steps. The goal of this step is to assign your raw notes to the right section before you write a single sentence.
Take your capture list and label each item:
You're not writing yet. You're organizing raw material so that when you do write, every section has a specific starting point instead of a blank page.
Most consultants write the executive summary first. It's a mistake. Write the problem statement first.
This is the section that anchors everything else. When it's done well, the rest of the proposal follows logically. When it's generic, no amount of polished scope writing will save the document.
Write one or two paragraphs that restate the client's situation in their language. Specifically:
You're not pitching your solution yet. You're showing them you understood. This is also the section that matters most for proposal structure — learn more in How to Write a Consulting Proposal.
Once the problem statement is done, the scope of work is the next hardest section. The most common mistake: listing activities ("conduct interviews," "review documentation") instead of outcomes ("a prioritized list of the three workflow bottlenecks causing the most delay, with evidence from your team").
For each phase of work, ask: What will the client have at the end of this phase that they don't have now?
That's your deliverable. The tasks that produce it are yours to manage — they don't need to be in the proposal unless they help the client understand the process.
Now that the body of the proposal exists, write the executive summary. It should be 100–150 words that answer:
The executive summary will be forwarded to people who weren't on the call. It has to stand alone.
Before you show the investment number, restate — in one sentence — what this engagement is worth to the client. If they told you the problem is costing them 15 hours a week of their team's time, say so. Then show the price.
The price looks different in that context than it does sitting alone in a section header. For more on this: How to Price Your Consulting Services.
If you record and transcribe your discovery calls (tools like Granola, Fathom, or Otter.ai do this automatically), you have the raw material to make this entire process faster.
The transcript contains the client's exact language — problem descriptions, urgency signals, outcome statements — without any paraphrasing or memory compression.
PitchWright is built specifically for this workflow. You paste in your notes or transcript, and it maps the client's language directly to the proposal sections: problem statement, approach, scope, investment framing. The output uses the client's words, not generic filler, so what you edit is already 80% of the way there.
The point isn't to skip the thinking. The discovery call is still where the proposal gets won. The point is to not lose the raw material in translation between the call and the document.
What's the difference between discovery call notes and a brief? Notes are the raw capture from the call — unstructured and in the client's words. A brief is your interpreted summary, organized for internal use. For proposal writing, notes (or a full transcript) are more valuable because they preserve the client's exact language, which is what makes a proposal feel personalized rather than templated.
How do I handle discovery calls where the client isn't specific about their problem? Ask follow-up questions during the call: "If we solve this, what changes first?" and "What would it cost you if nothing changes over the next six months?" Vague client descriptions are usually a sign that the problem hasn't been surfaced clearly yet — your job is to help them articulate it.
What if I don't record my discovery calls? You can still apply this workflow with handwritten or typed notes. The key is capturing the client's exact phrasing, not your interpretation of it. Even a few verbatim quotes from the call are more valuable than a polished summary written from memory.
Specificity. Every time.
Not longer. Not more polished. More specific — to this client, this situation, this conversation.
The fastest way to get there is to use your discovery call as your primary source material, and to resist the pull toward comfortable generalities that could apply to any client.
Your notes from that call are more valuable than any template. Build your proposal from those.
The PitchWright team writes about the practical side of winning consulting work — proposal structure, pricing strategy, and discovery call workflow.
One proposal teardown in your inbox, every Thursday.
Real proposals, what worked, what we'd change. No fluff. 4,000+ consultants read it.