What an RFQ actually contains
An RFQ looks like a document. It is closer to a scattered set of claims, each hiding somewhere else. How engineers read one, and how software should.
An RFQ looks like a document. Treat it as one and it will mislead you. What lands in an inbox is closer to a scattered set of claims: a quantity in the email body, a material in a standard reference, a tolerance in a drawing note, a delivery constraint in a forwarded thread two replies down. The skill of reading one is knowing where each claim hides and which ones are missing.
The four questions
An experienced application engineer reads every request against the same four questions. What is being asked for. In what quantity. To what specification. For what application. Everything else in the document is either evidence for one of those answers or noise, and the fourth question is the one juniors miss: the application, often a single sentence of prose, regularly changes which product is right even when the specification is complete.
| What you need | Where it hides | What goes wrong |
|---|---|---|
| Quantity | The email body, not the attachment | The quote prices the attachment's header quantity and the margin assumptions break |
| Material | A standard reference such as an EN or ASTM grade | A near-equivalent grade is substituted silently and surfaces at goods-in |
| Tolerance | A drawing note or the title block | The expensive one is missed and the part is quoted as standard |
| Application | One line of prose anywhere in the thread | The wrong product is configured perfectly |
| Commercial terms | A forwarded message or the customer's portal | Delivery and certification costs never reach the price |
Summarising is not reading
Most AI applied to documents produces summaries, and a summary is precisely the wrong tool here. Summarising compresses; quoting needs extraction. The job is to pull every attribute out as structured data, quantity as a number with a unit, material as a grade against a standard, each tolerance as a bound, and to keep the link back to the exact words it came from. We call that link a source span, and it is what turns a machine's reading into something an engineer can check in seconds rather than re-read in minutes.
A missing specification is information. It tells you which question to ask before you price.
Reading the way the engineer reads
This is the standard we hold our own extraction to. Kabaido reads a request against the same four questions, returns structured attributes with a source span on every value and abstains where the document is silent, surfacing the gap as a clarification to send back. The engineer stays the judge. The software just does the finding, so judgement is spent on the answer rather than the search.
Sources and method
- How the Kabaido AI reads requests, on this site
- Kabaido market research: the application engineer function map