Job shop quotes stall at RFQ intake, not at pricing

The problem

The person with this problem is the owner or one of a couple of estimators in a job shop of a few dozen people. RFQs arrive by email with PDF drawings, sometimes a STEP file, sometimes a purchase specification full of quality clauses.

Before anyone can price the part, someone has to pull out the part number, revision, material, finish, quantity breaks, due date and the tolerances that drive inspection. They also have to catch the flowdowns: material certs, first article inspection, outside processing, export control markings.

This work costs the shop in two ways. Quotes go out late, and buyers often award to whoever answers first. Worse, a missed flowdown means a job is won at a price that never included the cert, the plating or the extra inspection.

Job shop ERPs have quoting modules, but they assume someone has already typed the data in. Instant-quote platforms handle simple geometry for their own marketplace, not the shop's inbox.

The gap is the reading.

Constraints

• Budget: no IT staff. It has to run on an office machine or cheap hosting, at a small cost per RFQ.
• Skills: the estimator is an expert machinist, not a software user. The output has to land in the spreadsheet or ERP they already use.
• Data: drawings are often scanned, title blocks vary by customer, and past quotes sit in an ERP or spreadsheets with inconsistent part numbers.
• Regulation: export-controlled drawings cannot be sent to an arbitrary cloud API, and customer NDAs limit where files go.
• Trust: an estimator will not use a field they cannot trace back to the drawing.

System design

The pipeline has five parts.

• Intake: watch a shared folder or mailbox, group the email and attachments into one RFQ packet, hash and store the originals.
• Gate: deterministic text search for export control and proprietary markings. A hit routes the packet to a local model or straight to a human.
• Extraction: a vision-capable model reads the drawing pages and email body into a fixed schema. Every field must carry a page and a quoted snippet. A field without a citation stays blank, never guessed.
• Validation: plain code checks material against the shop's material list, parses quantities as numbers, and compares the part number and revision in the email with the title block. Mismatches become flags.
• History: match on normalized part number and customer, then on material, to surface past quotes and actual hours from job history. I would start with plain keys before reaching for embeddings.

The output is a one-page intake sheet with a flowdown checklist, plus a CSV the ERP can import.

The model belongs in exactly one place: reading messy documents. Arithmetic, rates, pricing and the decision to no-quote stay in deterministic code and in the estimator's hands.

Trade-offs

This design does not estimate cycle time or produce a price, so the time saved is bounded to intake. It does not read 3D geometry. The citation rule leaves more fields blank than a looser extractor would, and the local model used for controlled drawings will be weaker.

I accept all of that. The expensive failures in quoting are missed requirements and wrong revisions, not slow arithmetic, and a tool the estimator trusts partially is worth more than one they ignore.

What I would build first

Take a few dozen RFQs the shop has already quoted, so the right answers exist. Run extraction offline and compare each field with what the estimator actually entered, counting missed flowdowns separately from minor field errors.

Ship it as a folder-drop script that writes the intake sheet. No mailbox integration, no ERP writes. If the estimator opens the sheet on their own for a week, the next step is the inbox.

Let the model read the packet and cite where each field came from, and keep every number that leads to a price in deterministic code and a human's hands.