A commercial builder was writing every tender by hand, copying from old proposals and hoping nothing stale slipped through. We built them a tender writing system on Claude that reads the buyer's pack, answers every criterion in the buyer's own words, draws only on the builder's own past work, and flags anything it can't prove. Their preconstruction team now runs live tenders through it every day.
Client
Commercial builder (name withheld)
Industry
Commercial Construction
Tools Used
1,800+
Pages of past proposals
turned into a searchable library
3
Blind tests against tenders
the team had already lodged
0
Invented facts across
every test
The Problem
Tenders are how this builder wins work, and each one is a long document: methodology, programme, team, past projects, risk, quality, safety, all answered against criteria the buyer sets. The person writing them is also running preconstruction. There's never enough time.
So proposals were built the way most builders build them: open the last good one and start editing. When we read through their past submissions, that habit showed. Another job's client name in the text. A misspelled photo caption repeated across 16 proposals. Staff surnames spelled two different ways. Project values that disagreed from one tender to the next.
And they'd seen what generic AI does with a tender. It writes confidently about projects that don't exist and promises things nobody agreed to. For a builder, one invented claim in a submission is worse than no AI at all.
The Solution
We took every proposal they'd lodged, more than 1,800 pages, and split it into 525 sections filed under eight criterion types. On top of that sits a facts file (accreditations, insurances, projects, referees, the team), an answer bank for each criterion, and their brand.
The tender writer opens it in Claude and types one of three commands. That's the whole interface. It drafts from that library and nothing else. If a fact isn't in their own documents, it doesn't go in the tender. It gets flagged for a person to answer.
What happens automatically
Reads the whole tender pack and finds the documents that matter among the drawings
Maps every criterion and sub-question in the buyer's exact words
Asks about ten questions, each with the likely answer already filled in
Drafts every answer and builds the proposal in the builder's own layout
The team answers the flags, edits, and lodges it themselves
How It Works
New tender: drop the pack in
Tender packs arrive as gigabytes of drawings with a handful of documents that actually matter. The system unpacks nested zips, finds the request, response forms, conditions and addenda, and reads them. It then counts every bullet in every criterion, so nothing the buyer asked for gets missed. On one real pack it found 46 separate asks where the filled-in form showed only 34.
A short list of questions, already answered
Before drafting, it checks the builder's history with this buyer, the products the buyer names against usual lead times, the insurance required against the current certificates, and which team and case studies fit best. The tender writer gets about ten questions with answers pre-filled and replies "all good" or corrects them by number.
A full draft, built to print
Every criterion is answered in order, in the buyer's words, then built into a branded PDF that matches the builder's own proposals, plus an InDesign file for final polish. Where the buyer supplies a Word response form, it fills a copy. Changes are made by saying them: "page 18, use this photo."
Score, then close out
A score command checks a draft against the buyer's criteria. After lodging, a two-minute close-out feeds the final proposal back into the library and records the result. Any rule someone teaches it ("we never promise that outside our main region") is saved for the whole team, so the next tender starts smarter than the last.
Key Design Decisions
No source, no claim
Every statement has to trace back to the builder's own documents. Where their past proposals disagreed with each other on a project value, it doesn't pick one. It flags it for the team to settle once.
It never prices, sends or signs
No estimates, rates or quantities, ever. It never submits, emails or uploads anything, and declarations stay with a person. It writes. People decide and lodge.
It writes the way they write
We measured their house style from real proposals: sentence length, how often they name the company, punctuation. Their writing used an em dash about once every 6,000 words. An early machine draft used 17 per 1,000. A voice check now fails any draft that doesn't sound like them.
Feedback becomes rules
When the managing director read the first draft, they asked for dot points over long paragraphs and no table split across a page. Each comment became a rule or an automatic check, so it was fixed for every future tender, not just that one.
One shared brain for the team
The system lives in a private repository the builder owns. It updates itself when a session opens and saves after every reply, so a fact one person corrects is there for everyone the next morning. Nobody has to learn Git.
Tested blind before go-live
We ran it on three tenders the builder had already lodged, with their real answer hidden from the system, then compared criterion by criterion. Every gap it lost on became a fix before the team used it live.
The Results
Before
Each tender started from the last one
copy, paste and hope nothing stale survives
Old errors repeated across proposals
other clients' names, misspellings, mismatched values
Criteria easy to under-read
a missed sub-question costs points nobody sees
Knowledge in one person's head
lessons from each tender weren't kept anywhere
After
Two live tenders drafted in a day
every criterion answered, flags listed for the team
Every claim traced to a source
zero invented facts across three blind tests
Same picks as the team, made blind
the same three case studies and seven people they chose
A system the whole team adds to daily
corrections saved once, used on every tender after
The Numbers
36
Past proposals in the library
525
Sections filed under eight criterion types
3
Commands the tender writer needs to know
0
Prices, estimates or submissions made by the AI
The Impact
The tender writer no longer starts from a blank page or last month's proposal. They start from a complete draft that answers every question the buyer asked, built from what the company has actually done, with a short list of things only they can answer. In one blind test it also caught an insurance requirement the lodged submission had fallen short of, the kind of conformance gap that can knock a tender out before anyone reads the methodology.
The bigger change is what happens after each tender. Every correction, every rule, every result goes back in. The team's knowledge used to walk out the door at five o'clock. Now it's in a system they own, and the managing director and preconstruction team add to it every day.