Blueprint: a go/no-go screen for incoming tenders

A tender arrives as a document, and the chain described here reads it and says whether it is worth a human day of proposal writing at all.

Sales and bid teams rarely ask how to write proposals faster. They ask the quieter question: which of these inquiries are worth answering at all.

The screening decision

The decision is go, no-go, or unclear, made before anyone opens a proposal template. A tender or RFP arrives with a fixed set of things that can make a bid impossible: a submission date, required certificates, a minimum number of comparable references, a contract volume, and the exclusion grounds it names. Those are checkable in minutes and get checked in hours, by whoever happens to have the document open.

The cost of skipping the check is asymmetric. A no-go found on day one costs an hour. A no-go found on day six, after two people have written a technical concept, costs the week and the thing they were not doing instead.

The submission clock

The deadline is the criterion that can settle a case on its own, and in EU public procurement it is written down rather than negotiated.

In an open procedure, the minimum time limit for receipt of tenders is 35 days from the date the contract notice was sent, reducible by five days where electronic submission is accepted, and to no less than 15 days in duly substantiated urgency.

Directive 2014/24/EU, Article 27. Described here as a floor that a screen can read, not as advice on any specific procedure. On 9 September 2026 the Commission proposed a Public Procurement Act, COM(2026) 590, that would replace the directive with a regulation once Parliament and Council adopt it.

Those 35 days are a floor, not the date on the document in front of you, and the document is what the chain reads. The directive does say how the window runs: it starts the day the notice went out, not the day the mail arrived. A document that sat three days in a shared mailbox has used more than 8 percent of it before anyone opened it.

The chain, stage by stage

Six stages, each handing structured data to the next. The orchestration layer is n8n, which is the same layer we use for email triage and for screening lead lists before enrichment. The ordering principle is identical to that pipeline: the cheap deterministic checks run before anything expensive or interpretive.

1. Trigger: a shared tender inbox. One address, not a salesperson’s personal mailbox. A trigger hung on a person is an outage as soon as that person takes a week off. Attachments get pulled out, the mail body is kept as context, and both are stored with a case ID before any processing starts.

2. Parse the document. Tender documents are PDFs, sometimes scans, frequently with the criteria in tables. Mistral OCR 4.1, released 16 July 2026 and the replacement for OCR 4 since its deprecation on 29 September 2026, returns markdown plus a paragraph-level bounding box per block, a structural label, and confidence scores per page, per block or per word. Two of those matter downstream: the box is how a verdict later points at a place in the document, and the per-word confidence separates a badly scanned line from a criterion that is genuinely absent.

3. Extract the must-criteria. The model reads the parsed document and fills a fixed schema, one field per criterion: submission deadline, required certificates, reference requirements, volume and duration, lots, exclusion grounds. Two rules make the stage usable. The schema is fixed, so a missing criterion comes back as null instead of as a plausible sentence, and every filled field carries a page number plus the verbatim sentence it came from.

4. Run the hard gates in code. Deterministic booleans, evaluated outside the model: deadline against available capacity, certificate held or not, references of the required size and number, volume inside the band. These read from systems that already know the answer, a certificate register and a reference list, and they either pass or fail. A model that can be talked out of a missing certificate is worse than no check.

5. The verdict. Go, no-go or unclear, with one line of reasoning per criterion and the citation attached. A no-go names the criterion that killed it, an unclear names what it could not read.

6. Sign-off and filing. A human opens the verdict, agrees or overrides, and only then does the case move in the CRM. The record keeps the verdict, the criteria table and the page citations, so the next person to touch that customer can see why a bid was skipped eight months ago.

Nothing in this chain sends anything. It does not decline a tender, it does not write to the contracting authority, and it does not close the case by itself. That is a design decision, and it is the reason a chain like this stays switched on.

The citation requirement

A citation requirement means every extracted field carries the page and the exact sentence it came from, and a field without one counts as empty. Without it, the bid manager re-reads the document anyway, and then the screen has saved nothing.

Enforcing it is cheap. The parser already returns a bounding box per block, so the page reference is a lookup rather than a guess, and a required citation property in the output schema means a field arrives either with evidence or as null.

Requiring a quotation does not make the extraction correct, it makes it auditable. A wrong page number is visible in two seconds, which is the whole benefit: the failure mode becomes one a reviewer catches rather than one that travels into a bid decision.

The three verdicts

Three outcomes, because the interesting one is the third. Go and no-go are what a complete criteria table produces. Unclear is what it produces when a required criterion could not be read, when two parts of the document disagree, or when a gate depends on something no system holds.

Unclear cases stay put, in a queue with the reason and the page, and a human resolves them. The temptation is to let the model guess and mark the guess as low confidence, which produces a pile of low-confidence guesses nobody works through. A queue of four unresolved documents gets worked, a list of forty scored ones does not.

When the unclear share climbs, the cause is usually in the document, not the model: a new contracting authority with a different template, criteria in an annex the parse never received, a scan that lost a table. Each is fixable at the parse stage. None of them at the prompt.

Failure modes

The annex nobody sent. Criteria live in the attachment of the attachment: a specification referenced by the tender document, a separate form listing required certificates. The chain reads what arrived in the mail, and a criteria table built from three of five documents looks complete. Count referenced documents against the ones you have and let a shortfall force an unclear verdict.

Scans, specifically old ones. A text PDF is unremarkable to parse. A faxed and rescanned specification with a stamp across a table is where per-word confidence earns its place: set a floor and route a page under it to a human instead of extracting from it.

Volume and lots. A tender split into lots has a different volume per lot, and the number a naive extraction picks up is the total. That is the error behind a go on something four times the size of anything the company has delivered. Extract per lot or mark the field unclear.

Dates that are not the deadline. A tender document carries a notice date, a question deadline, a site visit, a submission deadline and a contract start, often in the same table. Picking the wrong one is the most consequential extraction error in the chain. Require the quoted sentence and keep a fixed set of test documents with known answers to run after any change to the model or the prompt.

The screen becomes a filter for inconvenient work. This failure is organisational. A no-go with reasoning attached is comfortable to accept, and a screen tuned slightly tight quietly stops a company bidding on anything unfamiliar. Track no-gos with their reason and read the list monthly.

Running cost

Three lines, and the document parsing is the largest of them. Prices below as retrieved on 1 October 2026.

Parsing. Mistral OCR 4.1 is listed at $4 per 1,000 pages, halved to $2 through the Batch API and its 50 percent discount, so a 90-page tender is around 36 cents. Amazon Textract prices the same job differently: $1.50 per 1,000 pages for plain text extraction in US West, $15 per 1,000 pages for its Queries feature, and 1,000 free text-extraction pages a month for the first three months on a new AWS account.

The model. Anthropic documents a PDF request ceiling of 32 MB per request and 600 pages, or 100 pages if the context window is under 1M tokens. It estimates 1,500 to 3,000 tokens per page. At the upper end, that same 90-page tender is roughly 270,000 input tokens, about 54 cents on Claude Sonnet 5.5 at $2 per million input tokens. Parse plus verdict lands under a dollar, which makes the page ceiling the constraint worth designing around rather than the price.

Orchestration. n8n Cloud starts at €20 per month for 2,500 workflow executions and €50 for 10,000, billed annually; the self-hosted Community Edition is free, with features including Git version control and SSO reserved for paid plans. Our n8n review covers that layer.

The number worth tracking is in none of those three lines: the share of arriving tenders that reach a proposal writer, and how many of those the writer calls a fit.

Frequently asked questions