RFQ automation: where AI helps and where human approval still matters

Turning an incoming enquiry into a quotation looks like one task. It is at least four, they fail in different ways, and treating them as a single automation problem is why so many quoting projects disappoint.

Stage one: reading the document

The enquiry arrives as a PDF, a spreadsheet, an email body, or a photograph of a printed page that has been through a scanner and an approval stamp. Getting line items out of that is genuinely well suited to machine reading, and it is the stage where the technology has improved most.

It is also where demonstrations are least honest. Extraction shown on a clean, native, digitally generated PDF with a ruled table tells you almost nothing about how it behaves on a skewed scan with a stamp over the quantity column — and both arrive in the same inbox from the same customer.

The useful measure here is per line item, not per document. A document where nine lines in ten are correct is not ninety per cent successful. It is a quote somebody has to check in full, which costs the same as a quote that was wrong everywhere.

Stage two: deciding what the customer meant

This is the hard one, and it is where most of the value and most of the risk sit. A line reading “2 inch GI elbow heavy 50 nos” has to resolve to a specific item in a catalogue that may contain forty thousand entries, several of which are plausible.

Semantic matching handles this far better than string matching, and it handles it well enough to be useful. But the failure mode is unpleasant: a wrong match is often a confident match. The description was read correctly, the item selected is a real item, the price retrieved for it is a real price, and nothing downstream has any reason to object.

This is the specific argument for human approval, and it is not a legal disclaimer. It is that a confidently wrong line is invisible to every subsequent automated check, so the only place it can be caught is by a person who knows the customer.

Stage three: pricing

Pricing should mostly not be done by a model at all. Retrieving the applicable price for a known item and a known customer is a lookup against rules that already exist — list price, agreed terms, quantity-break tier, standing discount.

Deterministic code is better at this than a model, for the straightforward reason that it behaves identically every time and can be audited when somebody asks why a number came out the way it did. Using a language model where a lookup will do adds variance to the one stage where variance is least acceptable.

The judgement that genuinely belongs to a person is the exception: this customer is strategic, this order is unusually large, this competitor is active this quarter. Those are commercial decisions and they should stay commercial decisions.

Stage four: sending

Nothing should reach a customer without approval. Not because the system cannot produce a good quote, but because the cost asymmetry is extreme: a quote that sits for twenty minutes waiting for review costs almost nothing, and a wrong price sent automatically costs the margin, the rework, and some portion of the relationship.

What a good system actually optimises for

The right target is not autonomy. It is time-to-approve. A system that produces a draft in which every uncertain line is marked, each value shows the source text it came from, and each price shows the rule that produced it, can be confirmed in two minutes by someone who would have spent forty building it.

That is a large saving, it is achievable with current technology, and it does not require claiming anything that is not true. A system that says “I am not sure about line seven” is more valuable than one that is silently confident about all of them.