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 started preparing that work, with the source of every number — and how we went about measuring whether it prepared 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 company 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: every quote backed up pushes back the answer on all the others, and the new prospect gives up before the price ever arrives. Quoting and proposing ends up setting the pace of the whole commercial side.

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 — which now takes minutes. 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: in the proof of concept we completed, that cycle came to fit 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 — PDFs, spreadsheets, drawings. The library belongs to them: it runs as SaaS on Google Cloud in São Paulo or fully on-premises, with the AI the company chooses. 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 built on the shop’s own history. This is not a generic “market” model: the estimate starts from the quotes the company itself has closed. When the new project resembles what the company has done before, the estimate is solid; when it strays from that history, the project is atypical, and that is surfaced for the engineer to look at closely.

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 company 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 contract. 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 firm 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 contract.
• The company’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 every reviewed proposal becomes part of it.
• 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 as SaaS on Google Cloud in São Paulo or fully on-premises, inside the company, with the AI the company chooses — a subject we covered in where the AI runs matters.

---

F7 KORE is built by F7 KORE SOFTWARE LTDA, an InterSystems partner, in real operations and regulated environments. What changes with it: the platform prepares the work, with the source of every number, 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, along with the matching requests. Parity can be measured on your history, by the same method as this post. Talk to us.