The technical bid you have already written.

The same question, every time

Open three of your technical bids from the last two years. You will find the same headings: site organisation, quality approach, staffing, waste management, comparable references. Public buyers copy each other, and that is good news for you.

Yet every consultation starts from a blank page. Not because the company lacks method, but because the right paragraph is buried in an eighty-page PDF, in a folder named after a client, on a network share two people know how to navigate.

The worst part is that the version rewritten in a hurry is almost always worse than the one from two years ago. That one had been reviewed by the site manager, corrected after a rejection, and it eventually won. Today’s comes out of a sleepless night.

Finding costs more than writing

When you time a tender response, the writing itself takes a surprisingly small share. The rest goes into four activities that produce nothing new:

• Reading the consultation pack to extract what is really being asked.
• Searching past answers for the one that already covered the subject.
• Checking that the references cited are current, and that certificates have not expired.
• Checking that nothing is missing from the list of documents.

Those four are mechanical, tedious, and exactly the ones an assistant absorbs well. The final writing, the part that commits the company, stays human. It must stay human.

That is the shift to make: you are not buying a machine that writes bids. You are buying a machine that finds, compares, and flags what is missing.

Reading the whole pack

A consultation pack is not a document, it is a bundle: rules of consultation, technical specifications, required answer template, annexes, sometimes a schedule of rates. The information that decides the fate of your bid is spread across it, and the costliest thing to miss is always the same: an administrative document required in annex 4, discovered on the day of submission.

What you want from an automated reading of the pack comes down to three outputs.

• The criteria grid with its weighting. That is what says where to put the effort. A carefully written bid on a criterion that carries little weight is time in the wrong place.
• The required answer template, where there is one. Answering outside it risks being ruled non-compliant, whatever the content.
• The exact list of documents, checked against what you already hold, with validity dates.

None of those three calls for creativity. All three call for exhaustive reading, which nobody does well two days from submission.

The first draft, and the blanks you own

A first draft assembled from your past answers has a property generated text does not: every paragraph knows where it came from. You can open the original bid, see the context it was written in, and decide whether it still holds.

That leaves the interesting case: the subject you have never written about. A consultation asking for your policy on material reuse when you have never had to formalise one.

Two behaviours are possible there. A generic tool fills the gap with plausible prose, and you commit the company to statements nobody has approved. A properly constrained assistant leaves the section blank and flags it. Less comfortable in the moment, and infinitely safer: a technical bid is a contractual document.

The blank has a second virtue. After a few consultations, the list of recurring blanks tells you exactly which positions your company ought to formalise once and for all, away from the deadline.