The output is good. The document is wrong.

You paste the discovery transcript, the client brief, and last quarter's similar proposal into a chat window. You ask for a proposal. Ninety seconds later you have 1,600 words of clean, confident, well-organised prose.

Then you start reading it properly. The section order isn't yours. There's no assumptions section, and your firm has put an assumptions section in every proposal for eleven years because of one bad engagement in 2015. The scope description is a paragraph where your template wants a deliverables table with acceptance criteria per line. Two of the numbers are confidently stated and you have no idea where they came from. The tone is nobody's. And the client's own term for their platform, which appears fourteen times in the brief, has been silently replaced with the generic industry word.

So you spend the afternoon doing what you always do: restructuring, re-sourcing, rewriting the voice, hunting for the invented facts. The draft saved you the blank page and cost you an audit. Most firms run this loop three or four times, decide AI “isn't there yet” for real deliverables, and go back to copying last quarter's file.

The conclusion is wrong. The models are more than good enough to write a proposal. What the chat window can't do is hold a document that has a shape.

A structured document is not long text

This is the whole problem in one sentence, so it's worth being precise about it. When you deliver a tender response or a post-implementation review, the words are only part of what you're delivering. The document also carries:

A fixed section set, often mandated by someone else. A Commonwealth panel RFT tells you exactly which response schedules exist and in what order.
Dependencies between sections. Your scope statement constrains your pricing. Your findings constrain your recommendations. Your assumptions constrain both.
Required inputs per section. A commercial terms section that doesn't state payment milestones is not a short section. It's an incomplete one.
A firm-specific bar. Not “is this good writing” but “is this what a good version of this document looks like at this firm”.
A relationship to evidence. Every claim traces back to the brief, the transcript, the control evidence, or a human decision someone can name.

A chat window represents none of that. It has one representation available: a conversation, and inside it, text. Anything you want it to honour has to be re-described in the prompt, in prose, every single time, and the model has to weigh those instructions against everything else in the context.

The five failures, and where each one comes from

1. It proposes a structure instead of honouring one

Ask for a proposal and you get the model's median proposal: executive summary, understanding, approach, timeline, team, pricing. It's a reasonable structure. It isn't your structure, and when the buyer is scoring against a mandated schedule list, a reasonable structure is a non-conformance.

You can paste your headings in. It will follow them for the first few sections and then drift, because the headings were an instruction in a context window competing with 40 pages of source material, not a constraint on the object being built.

2. It writes every section as if it were the only section

A one-shot draft is generated in a single pass, so the tenth section was written without knowing what you decided to say in the third. The visible symptom is repetition: the same three points appear in the executive summary, the approach, and the closing, each phrased slightly differently. The expensive symptom is contradiction. The scope section says configuration only, the risks section quietly assumes a data migration, and nobody catches it until the client does.

We ran the same 22-page proposal both ways and wrote up the side-by-side in section-by-section vs one-shot drafting. One-shot is forty seconds to a draft and most of a day to a deliverable.

3. It has no concept of missing information

This is the one that costs firms real money. A chat model is trained to produce the most plausible continuation of the text. If your source material doesn't say how many sites are in scope, “across your twelve sites” is a perfectly plausible continuation. It reads as fact, sits inside an otherwise accurate paragraph, and survives review because the paragraph around it is correct.

The tool isn't lying to you. It has no slot labelled “number of sites, required, not yet known”, so there is nothing for it to report as missing. Gaps only become visible when the workflow tracks what each section needs before it drafts.

4. Your firm's standard exists nowhere it can reach

The way your firm writes a findings section (evidence first, implication second, never a recommendation inside a finding) lives in two or three senior heads and shows up as review comments. A chat tool can't apply a standard it has never been given, and re-typing it into every prompt isn't a standard, it's a habit that one person has and four don't. We wrote about treating this as an asset rather than folklore in templates as institutional memory.

5. Nothing carries to the next document

The most under-rated failure. You spend forty minutes wrestling a chat thread into producing one genuinely good SOW. Next Tuesday, different engagement, and you start from zero. Whatever you learned is in a thread nobody else will open. Generic tools let you reuse the prose (copy, paste, find and replace the client name) and never the standard that produced it. That's the same reuse model as the shared drive, with extra steps.

What the workflow has to hold instead

None of the five failures is fixed by a better prompt or a bigger model. They're fixed by giving the workflow somewhere to put the things a chat window can't represent.

A template that executes, not describes. Sections and sub-sections in a fixed order, per-section guidelines, criticality (must-have versus nice-to-have), a target length, and the information each section requires before it can be drafted. The section set is a property of the object, so it can't drift.
Workspace-level voice, glossary, and author identity. Captured once from a document you've already delivered, then applied to every draft after it. The glossary is what stops the client's platform name being replaced by the generic industry word.
Sources the draft is grounded in. Transcripts, briefs, RFP packs, prior deliverables, technical references, attached to the document being drafted rather than pasted into a message.
Section-by-section generation with a review gate. Each section sees the earlier ones, including your edits, so a correction you make in section three is context for section ten instead of a comment nobody reads.
A clarifications loop. When the sources don't answer something the section needs, the workflow asks you, and your answer becomes context for everything that follows. That is the mechanical difference between a tool that fills gaps and one that reports them.

The how-it-works walkthrough covers the mechanics end to end, and use cases shows the shape per document type.

The same job, run properly

A four-person infrastructure consultancy responds to a health department RFT for network refresh services. Eleven response schedules, mandated order, a 30-page limit, and a compliance table that has to cite the tenderer's own certifications by number.

In a chat window, that's eleven separate threads or one enormous one, a running mental list of which schedules are done, and a final assembly job in Word that takes an afternoon on its own. The bid manager becomes the integration layer.

With the structure held by the workflow, the eleven schedules are the template. The RFT pack and the firm's last two successful network tenders are the sources. Schedule 4 drafts and, because the template says the compliance table requires certification numbers and expiry dates, the workflow asks for the two that aren't in the sources rather than producing convincing numbers. Schedule 7 drafts knowing exactly what Schedule 4 committed to. The bid manager reviews each schedule as it lands instead of auditing thirty pages at midnight, and the export is already the document, not raw material for one.

The time saved is real, but it isn't the point. The point is that the failure modes changed. You are no longer hunting for invented facts inside fluent paragraphs. You are answering questions the workflow asked you on purpose.

What chat tools are still genuinely good at

This isn't an argument that general-purpose AI is useless. We use it daily, and so should you, for the jobs it's shaped for: thinking out loud before you know your line of argument, pressure testing a recommendation, rewriting one stubborn paragraph, turning rough notes into three options you can react to, summarising a document you don't have time to read.

Every one of those is an unstructured task with a human reading the output immediately. That's exactly the shape a chat window fits. The mistake is assuming that a tool which is excellent at unstructured work will also be adequate at structured work, because both come out as words on a screen.

A test you can run this week

Take the last document your firm delivered that started as an AI draft. Open the AI version and the delivered version side by side, and sort every change you made into four buckets:

Structure. Sections added, removed, reordered, or reshaped from prose into a table.
Facts. Anything you corrected, deleted, or had to go and verify.
Standard. Changes that made it sound like your firm rather than a firm.
Actual writing. A sentence that was simply better after you touched it.

If the fourth bucket is the biggest, the model was the limitation and a better model will help you. In every review we've run with a pilot firm, the fourth bucket is the smallest by a distance. The first three are the tax you pay for using a tool that had no way to know your structure, your sources, or your standard, and the first three are the ones that don't get cheaper as models improve. They get cheaper when the workflow finally has somewhere to put them.