Treadstone Associates
Article · Proposals

Writing business proposals faster with AI

Most proposal time is not spent writing. It is spent rebuilding things the firm has already written, and that is the part worth attacking.

Treadstone Associates · Updated 2026

Key takeaways

  • • The bottleneck is usually reassembly, not composition.
  • • Build an approved component library before you build a prompt.
  • • A tight brief with named inputs beats a clever instruction every time.
  • • Never let the tool set the price, and never let it invent a reference.

Where proposal time actually goes

Sit with a partner through one proposal and the pattern is consistent: a short burst of genuine thinking about the client’s problem and the approach, then hours of hunting for the right version of the methodology section, the right project summary, the right team biography, and reformatting all of it.

The thinking is the valuable part and it is the smaller part. Everything around it is retrieval and assembly, which is why proposal turnaround responds so well to structure and so poorly to writing faster.

This also explains why firms that buy a drafting tool and see no improvement usually have no library to draft from. The tool then generates new text each time, which is slower to check than reusing text that was already approved.

Build the component library first

Take your last twenty proposals and extract the reusable blocks: methodology by service line, sector-specific context paragraphs, team biographies, past-project summaries, assumptions and exclusions, fee-basis explanations, and your standard terms references.

Approve each block once. Version and date them. Record any constraint attached to a block — for instance, a project summary that may only be used with the client’s consent, or a credential that applies to one named individual.

This is a two-day exercise that most firms defer indefinitely, and it is the single highest-return step. Everything downstream gets faster and safer because the tool is selecting from approved material rather than authoring new material.

The brief you give the model

A good brief names the inputs and the constraints. Inputs: the client’s stated problem in their own words, the service line, the sector, the constraints on timing and budget, the named team, and the specific components to use. Constraints: no new figures, no client names not on the approved list, no claims about outcomes, keep exclusions verbatim.

Explicitly instruct that anything missing should be marked as a gap rather than filled. A draft with five bracketed gaps is far more useful than one with five plausible inventions, and the gaps are where the partner’s attention should go anyway.

Keep the brief in version control alongside the component library. When a proposal goes wrong, the brief is usually where the diagnosis is.

The three-pass review

Pass one — facts. Every number, name, date and credential traced to a source you hold. Untraceable content is removed. This is where the legal exposure sits: section 74.01 of the Competition Act provides that a statement, warranty or guarantee of performance must be based on an adequate and proper test, and that the proof of it lies on the person making the representation.Pass two — scope and price. Deliverables, exclusions, assumptions, dependencies and the change process. Read them as a client in a dispute would. Also check the price is presented in full; representing a price that is not attainable because of fixed obligatory charges is addressed directly in section 52(1.3) and in the drip-pricing rules.Pass three — tone. Generated proposal text has a recognisable register: confident, general, slightly overwritten. Clients notice. Cut the adjectives and the summarising sentences that restate the previous paragraph.

What must never be automated

The price. Pricing carries judgment about risk, capacity and the relationship that no model has access to, and a wrong price is not a drafting error — it is a commercial one you are then bound to.

The references. Naming a client is a confidentiality question governed by what you agreed with that client, and a tool cannot know your consent history.

The decision to bid. Deciding whether to pursue work is a judgment about fit, conflicts and capacity. If anything, faster proposals make this more important, because the cost of a bad bid falls and the volume of bad bids rises.

Measuring whether it worked

Track three numbers against your current baseline: elapsed hours from brief to sent proposal, the number of partner review cycles per proposal, and the win rate by service line.

The first two should move within a month. The third should not move at all — if it drops, the drafts are reading as generic and the component library needs sharper sector-specific material, not a better tool.

Once the proposal is accepted it becomes the working scope, so make sure the accepted document and your contract agree: key clauses in a service agreement and statement of work versus master agreement cover the structures worth using.

Questions we get asked

How much faster is realistic?
We will not quote a figure, because it depends entirely on how much of your material is already reusable. Measure your own baseline first — hours to send, and review cycles per proposal — and compare against it.

Will clients be able to tell?
They can tell generic writing from specific writing. The fix is a better component library and a sharper brief, not a different model.

Should we use it for public-sector RFPs?
The compliance matrix work suits it well. Be stricter than usual on claims and credentials, since public procurement responses are scrutinised line by line.

See where AI pays off first in your firm.

A 30-minute call is enough to tell you whether AI pays for itself here.