Proposal vs Quote vs Estimate vs Statement of Work: which one to send
A client says "can you send something over?" and you have four options. Most people pick by habit, and the habit is usually whichever template they last used. That is how a casual estimate ends up being treated as a fixed price, and how a twelve page proposal gets sent to someone who wanted a number.
The four documents are not interchangeable. They differ in one specific way: how much you are committing to. Work out what you are willing to commit to and the choice makes itself.
The short version
| Document | What it is | How binding | Typical length |
|---|---|---|---|
| Estimate | Your best guess at the cost | Not binding, but relied on | Under a page |
| Quote | A fixed price, for a fixed scope, for a fixed time | Binding once accepted | One to two pages |
| Proposal | The argument for hiring you, with the price inside it | Usually binding on price once accepted | Three to fifteen pages |
| Statement of work | Exactly what will be delivered, by when, for what | Binding, and usually attached to a contract | Two to ten pages |
If you only remember one thing: an estimate says "roughly this much", a quote says "this much", a proposal says "this much, and here is why you should pick us", and a statement of work says "this much, and here is precisely what you get for it".
Estimate: a guess you can be held to anyway
An estimate is an approximation given before the full scope is known. You send one when someone asks what a kitchen refit or a website rebuild "tends to run".
The legal position in most jurisdictions is that an estimate is not a binding offer. The practical position is different. Clients remember the first number they hear, and if the final invoice is meaningfully higher than the estimate, you are the one having the conversation about it. Consumer protection rules in several countries also restrict how far a final bill can drift from a written estimate without notice.
Send an estimate when: the scope genuinely is not known yet, and you need to establish whether you are in the same ballpark before either of you spends more time.
Always put on it:
- The word "estimate", in the title, not buried in a footer
- What the number assumes, in specific terms, because the assumptions are the whole point
- What would change it, listed as bullets
- How long the estimate holds before the numbers need revisiting
The most common mistake is an estimate that reads like a quote. If there is no visible statement of what could move the number, you have effectively sent a quote and given up the flexibility you were trying to keep.
Quote: a price you are committing to
A quote is a fixed price for a defined scope, open for a defined period. Once the client accepts it, you have a contract on those terms in most legal systems. That is the point of it. The client is buying certainty and you are pricing that certainty in.
Send a quote when: you know exactly what the work is, you have done it enough times to price it confidently, and the client wants a number rather than a pitch.
A quote is not finished without:
- An itemised scope, so "what was included" is never a matter of memory
- The total, the tax treatment, and any deposit
- An expiry date, which is the single most-skipped field and the one that protects you when materials or your own rates move
- Payment terms, which is the other one people skip
The expiry date matters more than it looks. Without one, a quote you sent eight months ago at last year's rates is arguably still open for acceptance.
Proposal: the argument, with the price inside it
A proposal does a different job. A quote answers "how much". A proposal answers "why you, and why this approach". It contains a price, but the price is not the document, it is one section of it.
Send a proposal when: you are being compared to someone else, the client needs to show it to a colleague who was not on the call, or the approach itself is part of what they are buying. Agencies, consultancies and anyone selling a service where the method varies by provider live here.
A proposal that works usually has this shape:
- What you understood the problem to be. In their words, from the call. This section does more work than the rest of the document combined, because it is the only evidence that you listened.
- What you propose to do about it. The approach, in enough detail to be credible and not so much that it reads as a delivery plan.
- What it costs. Itemised, with options if options genuinely exist.
- Why you. Relevant work, named people, and what happens if it goes wrong.
- What happens next. One clear action, with a date attached.
The most common failure is length. A proposal is not more persuasive for being longer. If the client can find the price and the next step in under thirty seconds, the document is doing its job.
Statement of work: the one that prevents the argument
A statement of work, usually called an SOW, is the operational document. It defines what will be delivered, by whom, by when, to what standard, and what happens when something changes. It is normally attached to a master services agreement, which carries the legal terms, while the SOW carries the specifics.
Send an SOW when: the work has phases, several people, or a timeline long enough that memories will diverge. Anything over a few weeks probably needs one.
An SOW earns its keep through the sections people find boring:
- Deliverables, described so that "done" is observable rather than a matter of opinion
- Acceptance criteria, which is how you get paid without an argument
- Assumptions and exclusions, which is where scope creep is prevented or is not
- A change process, so a new request is a priced change order rather than a favour
- Milestones and payment schedule, tied to acceptance
If you have ever finished a project and then spent three weeks discussing whether something was in scope, the fix is a better SOW, and specifically a better exclusions section. We wrote a longer piece on how to write a statement of work that goes through each section with the wording that does the work.
Which one is the client actually asking for?
They rarely use the right word. Translate by intent:
| They say | They usually want |
|---|---|
| "Can you give me a ballpark?" | Estimate |
| "Send me a price" / "How much for X?" | Quote |
| "Send over a proposal" | Proposal, and probably one that another vendor also sent |
| "We need something for procurement" | Quote or SOW, with a purchase order number on it |
| "Put together a scope" | Statement of work |
| "Send the contract" | An SOW or MSA, and they are ready to buy |
When you genuinely cannot tell, ask one question: "do you want the number, or the number with the reasoning?" That single question sorts a quote from a proposal.
The version that causes the most trouble
The dangerous document is the one that is not labelled at all. An email that says "so that would be around 40,000 for the three phases, we can start in October" is an estimate in the writer's head and a quote in the reader's. It has no expiry, no exclusions, no assumptions, and it is in writing.
Whatever you send, label it in the title, date it, and say when it expires. Those three things take a minute and remove most of the disputes that reach a lawyer.
Writing four different documents from the same brief is where most of the time goes. In DocuDeal you describe the deal in a sentence, pick which of the four it is, and get a complete draft back with the right sections for that document type. The price is computed from your own price list rather than written by the model, so an estimate and the quote that follows it cannot silently disagree. Three documents a month are free.
Because the AI writes the whole thing rather than filling a template, the right document for the situation is about a minute of work rather than an afternoon, so you send the correct one on the day of the call instead of the one you happened to have a template for. Users are unlimited from Pro, so everyone who talks to clients can send the right document themselves.
The one-line rule
Estimate when you do not know. Quote when you do. Proposal when you are being compared. SOW when the work is long enough that people will remember it differently.