How to Write a Client Proposal From a Discovery Call

To write a client proposal, turn the client's problem into a specific offer: what you will deliver, what is outside the scope, how the work will proceed, what it costs and what the client needs to decide. Use the discovery call as evidence of their needs. Treat your proposed solution, schedule and commercial terms as proposals until the appropriate people confirm them.

A good proposal should let someone who missed the call understand the offer and raise a precise objection. If they cannot tell whether content migration is included, who provides the source material or what happens after the first review, the document needs another pass.

This guide follows a fictional consultancy engagement from rough call notes to a reviewable proposal. It is a writing workflow for freelancers, agencies and consultants, with checks you can use whether you draft manually or with AI.

Before you start: collect the facts that change the offer

Have the client's brief or request, your notes, any agreed follow-up messages and your own service information to hand. Use a recording or transcript only when it was appropriately made and you are permitted to use it for this purpose.

Find out who will assess the proposal, how the decision will be made, what problem needs solving and what resources the client can provide. The Government of Alberta's proposal-writing guidance identifies these as useful questions to answer before drafting. It also advises adapting the format to the client's requirements. Read the Alberta guidance.

For an informal engagement, a short email may answer the missing questions. For a formal request for proposals, follow its stated submission requirements. Do not let an attractive document structure displace a required response section or deadline.

Before writing, check that you can answer:

• What situation is the client trying to change?

• What outcome would make the work useful to them?

• What work are you actually proposing to undertake?

• Which decisions, inputs and approvals will you need from the client?

• Which material facts are still unknown?

If the last list changes the scope substantially, ask the questions first. A polished guess is still a guess.

1. Separate what was said from what you recommend

Read the call once for meaning, then again for the details that affect the offer. Avoid turning every enthusiastic remark into a requirement.

Create three small groups in your working notes:

Confirmed information: statements you can trace to a source, such as the current process, named stakeholders or a specific problem the client described. A statement can be confirmed as something someone said without being independently proven true.

Proposed approach: your recommendation for solving the problem. This is where your judgement belongs. Label it as an offer or recommendation rather than implying the client already requested every component.

Open questions: missing inputs, conflicting accounts and decisions that someone still needs to make.

In the fictional example, a client says: “New starters keep asking where the onboarding documents are.” That supports investigating document findability. It does not establish that they need a complete intranet rebuild, have approved a budget or want every document rewritten.

A useful working note is: “Client reports difficulty locating onboarding documents. Proposed first phase: review the existing document set and recommend a simpler structure. Confirm the number of documents and who can approve changes.”

Keep any source reference beside the note while drafting. You can remove internal evidence pointers from the client-facing version without losing them from your working record.

2. Write the problem and intended outcome in the client's terms

Open with the situation the reader recognises. Explain the consequence that matters to this engagement without adding dramatic claims.

Compare these two fictional openings:

Too broad: “We will transform your onboarding experience through a comprehensive knowledge strategy.”

Specific: “Your onboarding material is spread across several folders, and new starters are unsure which documents to use. We propose reviewing the current material and creating a recommended structure, so your team has a clear basis for reorganising it.”

The second version describes the problem and the work offered. It does not promise a measured reduction in onboarding time that nobody has established.

Distinguish the result you control from the client's wider objective. You might commit to delivering a reviewed content inventory and proposed folder structure. Adoption across the organisation also depends on decisions, implementation and ongoing ownership. Explain those dependencies instead of hiding them inside a confident headline.

3. Define deliverables, boundaries and acceptance

Give each deliverable a name and explain what the client receives. “Research and recommendations” could mean a short memo or several weeks of interviews. The label alone is not enough.

For the fictional engagement, the proposed deliverables could be:

• An inventory of the onboarding documents the client supplies, with duplicates and unclear ownership flagged.

• A recommended structure with a short explanation of the grouping and naming choices.

• A walkthrough with the client contact to review the recommendations and identify required decisions.

Then state the boundaries. For example, implementation in the client's document system, rewriting every document and interviewing additional departments might be outside the initial offer. Explain how an extra request will be assessed and agreed rather than pretending no changes will arise.

Add a practical review condition. Who will check each deliverable? What will they check it against? How will they provide consolidated feedback? Use a review process the people involved can actually follow.

Avoid vague acceptance language such as “when the client is happy”. A clearer description might be: “The named client contact reviews whether the supplied documents are represented and identifies any missing material before the recommended structure is finalised.” Set the actual revision allowance and approval process deliberately; do not copy them from an unrelated project.

4. Explain the approach and schedule together

Describe the work in the order it will happen. Make the dependency between stages visible.

In this example, the sequence is to receive the material, inspect it, draft a proposed structure, review it with the client and deliver the agreed final document. A date for the final document only makes sense alongside the assumptions about receiving material and feedback.

Write dates you have checked against your capacity and the client's availability. If timing remains open, identify the condition needed to confirm it. “Schedule to be agreed after receipt of the document set” is more accurate than an invented start date.

Make responsibility concrete. “Client input required” is weak; “The client contact supplies the current onboarding documents and names one person to consolidate feedback” tells the reader what they must organise.

Do not turn the proposal into a full project plan unless that level of detail helps the decision. Show enough sequence and dependencies to explain the offer. Keep your internal working tasks in your own planning system.

5. Add pricing and terms from approved information

Use your own reviewed commercial information for the price, currency, payment schedule and any applicable conditions. A transcript can record a budget discussion; it cannot choose your price for you.

Check that the price refers to the same scope described earlier. If you offer options, show the meaningful difference between them. An expanded option should specify the additional work, rather than merely being called “premium”.

Review every number separately from the prose. Check totals, units, currency, quantities and the relationship between milestones and payments. If a term is undecided, resolve it or mark it for confirmation in the working draft. Do not send a client a mixture of finished terms and unexplained placeholders.

Avoid letting AI invent discounts, guarantees, service commitments or contractual language. Use your established review process for the commercial and contractual parts of the offer.

6. Make the next decision easy to understand

End the proposal with the action you want the reader to take. Depending on your process, that could be reviewing the scope with their team, choosing between two options or arranging a discussion to resolve specific questions.

Specify the person to contact and any genuine response deadline. Explain which questions must be settled before work can begin. Do not describe a proposal as approved merely because a contact says it looks interesting.

Keep the executive summary consistent with the final offer. If the scope changed while you wrote the document, revise the opening too. A promise in the summary that disappears from the deliverables can create a different understanding for each reader.

Using a recording and AI without losing the detail

If the discovery call is in Weeve, you can use its transcript and chat workflows to review the conversation and prepare a first draft. Start with the relevant recording or a deliberately chosen set of sources. A question aimed at one client should not silently mix in another client's conversation.

Ask for an evidence pass before asking for persuasive copy. For example:

From this discovery call, identify the client's stated problem, desired outcome, constraints and unanswered questions. Keep my suggestions separate from the client's statements. Include source references where available. Do not infer budget approval, agreed scope or a start date.

Check the response against the transcript and, where needed, the original audio. Speaker labels and transcribed wording may need correction. A useful source reference lets you inspect the evidence; it does not prove that the interpretation is right.

Native Weeve preview with synthetic demonstration content. This shows source review, not an actual client call or a tested proposal-generation result.

After reviewing the extracted facts, ask for a draft using only those facts and the approach you have chosen. Supply the approved commercial details yourself. Keep an explicit list of remaining questions instead of asking the model to fill every gap.

Weeve supports local processing and optional external chat providers. If you choose ChatGPT or Claude, relevant context is sent to that provider; do not assume the whole workflow remains local. Choose the mode that fits how you are permitted to handle the material. See Weeve Chat for the product workflow.

A final review before the proposal leaves your desk

Read the document as a client who was not on the discovery call. Then check it against the source material as the person responsible for delivering the work.

Confirm that every promised deliverable appears in the scope, schedule and commercial section consistently. Check that exclusions are understandable, dependencies have named owners and the next step is explicit. Remove unsupported claims about results, past experience or client approval.

Look especially for small words that change a commitment: “all”, “unlimited”, “guaranteed”, “included” and “approved”. Keep them only when they reflect an intentional, reviewed commitment.

If a key question is unresolved, send a focused clarification before finalising the offer. Our guide to preparing for a client meeting can help organise that conversation; the meeting follow-up guide covers communicating agreed next steps afterwards.

The final test is practical: can the client explain what they are being asked to approve, and can you explain exactly what you will deliver? If either answer is uncertain, revise the offer before polishing its presentation.