Tender to quote: why estimators lose days to GAEB files

Ask a window or door manufacturer where the bottleneck in their sales process is, and the answer is rarely "pricing". It is everything that has to happen before anyone can price: turning a tender into something an estimator can actually work with. Here is that sequence, stage by stage — and an honest look at which parts need a human and which parts never did.

What actually arrives

The first mistake is thinking a tender is a file. It is a package:

• The bill of quantities — a GAEB file, in one of several generations and phases. Sometimes a PDF instead. Sometimes an Excel export someone made from a GAEB file, which has already lost half its structure.
• The preliminary remarks (Vorbemerkungen) — rules that apply to every position, buried in a PDF.
• The technical specification — what the products actually have to achieve, often the only place a U-value or a sound-insulation class appears.
• The contract terms — VOB clauses, warranty periods, penalties.
• The forms — eligibility declarations, references, certificates, each with its own deadline.

The bill of quantities tells you what to price. The other four tell you whether you should bid at all, and under what conditions. Estimators read the first one carefully and the rest under time pressure, which is exactly backwards from where the risk sits.

The seven stages

Three of seven stages need an estimator. The other four are data handling that a senior, expensive person is doing because no tool removed it.

Why each handling stage is slow

Stage 1 — it does not open. Several GAEB generations coexist, and no single estimating package reads all of them cleanly. A file can also be mislabelled: an X84 renamed to .x83 imports as a request and silently drops every price in it. The ten most common import failures covers what actually goes wrong and what to send back to the sender.

Stage 2 — volume. This is the one worth doing the arithmetic on yourself, because your number is the only one that matters:

Take your last tender. Count the positions. Multiply by the seconds you spend on each one that did not import cleanly — reading it, typing it, checking it. That product, in hours, is what stage 2 costs you per tender. Multiply by tenders per month.

Our free sample file has 22 positions, and that is a small one. Real tenders run to hundreds, sometimes thousands. A few seconds per line is an afternoon.

Stages 6 and 7 — fragility. The file you return has to match the file you received exactly: same position numbers, same order, same structure. The client's software reconciles your X84 against its original X83 line by line, and a mismatch is not a friendly error — it is a position quietly assigned to the wrong price, or a bid the platform rejects on submission. Estimators re-check obsessively, and they are right to, because a silent failure is worse than a slow one.

What should remove each stage

Not "estimate faster". Delete the handling and leave the judgement:

• Read any format, once. A parser that handles every GAEB generation and exchange phase makes stages 1 and 2 disappear: nothing is retyped because nothing failed to import. That is what our open-source engine pyGAEB does, and it is why we published it rather than kept it.
• Put the package in front of the estimator, not behind them. Deadlines, eligibility and exclusion criteria, contract flags and alternative positions extracted from the PDFs and shown next to the positions — each with a citation back to the page it came from, so it can be checked rather than trusted. That turns stage 3 from a late-night read into the first thing you see, and into a Go/No-Go decision you can defend.
• Propose the match, keep the decision. Software can suggest which catalogue article and which price each position maps to. The estimator reviews and corrects. Stages 4 and 5 stay human — they should — but they become review instead of construction from scratch.
• Generate the return file from the original. Writing the X84 straight from the X83 structure you imported removes stages 6 and 7 entirely: the position numbers cannot drift, because they were never re-entered.
• And when you are the one collecting bids — from subcontractors, on your own packages — the same structure gives you a Preisspiegel: every bid against every position, ranked, with the price spread visible per line.

That is the shape of DatumOS: the tender in, the judgement stages surfaced and supported, a send-ready X84 out. A human in the loop for the decisions that carry risk, and out of the loop for the retyping that carries none.

The honest version of "how much time does it save"

We are not going to print a number we cannot show you the working for. Anyone quoting "70% faster" on a landing page is quoting a number from a spreadsheet, not from your office.

What we can say is which stages exist and which ones are handling rather than estimating — that is the table above, and you can check it against your own week. If four of the seven stages in your process do not need your judgement, that is the size of the opportunity, whatever the hours turn out to be.

The first pilot companies are running exactly this measurement on their own tenders. When those numbers exist, they will appear here, with the method attached.

Until then: if you want to see what your own tender looks like on the other side of stages 1 and 2, drop it into GAEB-Check — it costs nothing and takes a minute.