# Write a proposal from rough notes
A structured proposal draft with scope, assumptions, and next steps, built from a rough description of the job.
**Time:** 12 minutes

**What you'll have when you're done:** A structured proposal draft with scope, assumptions, and next steps.
---You know what the client needs and roughly what you'd charge, but turning that into a proposal document that reads as organized and professional takes longer than the thinking did. This gets the structure done so you can spend your time on the parts only you can get right: the price and the promise.

---

## The one hard rule

**Never let it invent pricing, legal terms, dates, or commitments you haven't actually made.** A proposal is a commitment document. Anything it drafts in these categories is a placeholder for you to fill in and check, never a default to accept.

---

## Do this

1. **Describe the client need and rough scope**, in your own words.
2. **Give your actual pricing approach**, even if it's just "hourly at $X" or "flat fee, roughly $Y depending on scope."
3. **List constraints**: timeline, what's out of scope, anything the client has already specified.
4. **Ask for a structured draft**, using the prompt below, with placeholders for anything you haven't finalized.

```
Client need: [describe it]
Rough scope: [what you'd actually do]
Pricing approach: [your real approach, even if approximate]
Constraints: [timeline, exclusions, client-specified requirements]

Draft a proposal with:
1. Understanding of the need (show you listened, don't pad it)
2. Proposed scope, clearly bounded (what's included and excluded)
3. Approach or process, briefly
4. Pricing, using placeholders for any number I haven't finalized:
   mark them [CONFIRM: ...]
5. Timeline, with placeholders for dates I haven't set
6. Next steps

Never invent a specific price, deadline, or legal term I didn't
give you. Use [CONFIRM: ...] placeholders instead.
```

---

## Check this before you trust it

- **Every `[CONFIRM: ...]` placeholder**, before sending. These exist specifically so nothing gets sent with an invented number attached.
- **The scope boundaries.** Make sure "what's excluded" actually matches what you intend to exclude; a proposal that's vague here is where scope creep starts.
- **Any language that sounds like a legal or contractual commitment** ("guarantee," "warranty," specific liability language). That belongs in a contract reviewed properly, not a proposal draft.

---

## If it goes wrong

**It fills in a price or date anyway, despite the instruction.** Remove it and replace with your own placeholder before proceeding. Treat any specific number you didn't provide as suspect by default.

**The scope section is too vague to actually bound the work.** Push back with specifics: "list exactly what's included, as bullet points, not a paragraph." Vague scope in the proposal becomes a dispute later.

**The tone doesn't match how you actually talk to clients.** Paste in a proposal you've sent before and ask it to match that voice, the same fix that works for any other drafting task on this site.

**The client asks a question the proposal doesn't answer.** That's useful information for the next proposal, not a failure of this one. Add a standard section for whatever came up, so it's covered next time.

---

<div class="cta">
<h2>Related</h2>
<ul>
  <li><a href="/templates/build-a-proposal-from-notes/">Build a proposal from rough notes</a> <span>The paste-ready version, no walkthrough</span></li>
  <li><a href="/guides/small-business/vendor-proposals-fine-print/">Compare vendor proposals without missing the fine print</a> <span>The buyer's side of the same document type</span></li>
  <li><a href="/guides/small-business/faq-from-customer-questions/">Create a FAQ from the questions customers keep asking</a> <span>For the questions that keep coming up after a proposal goes out</span></li>
  <li><a href="/rss.xml">Subscribe by RSS</a> <span>New guides as they publish</span></li>
</ul>
</div>