Clients want their computing problems solved with the ease of getting a pizza delivered: call a number, tell them what you want, and it shows up soon afterward. The ingredients you use in the pizza rarely matter to the hungry person who wants dinner.
Instead, the proposal should identify functional categories. That is, a proposal to build the client's website might have one stage in which you establish the Site Structure (which includes setting the DNS, installing software), another for design issues (working with client to identify custom themes, choose photos), still another for content creation functionality (get existing content uploaded, teach them how to use the system), perhaps a stage for getting the site noticed (SEO, etc.). Describe those steps in English with headings that your most non-techie relative would understand. You might care whether "install Askimet" goes into "Site Structure" or a different category, and you may want to document it in that section (under a "tools" list) if the proposal will also serve as the starting project spec (it often does). But each functional category should represent a stage in the project, accompanied by a paragraph that explains how it contributes to the client's goal. (Everything keeps coming back to that.)
[ See also: Negotiation 101: To get to yes, start with no ]
Each phase also gets a time estimate and what it depends on (e.g. "4-6 weeks, starts after design signoff, requires meetings with client's marketing director"); some of this may be included in the consulting contract, which is usually but not always a separate document.
When possible, organize the phases based on the personal interaction necessary. Some chunks of project functionality require the client's input; those are the bits that I'd prefer to bill on an hourly rate or estimate with a worst-case view (meetings are scheduling pains, and you have less control over them: "Oh sorry we put that off until next week!" leaving you twiddling your thumbs). Other project phases let you work alone, without client participation (such as the DNS and installation stuff, which you're probably comfy enough with to bid on a fixed price). Whether or not you say so explicitly in the proposal, at the end of each function there's a clear product: a live site ready for content, a wireframe with a client signature, a system to track site analytics. (Do find some way to get them to sign off on each phase... but that's a getting-paid issue rather than proposal writing skill.)
Or to think of these functional categories another way: Break it up into sections that let you invoice regularly. If nothing else this means you could finish one piece of the project, invoice for it — and see if they actually pay on time. And if everything went to hell in a handbasket, they'd have that one part "done" without you needing to talk to them ever again.
This tip is adapted from "How to Write a Client Proposal" by Esther Schindler.