ConsultantStack

Proposals · 2026-10-25

The Proposal Doesn't Need Writing. It Needs Deciding.

A proposal is not a document you write. It is a decision you make, transcribed. If you can state the decision in five sentences, a model can draft the document around it in a few minutes — and the draft will be better than what you'd write at 11pm, because it doesn't get tired and doesn't soften the number to be liked.

The part that stays yours is the decision: what is in scope, what is excluded, what it costs, and what you are assuming. Get those four right and the prose is mechanical. Get them wrong and no amount of good writing saves the proposal.

Where proposals actually go wrong

Ask someone why a proposal took four hours and they will usually say the writing took four hours. It rarely did. The four hours were spent discovering, mid-sentence, that they had not decided what the client was buying.

The symptoms are recognizable:

  • Two paragraphs that describe the same deliverable slightly differently, because you hadn't settled which one you were selling.
  • A price with a paragraph of hedging around it, written by someone who was not confident about the scope.
  • An exclusions list that is either absent or so vague it excludes nothing.
  • A timeline built from optimism rather than from the same estimate you'd have given a colleague.

All four are decisions, not prose problems. Writing them down with a model's help is fast. Being uncertain about them is slow, no matter what you write them with.

What to give the model, and what not to

The input is the whole game. A prompt that says "write a proposal for a website redesign" produces decoration: confident-sounding scope, invented deliverables, a timeline with no basis. That is not the model's failure. It was given nothing to be right about.

What works is a decision brief. Four blocks, written in plain language, before any drafting:

1. The decision itself. One sentence: "We will do X for Y, over Z weeks, for N." If you can't write this sentence, stop. The proposal will not fix that.

2. The scope, as a list of things the client receives. Not activities. Deliverables. "A 40-page strategy memo" is a deliverable. "Extensive research and analysis" is not.

3. The exclusions, as a list of things the client might reasonably expect that you are not doing. This is the block people skip, and it is the block that prevents the argument in week six.

4. The assumptions your number depends on. How many stakeholders you'll have access to, how fast feedback will arrive, what happens if the data isn't ready. These are the conditions under which your price is true.

With those four, a drafting instruction is short: "Draft a proposal using only the scope, exclusions, and assumptions above. Do not add deliverables I did not list. Do not soften the price. Where you need information I have not given, ask me instead of inventing it."

That last clause matters more than it looks. An unconstrained model fills gaps silently. A constrained one asks.

What the four blocks look like

A filled-in decision brief for a piece of work, written badly and quickly, before any drafting:

Decision: I will run a four-week workflow audit for this client's customer support onboarding, for a fixed fee, with a written output at the end.

Scope (what they receive): one 90-minute walkthrough of the current process; a written map of every step with who owns it and how long it takes; a classification of each step as automate, assist, keep manual, or delete; one recommended starting slice with a stated risk; a 60-minute walkthrough of the findings.

Not included: building any automation; integration work; training the team; a second workflow; follow-up support after the walkthrough.

Assumptions the fee depends on: one workflow, not three wearing one name; access to two people who actually run the process; existing documentation, if any, provided before the walkthrough; feedback on the draft within five working days.

Everything the proposal needs is in there. What the model adds is not judgement — it is the eight hundred words of connective tissue that turn those four blocks into something a client can read without wincing. That is the trade: you spend twenty minutes deciding, and a few minutes drafting instead of an evening.

Now look at what would go wrong without the exclusions block. The client reads "workflow audit," remembers mentioning training their team, and assumes training was included. Nothing in the scope list contradicts that assumption — it only lists what is included, and a reasonable person can read an inclusion list as incomplete rather than exhaustive. The exclusions line exists purely to make the boundary explicit, and it is the line most often skipped because writing it feels ungenerous.

The failure mode nobody warns you about

Here is the one that actually costs money: a draft that sounds more confident than your scope.

You gave it a rough scope and a rough number. It returned a document that reads like a fully specified engagement — tight language, clear deliverables, no visible uncertainty. It is a better-written document than the underlying decision deserves.

Send that, and you have made a commitment the document is not grounded in. The client reads precision and holds you to it. Week six arrives, the vague part of your scope becomes an expensive argument, and the proposal you sent is the proof that you agreed to more than you intended.

The fix is not better writing. It is a rule: before sending, re-read for any sentence that commits you to something you did not decide. Delete it or decide it. A proposal with three visible open questions is safer than a polished one with none — because the open questions are real, and the client will find them either in the document or in delivery.

This is the general shape of the problem with drafting tools. They are very good at producing the appearance of certainty from incomplete input. The appearance is useful only when the input was complete.

The assembly order that works

The sequence matters, because each step constrains the next.

Decide the four blocks. Write them by hand, badly, in bullet points. No prose.

Draft one section at a time, not the whole document. Ask for the scope section, check it against your list, correct it, then move on. A whole-document draft is harder to audit because the errors are spread across a polished surface.

Ruthlessly delete anything you didn't decide. This is the step that takes the longest, and it is the step that makes the draft safe.

Write the price paragraph yourself. Do not delegate the sentence that states the number. It is the one sentence where a generic drafting voice does real damage, because hedging is exactly what it defaults to.

Write the exclusions list last, and read it first. Exclusions are where the money leaks. If you read your own proposal and can't find a clear statement of what's not included, the client won't find one either.

What the model is actually good at

Being precise about it: it is good at restructuring, at consistency, at turning a bulleted scope into prose that reads evenly, at noticing that you described the same deliverable two different ways, and at producing a version that doesn't sound like it was written in a hurry at night.

It is not good at knowing your client, your market, your costs, or what your scope should be. It has no access to the conversation where the real constraints were stated. If a section needs that knowledge, it will produce something plausible instead of asking — unless you tell it to ask.

That distinction is the whole method. Delegate the transcription. Keep the decisions. The time saved is real — the drafting genuinely does collapse — but the time saved is not the point. The point is that separating decision from transcription makes it obvious which parts of your proposal you were never sure about.

A note on where this does not apply

If your proposals are won on relationship and the document is a formality, none of this matters much. If your proposals are competitive and read alongside three others, the exclusions and assumptions do more work than the prose, and those are precisely the parts no model can supply.

And if the four blocks take you three days to write, that is the finding. The drafting tool did you a favour by exposing it before you sent anything.

The workflow described here is a method, not a measured result. No time savings are claimed, because none were measured. Where figures appear they are illustrative examples of the arithmetic, not market data.

Related notes