Customer RFQs Land as PDFs. They Should Leave as Quote Skeletons Before Lunch.

At a contract fabrication shop in central Nebraska, the RFQ inbox is someone’s least favorite part of the morning. Five to eight quote requests come in overnight on a busy week — some from distributors who’ve been sending RFQs in the same format for six years, some from new customers whose PDFs are formatted in ways the shop has never seen before, and occasionally one from an engineering department that has attached a forty-page spec and circled the relevant section with an arrow drawn in Preview. Each one has to be opened, read, interpreted, and entered into the ERP before an estimator can start putting a price together.

At a shop where the estimator is also handling customer calls, coordinating with the floor on lead times, and managing the three quotes that are due today, the RFQ entry work is the thing that gets done between everything else — which means it gets done slowly, at the end of the day, or not until tomorrow morning. Customers whose quotes come in late lose confidence in the relationship before the quote has even been priced.

This is not an exotic problem. It’s the same problem at most Nebraska contract manufacturers who run a quoting operation of any volume. The fix isn’t to hire another person to enter data. It’s to stop entering it manually.

The intake pile every Nebraska manufacturer recognizes

The RFQ pile accumulates for three reasons that reinforce each other.

The first is format variance. Customers don’t fill out a standard form. They send a PDF of their internal quote request, which was formatted for their internal procurement system, not for the shop’s ERP. The fields the estimator needs — part number, quantity, material spec, tolerance, required delivery date, drawing revision level, surface finish — are in different places and labeled differently in every customer’s template. Manual entry is slow because the estimator has to find each field before she can enter it.

The second is the drawing interpretation problem. Some RFQs include engineering drawings. The drawings contain information the estimator needs — material, tolerance, surface finish, special notes — that isn’t in the text of the RFQ itself. Reading and interpreting a drawing takes time even for an experienced estimator, and the time scales with the complexity of the part. A shop running twenty RFQs a week is spending a meaningful share of estimator capacity just on intake, before any actual quoting judgment has been applied.

The third is ERP entry friction. Most ERPs in mid-market manufacturing are built for data that’s already been cleaned and structured. Entering a new part requires creating a part record, linking it to the customer, entering the spec fields, and setting up the quote line. The interface wasn’t designed for high-volume intake from unstructured source documents. It’s designed for the work that comes after intake.

Together, these three factors turn a three-minute task — “the answer is in the document, someone just needs to read it” — into a fifteen-to-forty-minute task per RFQ.

The PDF to spec to quote pattern

The build that addresses this is a structured extraction pipeline with a review step before anything posts to the ERP.

The RFQ PDF comes in through the inbox or is dropped into a monitored folder. The pipeline reads the document — text fields, drawing annotations, specification tables — and produces a structured record: part number or description, quantity tiers if the RFQ has multiple, material specification, tolerance class, required delivery, drawing revision, and any notes flagged as potentially unusual (a tolerance tighter than what the shop routinely holds, a material that’s outside the standard stock list, a delivery requirement that conflicts with current backlog).

The structured record goes to the estimator’s review queue, not directly into the ERP. She sees the extracted fields next to the original document. She corrects anything the extraction got wrong — which, for a well-calibrated pipeline on a familiar customer’s format, is usually nothing or one field — and approves it for posting. The approval takes two to three minutes rather than the original fifteen to forty.

The extraction is calibrated per customer format. A customer who sends RFQs in the same template every time gets a parser tuned to that template. A new customer format gets a generic extraction attempt on the first few quotes, followed by a quick review to confirm the field mappings, and then a tuned parser from that point on. The calibration work front-loads some effort but pays off quickly as volume builds.

Drawing interpretation is the hardest part of the pipeline to fully automate, and it’s handled differently depending on the drawing type. Standard GD&T on a well-formatted engineering drawing is parseable. Scanned hand-drawn sketches with penciled tolerances are flagged for manual review rather than extraction. The system knows what it can read reliably and what it can’t.

Margin guidance from past jobs

Quote skeletons are useful. Quote skeletons with cost history attached are more useful.

The ERP contains the shop’s job history — actual material costs, actual machine time, actual labor by operation — for every part that’s been through the floor. When a new RFQ comes in for a part that’s materially similar to something the shop has already run, that history is a direct input to the quote.

The pipeline can surface: the last three times the shop ran a similar part (same material, similar tolerances, similar quantity tier), the actual cost per unit at each quantity break, the margin achieved on those jobs, and how the current quote’s delivery requirement compares to lead times on prior similar jobs. The estimator doesn’t have to pull this information manually — it’s presented alongside the extracted spec fields in the review queue.

This matters more than it might seem. Estimators at shops without job-cost retrieval are quoting from mental models of what similar parts should cost. Those mental models are accurate for parts the shop runs frequently and less reliable for parts that come in once a year or for customers whose jobs have historically had hidden costs. The historical data doesn’t replace estimator judgment — the estimator still knows things the data doesn’t, like that this particular customer’s tolerance requirements routinely require rework, or that the material spec they’re asking for is currently on a six-week lead time. But it gives the estimator a starting point that reflects what the work actually cost, not what it should cost in theory.

The cost-retrieval piece is the part of the build that tends to produce the most visible return. Shops that have been underpricing similar-part work discover it quickly when the job history is surfaced systematically.

The estimator review that stays

One thing this pattern doesn’t change is where the pricing decision lives.

The estimator reviews the extracted spec, reviews the cost history, applies judgment about current material costs, current machine availability, current backlog pressure, and the customer relationship, and sets the margin. The system doesn’t quote. The estimator quotes. The system reduces the time spent on intake so the estimator has more time for the judgment part.

This distinction is worth holding onto because there’s a version of this pitch — usually from platform vendors — that suggests the AI can close the loop on quoting and send a draft quote to the customer without estimator involvement. At a shop with tightly controlled tolerances, current backlog constraints, and a customer base where relationships matter, that version is not ready. The estimator’s judgment on any given quote is taking in information the system doesn’t have access to: the conversation she had with the customer’s buyer yesterday, the fact that the machine that would normally run this part is scheduled for maintenance next week, the awareness that this customer tends to use quotes as negotiating leverage rather than as firm purchase intent. None of that is in the ERP.

The pipeline handles intake. The estimator handles the quote. Those are both necessary.

What it looks like in a 300-person fabricator

At a 300-person fabrication shop outside Omaha with a quoting team of four, the RFQ volume runs roughly thirty to fifty incoming requests per week during busy periods. Before the pipeline was in place, the team was spending a collective estimate of ten to fifteen hours per week on intake alone — opening PDFs, entering spec fields, pulling up the ERP part-number records, chasing down drawing revisions that weren’t attached to the original RFQ.

In the first month after the pipeline was running, that intake time dropped by most of the manual entry work. Roughly 80 to 85 percent of incoming RFQs from established customers were processed through the pipeline with no manual correction at the review step. New customer formats required some correction in the first one or two quotes and were then calibrated.

The cost-history retrieval surfaced three recurring customer relationships where the shop’s quoted margins had been consistently below actual job cost for similar-part work. The estimating team adjusted the pricing model for those customers on the next round of quotes.

The change the estimators noticed most wasn’t the time savings on intake — it was that by the time they got to the actual quoting work, the information they needed was already organized and in front of them. The job had changed from “gather information and then decide” to “review gathered information and decide.”

For more on how Blue Sage approaches quoting and intake automation for Nebraska manufacturers, see the manufacturing practice.