AI for RFP responses in government: scoring criteria, mandatory returns and the portal deadline
The portal closes at eleven in the morning. It is the evening before, and four people are working on the same submission. One is retyping the registration details and insurance figures into a selection questionnaire for the fourth time this quarter, because the portal will not accept an attachment there. One is cutting a good answer down to the length the template allows, and losing the part that made it good. One has found three versions of the environmental policy and cannot tell which is signed. One has just read the clarification log and realised one of the buyer's published answers changes an assumption two drafted answers rest on.
Nobody in that room is short of ability. They are short of a system. The work is not really writing. It is assembling a compliant document out of material the organisation already owns, against a marking scheme somebody else wrote, on a fixed deadline.
Why a public tender is scored, not read
A commercial proposal is persuasion. You can build rapport, follow up, and recover from a weak section with a good meeting. A public tender is closer to an examination. The criteria are published in advance, usually with weightings and often sub points, and the panel has to justify every mark it gives.
One consequence most bid teams underuse: the answer that wins is not the answer that reads best. It is the answer that visibly addresses every published sub point, in the order the buyer asked, in language the panel can match to its own marking notes. A paragraph the team is proud of, which does not map to anything being marked, scores nothing.
The second consequence is harsher. Much of the pack is pass or fail before anyone reads the quality answers at all. A missing signature, an unanswered mandatory field, a document in the wrong format, a file over the size limit, a declaration left unticked. A strong bid can be set aside on a formality, and the buyer often has very little discretion to let you fix it afterwards.
Reading the tender pack into a checklist
A tender pack is rarely one document. It is instructions to bidders, a specification, a selection questionnaire, response templates, a pricing schedule, terms and conditions, sometimes a social value framework, and a timetable that includes a clarification deadline nobody diarises.
The first genuinely useful thing an AI system does here is read the whole set and produce one structured list: every requirement, every question with its word or character limit, every document to be returned and in what format, every mandatory field, every date. Each line points back at the clause it came from.
That back reference is the point. A checklist produced by hand has to be trusted. One where every line cites its source can be verified in an hour, and rebuilt and compared the moment the pack is reissued.
Selection questionnaires and the facts you retype
Every public bidder answers the same corporate questions repeatedly. Legal entity and registration details. Turnover for the last three financial years. Insurance types, levels and expiry dates. Prior enforcement action or contract termination. Health and safety, equality, modern slavery, data protection and information security arrangements.
The facts do not change between tenders. The shape of the question does, along with the length allowed and the evidence to attach. This is the cleanest automation in the process, because the mapping is mechanical: match each question to the maintained corporate record, fit it to the length asked for, and produce the attachment list with expiry dates checked.
What goes wrong is almost never the prose. It is a figure from last year's accounts, a superseded policy version, a certificate that expired six weeks ago, or an answer trimmed by hand at midnight until it no longer says the thing that earned the mark.
An approved content library, mapped to the criteria
Reuse is not the problem. Unchecked reuse is. Most bid libraries hold passages that were true of the contract they were written for and are not true of this one, and claims nobody currently in the team can stand behind.
The structure worth building is a library where each passage has an owner, a date, a review cycle and a record of what it is approved to say. A first pass answer is then drafted only from material the organisation has already stood behind, assembled against the published criteria rather than a blank page, with contract specific claims marked for replacement instead of carried across silently.
Flagging where no approved content exists
The more valuable output is the gap list. For this tender, these six questions have approved content that fits. These three need updating. These two have nothing, and somebody with the relevant knowledge has to write them.
That is the behaviour we design for. When the system is not confident, it stops and routes to a named owner rather than producing something plausible. In a scored tender, plausible is the dangerous output, because a confident sentence about a capability you do not have can end up inside a contract.
Limits, formats and the mechanical checks
Word counts, character counts including or excluding spaces, page limits, font requirements, file naming conventions, separate uploads per section. These are trivial to check automatically and still one of the commonest reasons good answers get cut badly or rejected outright. Check every drafted answer against the stated limit before a person reads it, not after.
Social value, sustainability and the promises behind them
These sections carry real weight and are frequently answered badly, because teams write what sounds committed rather than what the organisation can evidence and then deliver. Commitments made here can become contractual reporting obligations, so an answer that overreaches costs you twice.
An AI system helps by drafting from what your organisation has delivered before and refusing to assert what the records do not support, and by checking the answer against each published sub point. These frameworks tend to have several, and it is common to address two of five thoroughly and the rest not at all.
Accreditation, insurance and policy evidence
Most compliance failures in tendering are currency failures. The evidence existed, it was out of date, in the wrong version, or signed by someone who has left.
Keeping it current is ordinary back office work between systems, which is exactly where value sits. A register of every accreditation, licence, insurance certificate and policy, with its expiry, owner and current signed version, monitored continuously rather than assembled in a panic per bid, flagging what is expiring before a tender arrives. Whether a certification is claimed as held is a statement of fact, and a person owns that.
Clarification rounds and published answers
Clarification works differently in public procurement. Questions are usually answered to all bidders, so the published log is a live change to the pack that every competitor sees at once.
Two useful jobs here. First, generate candidate clarification questions from the ambiguities and contradictions found while reading the pack, before the clarification deadline, and let the bid lead choose which to submit. Second, when answers are published, identify which drafted responses and pricing assumptions rest on text that has now changed. The output should be short: these four answers and two pricing lines are affected.
Bid or no bid, with the reasons written down
Framework opportunities and call offs arrive in volume, and triage usually happens in someone's head in ten minutes. A system that scores each opportunity against your own stated criteria, contract value, sector, geography, mandatory requirements you cannot meet, incumbent presence, resource availability, and writes down the reasoning, makes the fast decision consistent and leaves a record you can review at year end. The decision stays with a person. The written reasoning is what makes it reviewable.
The buyer side: packs and consistent evaluation
Buyers have the mirror image of this problem. Tender documents get assembled from previous exercises, so specifications carry forward requirements that no longer apply, criteria and weightings drift out of alignment, and timetables get copied with the old dates in them. Reading a draft pack for internal contradictions, unreferenced attachments, criteria that add up wrongly and inherited requirements is useful, low risk work.
Evaluation is different. Consistency matters, so does fairness, and so does the ability to defend every mark if the process is challenged. An AI system can support that by checking each response has been assessed against every published sub point, by surfacing where two evaluators have diverged widely on the same answer, and by keeping a complete record of who assessed what and when. It must not produce a score. Evaluation is a judgement the named panel owns, and automation without an audit trail is automation you are not allowed to keep.
Where AI fails here
It fills gaps rather than leaving them. Asked about experience you do not have, it produces confident prose. In a scored tender that prose can become a contractual commitment, so every generated passage needs a named person who has confirmed it is true of this organisation and this contract.
It cannot price. Rates, margins, risk allowances and the final number in the pricing schedule are commercial judgement, and treating them as a text generation task is how bidders win work they lose money on.
It must not sign or complete declarations. Statements about accreditation, financial standing, prior conduct and conflicts of interest are assertions the organisation is legally accountable for.
It does not know what the buyer really wants, what the market engagement session revealed, or whether the incumbent can be beaten. It has no view on whether the contract is worth winning.
It will reformat a good answer into a compliant one that has lost the substance, particularly when cutting to a word limit. A person reads the final version.
How to start
Do not pilot this on a live bid. Take a tender you submitted and lost, and run the system over the pack as it arrived. Let it build the requirement and returnables checklist, map the published criteria to the answers you submitted, flag evidence that was out of date, and mark the claims it thinks were carried over from somewhere else.
Then compare against what happened. Did it find the sub point you did not address? Did it catch the expired certificate? Did it invent anything, and would your reviewer have caught it? One tender tells you how the system behaves. Three tell you whether to trust it live.
For public sector work this usually has to run inside your own environment rather than somewhere information governance has not approved, which is how Adopt AI Partners builds it: in your perimeter, measured before launch, owned by your people. If you want the comparison checklist we use for that retrospective run, hello@adoptaipartners.com.