Two weeks of quoting in two hours

Every engineer-to-order shop keeps the same knowledge in the same places: the customer’s request, the technical specification, the drawings, the cost spreadsheet from that similar project eight months ago, the folder with the proposals that closed. Most systems on the market store and search that material very well.

The work of turning all of it into a price still lives entirely in the heads of two or three people.

This post is what happened when software took that work over — and how we went about measuring whether it did it well.

The cycle nobody puts a stopwatch on

The request arrives by email: between technical specifications, scope narrative and drawings, a hundred pages is common. From there, always the same person:

• reads everything and separates what is asked, what is implied and what is missing;
• assembles the technical datasheet for what will be built;
• builds up the cost — material, fabrication, assembly, freight, warranty, margin;
• writes the proposal in the house style;
• reviews it, because a percentage-point slip on one line becomes a contractual dispute later.

Added up, that work takes about two weeks per proposal. And because only someone with judgment can do it, the queue of requests becomes a queue of revenue: with eight quotes backed up, response time triples and the new prospect gives up before the price ever arrives. In the operation we worked with, quoting and proposing consumed roughly half of the commercial cycle.

And every quote starts from zero. The near-identical project closed last year contributes nothing beyond the memory of whoever was there.

(The three days we wrote about in the technical proposal that took the senior engineer 3 days are just the drafting. The two weeks are the whole cycle — reading, sizing, building up the cost, writing and reviewing. This post is what happened when we measured that cycle.)

The short version, before the method: that cycle now fits into about two hours, and the estimate landed within 93% to 97% of the quote the senior engineer had already closed — in a test where the AI never saw his result. The rest of this post is how it was built and, above all, how it was measured.

What we built

Four pieces, on top of the shop’s own document library.

1. Extraction with evidence. The customer’s documents go into the shop’s own library — text PDFs, spreadsheets, drawings. The library belongs to them: it runs on a dedicated cloud or inside the company, whichever they choose. F7 KORE reads and extracts item by item: dimensions, quantities, scope requirements, supply conditions. For every extracted value it shows where it came from: the document, the page, the excerpt. What it didn’t find, it doesn’t fill in — it flags as pending. A field declared empty is worth more than a plausible number.

2. An estimate that learns from the shop’s own history. This is not a generic “market” model: the engine trains on the quotes the company itself has closed, and cross-checks two independent readings of the same project. When the two agree, the estimate is solid; when they diverge, the project is atypical and deserves the engineer’s eye.

3. The engineer confirms — and the number responds. The estimate appears with the extracted items beside it. He confirms what is right, adjusts what he knows better than any document, and the cost recalculates on the spot. It isn’t a report to review and redo by hand: it’s the engine itself running again with his input.

4. The proposal in the house template. Out comes the document in the company’s own template — cover, sections, datasheet table, investment breakdown. Where data was missing, the text carries an explicit “[TO BE DEFINED]” rather than a factory default. Nobody sends a proposal with a visible gap; but plenty of people have sent one with a default number nobody checked.

Those are the two hours from the top of this post. But time alone is worth nothing: a fast proposal with the wrong price costs the margin, or costs the job. So the question that mattered was the other one — is the number right?

The proof: a blind benchmark

An estimate that nails the past it was trained on proves nothing. So we measured the painful way: take the quotes already closed, hide one, train the engine on the rest only, ask for an estimate of the hidden one, compare against the real number. One at a time.

Parity reached 93% to 97% — against the quote the senior engineer had already closed, with the AI never seeing his result. Plus something a hand-built quote doesn’t deliver: evidence for every line item, traceable back to the page it came from.

We measured it over the real archive of an engineer-to-order shop: closed quotes, with known contract values, in a completed proof of concept. We don’t name the shop — cost breakdowns and proposals are the material an engineering house doesn’t publish, and the same discretion applies to whoever hires us. The method is right there above; it’s the same one we run on the history of whoever comes to us.

What it frees up

This isn’t about answering faster. It’s about what the shop becomes able to do:

• Answer every request. When assembling a proposal costs two hours instead of two weeks, the shop stops choosing which RFQs to take. More proposals out is more chances to win — the simplest math in industrial sales.
• The senior back to senior work. He stops filling spreadsheets and goes back to what nobody else does: settling scope, spotting technical risk, negotiating the job.
• The house’s judgment becomes an asset. What carried the estimate was the body of decisions the company had already made — scattered across PDFs and spreadsheets, earning nothing. Now it works on every new quote, and improves with every proposal reviewed.
• Traceable pricing. Every number in the proposal has provenance. In a scope dispute six months later, that’s the difference between arguing from memory and showing the document.

It carries beyond quoting: datasheets, technical reports, specifications, inspection — any work that today depends on a senior head reading documents and applying judgment.

One principle runs through all of it, and it’s what makes the number trustworthy: where there is no evidence, F7 KORE flags the gap instead of inventing a value. That’s why the engineer signs off on it — the manual labor goes, the decision stays with him.

Customer requests, drawings and cost breakdowns are the most sensitive material an engineering shop has. That’s why F7 KORE runs inside the client when the client needs it — a subject we covered in where the AI runs matters.

---

The company behind F7 KORE has been automating industrial processes for over a decade, in real operations and regulated environments. What changed is the engine: the platform now does the work on top of knowledge that was already there — and the senior people review and decide instead of executing.

If assembling quotes and technical proposals is your engineering bottleneck, the path is short: bring the closed quotes from your last few similar projects — half a dozen is enough — along with the matching requests. Parity can be measured on your history, by the same method as this post. talk to us.