Write Proposals That Close

A proposal should be a decision document, not a brochure with a price at the end. It records what you heard, what the buyer wants to change, what you will deliver, what remains outside the job, how the work will be reviewed, and what the buyer must do next. A clear proposal helps the buyer say yes, ask for one specific change, or decline without wasting another week.

Writing proposals becomes easier after a diagnostic call because the proposal is mostly a translation of evidence. If you cannot connect a sentence to something the buyer said or supplied, mark it as an assumption instead of presenting it as a requirement.

Start With the Decision

Before selecting a template, write one sentence:

> On [date], [buyer] will decide whether to approve [bounded result] for [price] under [review and payment terms].

This forces you to name the person who can decide and the approval event. A proposal sent to someone who can only recommend is not ready to be called a proposal. It may still be useful, but the path to the decision owner must be written down.

The document should support one of four outcomes:

• Approval of the stated scope.
• Approval after a named change.
• A later decision tied to a named missing fact.
• A clear no.

"Let me know what you think" creates none of those outcomes. It leaves the next move ambiguous and invites silence.

Mirror the Problem Without Inflating It

Use a short section called "What we heard." Write the current process in plain operational language:

• The event transcript arrives after approval.
• An event coordinator removes attendee names.
• The owner drafts follow-up messages by hand.
• A second reviewer checks claims and links.
• Messages sometimes miss the next event window.

Then state the evidence:

• The latest cycle required four hours of drafting and review.
• One draft repeated a claim the source did not support.
• The buyer missed one event window.
• The buyer already pays for an event coordinator and writing tools.

Do not turn one late cycle into a claim of monthly losses. Do not say the buyer's team is careless. A neutral description shows that you listened and gives the buyer a chance to correct the record before agreeing to work.

Promise One Finished State

The proposal needs one primary result. Other included items should make that result credible, not turn the proposal into a list of every useful thing you could do.

A reasonable result statement for the workshop example is:

> A review-ready set of twelve follow-up message drafts, tied to four approved customer moments, with source notes and a completed privacy and claim checklist.

This sentence names the output, quantity, source relationship, and acceptance evidence. It does not promise more clicks, sales, attendance, or a reduction in staff. Those may be possible, but they are not the work you control.

Put the result near the top. A buyer should not need to search for the value inside your biography, methodology, or software description.

Turn Discovery Into a Work Plan

The work plan should show sequence and review points:

1. Approve the four customer moments and source files.
2. Redact or remove unnecessary personal data.
3. Draft the twelve messages with source notes.
4. Check names, dates, quotations, links, and claims against the approved source.
5. Send one consolidated review set to the named reviewer.
6. Correct agreed defects within the included review round.
7. Deliver final files and a short handoff note.

Include the buyer's responsibilities by date. A plan that depends on an unreviewed transcript but does not require the buyer to approve that transcript is incomplete. State the working assumption: for example, that the transcript and program notes arrive in readable formats and contain the information needed for four moments.

Define Done in Inspectable Terms

"High quality" cannot be accepted or rejected consistently. Replace it with checks:

• Twelve message drafts are present.
• Each is connected to one of the four approved moments.
• Every factual claim has a source note.
• No attendee name or contact detail appears in the final drafts.
• The named reviewer has completed the approval checklist.
• Final files are delivered in the agreed formats.

If one of these checks fails, the work is not complete. If the buyer wants a different kind of result, the scope has changed. This distinction prevents a quality problem from becoming an argument about taste.

List Inputs, Exclusions, and Reviews

A useful scope has three columns: included, buyer supplied, and excluded. That structure answers the assumptions that usually cause disputes.

Included in the pilot might be:

• Four customer moments selected from approved material.
• Twelve drafts.
• Source notes.
• One privacy and claim review.
• One consolidated correction round.
• Final files and handoff notes.

Buyer supplied might be:

• One approved transcript.
• One program notes file.
• The four approved moments.
• The name of the final reviewer.
• Timely answers to factual questions.

Excluded might be:

• Sending the messages.
• Building a marketing campaign.
• Providing legal review of advertising claims.
• Guaranteeing response or attendance.
• Maintaining the workflow after handoff.
• Processing files outside the agreed input set.

Exclusions are not a way to escape the main promise. They make the boundary visible so both sides can judge whether the small engagement fits.

Make Price and Payment Part of the Decision

Show the total price, currency, tax treatment, payment trigger, and payment method. If a deposit is required, say when it is due and what it reserves. If work begins only after payment or approval, state that.

Do not bury a material condition in a footnote. If the price assumes one input file and two review rounds, those facts belong in the main scope. If a change requires additional work, the proposal should say how the change will be estimated and approved.

The smallest proposal is often:

• Fixed result.
• Fixed price.
• Fixed start window.
• Fixed delivery window.
• One named reviewer.
• One included correction round.

That simplicity reduces the number of ways the decision can stall.

Name Decision Roles and Approval Evidence

List who can:

• Confirm the problem and desired result.
• Provide or authorize data access.
• Approve scope and price.
• Review the deliverable.
• Approve payment.

For the workshop example, the owner may approve spending while the coordinator approves access and factual accuracy. The proposal should show both responsibilities if both matter.

End with an approval request such as:

> If this scope is correct, reply "approved" and I will send the kickoff checklist and payment instructions. If anything must change, mark that section and I will send a revised version for the same decision.

This is more useful than asking for a signature the buyer may not have authority to provide. Use whatever approval method creates an appropriate record for the engagement and jurisdiction.

Handle Unknowns Before They Become Surprises

Some facts are unavailable during diagnosis. Put them in an "Open assumptions" section:

• The transcript can be shared after redaction.
• The four customer moments can be approved in one review.
• The buyer's current tools permit the proposed handling of source files.
• The buyer does not need a regulated professional opinion.

Each assumption needs a consequence. For example: "If the source cannot be shared in the proposed format, the workflow may require a manual review session or a revised scope." This tells the buyer what changes if the assumption fails.

Keep the Proposal Honest

Do not use false urgency, invented scarcity, or inflated credentials. Do not add a customer logo without permission. Do not claim that an AI tool guarantees speed or accuracy. If you are using a new workflow, say what has been tested and what has not.

Evidence can include completed work, a relevant explanation of your process, a references call, or a small diagnostic step. It cannot include a fabricated case study. Honest limits help a careful buyer trust the parts you do promise.

A Worked Proposal

The following is an illustrative composite, not a real client proposal or legal agreement.

Nina's diagnostic conversation shows that the workshop owner approves contractor spending below a local threshold, while the event coordinator controls the transcript and factual review. The owner wants twelve follow-up drafts before the next event in three weeks. The coordinator is worried about attendee names in the transcript.

Nina sends a two-page proposal. Page one contains:

• Decision: Approve a $1,500 pilot by Friday.
• Result: Twelve source-checked follow-up drafts based on four approved customer moments.
• Why now: The next event is in three weeks, and the current manual sequence has already missed one window.
• Work plan: Approve inputs, redact, draft, verify, review, correct, deliver.
• Done: Twelve drafts, source notes, privacy check, reviewer approval, agreed final formats.

Page two contains inputs, exclusions, payment timing, review limits, data handling, assumptions, and the approval request. Her terms identify the owner as price approver and the coordinator as input and factual reviewer. The proposal includes no promise of more attendance. It offers a concrete result and a known path to a decision.

The owner asks whether the price can include six additional drafts. Nina does not silently absorb them. She sends a revised option with the added quantity, a later final date, and a revised price. The buyer can now compare two complete scopes instead of asking for an invisible favor.

The coordinator asks that the transcript be redacted before it enters any AI tool. Nina confirms that this is already part of the workflow and records the approved redaction method. The proposal moves into the privacy and approval stage.

Test the Proposal Before Sending

Ask:

• Can the named decision maker approve this document?
• Is there one obvious result?
• Can a stranger tell what is included and excluded?
• Does every material claim have evidence or an assumption label?
• Are dates, price, payment, and review limits visible?
• Does the document explain why action now is useful without inventing pressure?
• Is the next step one reply or one scheduled decision?

Have a peer read the proposal without your call notes. If they cannot restate the result, price, boundary, and next step, revise the document.

Your Chapter Exercise

Using the call notes from the previous chapter:

1. Write the decision sentence with buyer, result, price, and date.
2. Record three to five facts from the diagnosis and label each as stated, estimated, or unknown.
3. Write one outcome sentence and five acceptance checks.
4. Build included, buyer supplied, and excluded lists.
5. Draft the work sequence with two review points.
6. Name the approver and the factual reviewer.
7. Add price, payment trigger, review limit, and change process.
8. Write data, AI, and human-review conditions.
9. Add open assumptions and their consequences.
10. Ask a peer to restate the proposal's decision and scope from memory.

Chapter Deliverable

Create a reusable proposal kit containing:

• Decision sentence.
• What we heard section.
• One-outcome statement.
• Work plan and buyer responsibilities.
• Included, supplied, and excluded lists.
• Acceptance evidence.
• Price, payment, and change terms.
• Data, AI, and human-review controls.
• Decision roles.
• Open assumptions.
• One clear approval request.
• A proposal review checklist.

Source and Decision Caution

This chapter is a practical communication framework, not legal, tax, privacy, or financial advice. Contract formation, consumer rights, electronic signatures, deposits, cancellation, tax, and recordkeeping requirements vary by jurisdiction. Confirm the actual agreement with a qualified reviewer and current local sources before relying on it for a paid engagement.

Keep proposal recipient data and diagnostic notes in an approved location. Share only what the decision requires. If AI is used to draft or summarize a proposal, verify every buyer fact, number, date, promise, and limitation against the approved source. A polished sentence is not evidence, and an AI-generated clause is not legal review.

The next chapter covers the period after the proposal is sent: how to follow up, make a decision easier, and close the loop when the answer is no.