How AI Reads an RFP into a Warehouse Quote

A warehouse tender arrives as a 30-page PDF with a volume annexure buried on page 19. Somewhere in there are the forty or so numbers that will drive your entire cost model. Getting them out of the document and into a costing engine is one of the most tedious and error-prone hours in the whole tender process — and it is exactly the kind of work an AI can do well, provided it is built to admit what it doesn't know.

What "reading a tender" actually means

This is not summarisation. Nobody needs an AI to tell them a tender is about warehousing. What a costing team needs is extraction: locating specific named quantities in an unstructured document and mapping them onto the fields of a cost model.

A typical warehouse RFP contains somewhere between fifteen and fifty operating figures worth capturing:

• Inbound — pallets received, containers by size, cartons received, ASNs or inbound orders per year
• Outbound — orders, order lines and units by channel, cartons packed, pallets despatched
• Storage — average pallets on hand, oversize or dangerous-goods pallets, active SKU count, pick-face and bulk locations
• Other work — returns, value-added services, cycle counts, replenishment
• Contract shape — site size, start date, term, temperature requirements, dangerous-goods handling

Each one has to land in the right field, in the right unit, on the right basis. Get one wrong and every downstream number — headcount, equipment, space, rate card — is wrong with it.

The three ways naive extraction fails

1. It invents a number

The single most dangerous failure. A general-purpose model asked to "fill in the volume fields" will happily produce a plausible figure for a field the document never mentioned, because producing text is what it does. In a tender that number becomes a headcount, becomes a rate, becomes a price you are contractually bound to.

2. It confuses the unit

Tenders quote weekly, monthly and annual figures in the same table, and rarely label them consistently. "6,200 orders" is a very different cost model depending on whether that is a week or a month. Extraction has to normalise to the model's basis — and record which conversion it applied.

3. It picks the wrong basis

This one is subtle and it is the one that costs money. Consider a tender that says:

Two numbers, both correct, both about outbound orders per week. A model that grabs the last number it saw, or the biggest number it saw, prices the contract on peak volume: roughly 15% too much labour, too much equipment, and a rate card that is uncompetitive on every line. A model that takes the average and separately flags the peak gives the pricing team what they actually need — the base case, plus a note that peak capacity is a conversation to have.

Confidence bands: the honest interface

Not every extracted figure deserves equal trust, and pretending otherwise is how errors get through. A workable design grades every reading into three states:

The third row is the important one. A blank field is a question a person will ask the customer. A wrong field is a question nobody asks until the contract is running.

Citations, not assertions

Every extracted figure should arrive with the line of the document it came from. This costs nothing to implement and changes the review from an act of faith into an act of checking. A reviewer scanning forty figures with quoted sources can clear the list in five minutes; the same reviewer scanning forty bare numbers has to open the PDF and start again.

It also settles disputes later. When a rate is challenged eighteen months into a contract, "the tender said 6,200 orders per week on page 19" is a much better answer than "that's what we were told at the time".

What AI should not be asked to extract

A tender describes the customer's world: their volumes, their channels, their service requirements. It says nothing about yours. The operator-side inputs — productivity rates, enterprise agreement rates, rent per square metre, equipment costs, on-cost percentages, overhead structure — must come from your own site and register data, never from the document.

This split matters because it defines the boundary of the AI's job. It fills the customer half of the model. Your platform supplies the operator half. Nobody should be extracting a pick rate from a customer's RFP.

The human stays in the loop — structurally

Extraction should end at a review screen, not at a saved quote. When the reviewer accepts a figure, that acceptance ought to behave exactly like any other edit made by a person: recorded in the change log against their name, triggering a full recalculation, obeying every permission, lock and approval rule the platform already enforces.

Built that way, the AI adds no new risk surface. It types faster than a person; it doesn't get any extra authority for doing so.

What this actually saves

The time saving is real but it is not the main prize. Re-keying forty figures takes perhaps an hour; checking them takes another. Halving that is worth having.

The bigger prize is consistency of interpretation. When four different estimators read the same tender, they make four slightly different judgement calls about which number is the base case, what counts as an order line, and whether returns were included in the outbound figure. Those judgement calls are invisible and they move prices by several percent. An extraction step that applies the same rules every time, and shows its working, removes a source of variance nobody was measuring.

Seven questions to ask any extraction AI

1. Does it show me the source line for every figure?
2. Does it leave fields blank, or does it always produce something?
3. How does it handle average versus peak, and does it tell me both exist?
4. Does it normalise units, and does it say which conversion it applied?
5. Can I see and change every value before anything is saved?
6. Does applying a value go through the same audit trail as a manual edit?
7. Is my tender document used to train a model, or only to build my quote?

An extraction tool that answers those seven well is a genuine productivity gain. One that can't answer the second and third is a liability dressed as a feature.

The principle

Reading a tender is a mechanical task with a high cost of error. That is precisely the profile of work worth automating — as long as the automation is built to be checked. Cite every number, grade every reading, drop what isn't there, and leave the decision with a person. Done that way, an hour of transcription becomes five minutes of review, and the numbers underneath the quote are better than they were before.