How to use an AI proposal generator without losing the scope

The scope and the price decide the deal. The prose does not.

A model will paper over the gap you left

Ask an AI proposal generator to write a proposal to “redesign our website” and you get something that reads well in about twenty seconds: an executive summary, a collaborative approach, a why-us section, a number at the bottom. What it will not have is the content that governs the engagement — exactly what you hand over, exactly what you do not, and the test that decides when a deliverable is finished.

Six weeks later someone asks for the sixth page template, or a third round of revisions, or the copywriting you assumed they were doing. You are performing work you never priced, and the only document either side can point at is the one the model wrote.

Every sentence is a promise someone can hold you to

The famous risk with generated text is the invented fact. In a proposal the sharper risk is the invented commitment. The model writes “including ongoing optimisation and support” because thousands of proposals in its training data say that. It is fluent, it is on-brand, and you have just promised an unbounded service for a fixed fee. NIST's generative AI profile treats confidently wrong output as an expected property of these systems, and a proposal is a document where confidently wrong is expensive.

So invert the job. Do not use the generator to produce more words around a thin scope. Use it to force the scope to be precise, then let it write the smallest amount of prose that carries the argument.

Rewrite the one-line scope into things you can be held to

Use this six-step workflow

1. Write the outcome the client is buying, in their words.
2. Convert every activity into a countable deliverable.
3. Write the exclusions before you write any prose.
4. Give each deliverable an acceptance test and a review window.
5. Price the line items in a sheet, then generate the document.
6. Have a lawyer review the terms, then send the PDF.

What the rewrite looks like

“Redesign our website, about 20 pages” is what a client says on a call, and what a generator will happily expand into four pages of prose. Here is what you hand the generator instead.

Notice what disappeared. “About 20 pages” became 22, with a price for the 23rd. “A few rounds of feedback” became two, and then a five-day review window so a silent client cannot stall the milestone. Nothing here is persuasive writing, and all of it is what the argument will be about if there is one.

Give the document the sections that carry weight

Ten sections, and the failure each one prevents

Most templates are ordered by persuasion. Draft yours in order of exposure instead, even if the cover letter still comes first on the page.

If there is an RFP, the RFP owns the structure

Responding to a formal solicitation, stop designing. US public-sector buyers issue solicitations in a prescribed layout — the uniform contract format puts the statement of work in Section C and the evaluation factors in Section M. Read Section M first: it tells you, in the buyer's own words, what your submission will be scored on.

This is where an AI proposal generator is both good and safe. Give it the solicitation and ask for a compliance matrix mapping every instruction and evaluation factor to a section of your response, with unanswered requirements flagged. It is checking coverage against a document, not inventing obligations.

Price the deliverables in a sheet, not in a sentence

The number in the document should be derived, not typed

Build the price as a table with one row per deliverable: role, rate, hours, and a line total. Add a contingency row that names what it covers. Total the rows with a formula. Then write the payment schedule against acceptance events, not against calendar dates — the second instalment falls due when the templates are accepted, not on the 15th.

A live sheet solves a problem specific to proposals: they get revised. If the total is typed into a paragraph, you will eventually send a document whose summary and whose table disagree — and the client will read whichever is lower. If it is a formula over the rows, cutting a deliverable is one edit.

Say which document you are actually sending

An estimate signals the number will move. A quote is a firm price for work that is already defined, which is why it can be short. A proposal defines the work and prices it, which is why it needs the scope, exclusions, and acceptance criteria a quote can leave out. When a client asks for “a quick quote” on work nobody has scoped, what they need is a proposal.

What the generator should actually hand you

Two editable files and one rendering of them

A web preview is not a deliverable. You need an editable document because you will change the price, and an editable sheet because the price is a calculation. In OpenCraft those are two different mechanisms.

• The proposal document is produced in-process: Markdown in, a real .docx out alongside a document-styled HTML preview. No sandbox in that path, and the file in your artifacts is the file you open in Word.
• The pricing sheet runs as a code job in a sandbox using openpyxl, so the cells hold real formulas rather than pasted numbers. Before anything is published, the host recalculates the workbook through LibreOffice and rejects it if any formula resolves to an error or a reconciliation check sheet comes back empty or failing. A broken total does not reach the client because it does not reach you.
• The PDF is rendered from those same files. When the job runs on the Office worker — which the spreadsheet and slides workflows load — the workspace carries LibreOffice, so you ask for the reviewed DOCX and XLSX to be converted right there. The PDF the client receives is therefore a rendering of the file you edited, not a second layout built from the same prompt that can quietly disagree with it.

The workspace persists across turns, so “drop deliverable four and reprice” is a revision of the existing files rather than a fresh generation that loses your edits. Same filename means stacked versions, one per turn, and a failed job publishes nothing — you never get a half-written proposal presented as a finished artifact.

Read the PDF as the client will

Before sending, check that the summary total matches the table total, that the exclusions survived the last edit, that the validity date is in the future, that acceptance criteria are still attached to the right deliverables, and that no placeholder still carries another client's name. You can compare workspaces on how they handle editable files before committing a client document to any of them.

Know when the proposal stops being marketing

A proposal is often an offer, and acceptance can bind you

This is the part the generator will not warn you about. In many jurisdictions a proposal a client accepts can become an enforceable agreement on the terms it contains — including the ones the model added because they sounded professional. Cornell's Legal Information Institute frames acceptance around the offeror's own expectations of how it is communicated, which is why a proposal that says nothing about how it may be accepted creates avoidable ambiguity.

“acceptance should be relayed in a manner authorized, requested, or at least reasonably expected”

Cornell Legal Information Institute

Federal procurement makes the same ideas explicit, and they are a useful model for private work: acceptance is an authorised representative formally approving what was delivered, and only a contracting officer may modify the contract — nobody else's instruction to do extra work counts. Copy that discipline. Name the one person who can accept a deliverable, and state that only a written change note signed by that person moves the scope or the price.

“assumes ownership of existing identified supplies tendered or approves specific services rendered”

FAR 46.101, definition of acceptance

This is not legal advice, and the model is not your lawyer

Nothing here is legal advice, and a generated indemnity, liability cap, IP assignment, warranty, or termination clause is not either. Those terms are where the real exposure sits, they vary by jurisdiction, and a model producing them is pattern-matching, not advising. Have a lawyer review the terms once and reuse the reviewed set; that is far cheaper than reviewing every proposal. If you need to understand the document that follows the accepted proposal, read the AI contract generator workflow next.

Use the right document for the right reader

A pitch deck asks an investor to buy a share of an uncertain future, so it is judged on the size of the opportunity and the credibility of the evidence. A proposal asks a client to buy a defined piece of work at a fixed price, so it is judged on whether you understood the problem and whether the scope is one you can deliver profitably. If you are raising rather than selling, use the AI pitch deck generator workflow instead, or browse the full OpenCraft use-case library.