From scope to signed proposal.

There are two ways in and they suit different jobs. For a small job, describing it out loud is faster than any form: you say what the work is, roughly how big, where it is and what the finish level is, and that is enough to price against. For a tender, you drop the pack in whole.

A pack turns up as whatever the client happened to have. One enormous PDF, a folder of sheets named A-101 through A-118, a specification in Word, a bill of quantities in a spreadsheet somebody has been editing for years. Nothing needs naming, sorting or tagging first.

Why this part is harder than it looks. A tender pack has no schema. The same fact lives somewhere different in every pack. Liquidated damages might be a clause, an annexure, or one line of a table hundreds of pages in. Retention might never be stated at all and simply fall back to whatever the standard form contract says. So the first job is not extraction, it is working out what each document is and which parts of it carry obligations.

Drawing sheets get classified before anything is measured, because a plan, an elevation and a detail all have to be treated differently, and the title block cannot be relied on to tell you which one you are looking at.

Reading the commercial text and measuring the drawings are different problems and get different machinery. The text side is language work. The measuring is geometry, and it is the part most estimating tools quietly do not do at all.

Most plan pages are drawn as vectors, which means the true geometry is sitting in the file and does not have to be inferred from pixels. The catch is scale. A drawing will happily say 1:100 in the title block and not be at 1:100, because it was reissued at a different sheet size and nobody updated the block. A stated scale is treated as a hint, and the drawing has to confirm its own scale from something measurable on it before any number coming off it is trusted.

Where the models come in. Vector geometry tells you where the lines are, not what they mean. A segmentation model classifies rooms and a detection model finds symbols: doors, windows, fixtures, services, site marks. Both work over a fixed taxonomy rather than free text, so two sheets can never disagree about what a thing is called.

Those models were taught by hand. Australian house plans, labelled sheet by sheet inside Quantifyr’s own manual takeoff tool: rooms drawn as polygons, symbols boxed. Not scraped, not bought, and not customer work. It is slow, unglamorous and there is no shortcut, which is exactly why it is worth having.

It also could not be skipped by using what already exists. The public floor plan datasets are almost entirely overseas. A model trained on them arrives at an Australian drawing and finds very little, because the symbols, the line weights and the drafting conventions are not the ones used here.

One detail says more than the rest. A part-finished sheet exports with an ignore mask. If only the rooms were labelled on a sheet, the wall and symbol pixels are written as ignore, not as negatives. Without that, every half-done sheet would be quietly teaching the model that a door is not a door, and the model would get worse the more effort went into it. It is the sort of thing that only shows up once you have trained something on real, partly-finished work.

Annotation runs against the model’s own predictions, so a person confirms or corrects rather than redrawing from nothing. A correction is worth more than a fresh label, because it lands exactly where the model is weak.

Every line says where its rate came from: a rate you have set, the built-in Australian library, or a grounded market search that stays marked unconfirmed until you accept it. Your own rate always wins. That ordering is the point, because it means you can scan a schedule and see the handful of lines worth arguing with instead of auditing all of it or trusting all of it.

Rates are learned from corrections rather than entered up front. There is no library to load before you can price anything, which is the setup cost that stops most people ever starting.

Then the benchmark. The estimate is compared against contracts that were actually awarded. The models return a full set of percentiles rather than a single figure, and the intervals are conformalised, meaning they are calibrated against contracts the model never saw during training. A band that claims to contain the answer has been made to earn that claim.

A second model asks the question estimators care about more: will this contract get varied, and how far does the cost travel when it does. You get a risk level, a spread of likely outcomes, and a recommended allowance with a reason behind it instead of the usual flat ten percent.

Building that database was the slow part. Awarded contract data is public but it is not tidy. Every source publishes a different shape, different fields, and a different idea of what the value of a contract even means. Some figures include variations and some do not. Some are restated later without saying so. The same project can appear three times under three names. Most of the work was reconciliation and de-duplication rather than modelling.

Houses run through a separate model built on building permit data. Government tender data describes government work, and pretending it describes a detached house in an outer suburb is how benchmarks end up useless. Naming that limit is what makes the rest of it worth believing.

The estimate goes out as a proposal with your own branding on it, not as a spreadsheet with our name in the corner. What the client sees is a document, not a tool.

Once it is out, the estimate stops being a one-off document and becomes the baseline. When the scope moves, and it will, the variation is priced against what was agreed rather than reconstructed from memory weeks later, which is where margin usually disappears on a job that was priced correctly in the first place.

Progress claims and variations track back to the same set of lines, so the question of what was in the original price has an answer instead of an argument.

Progress claims and variations track back to the same set of lines, so the question of what was in the original price has an answer instead of an argument.

A single job priced well is worth something. Knowing what the next six months look like across every job is worth more, and it is the thing most estimating tools stop short of, because it needs the estimate, the dates and the odds in the same place.

The board. Six stages, from new lead through needs defined, proposal sent and proposal in review, to accepted or lost. Drag a job between them. It is the same view for everyone in the workspace, so nobody is working from their own copy of the truth.

Weighted, not wishful. Each stage carries a default likelihood of winning, so the pipeline total is what the work is actually worth rather than the sum of everything you have ever quoted. A new lead counts for a tenth of its value; a proposal already in review counts for three quarters. Where you know better than the default, override it on that job.

Cashflow. Give a job a planned start and finish and its value spreads across the weeks or months between them. You get two lines: what you would bill if every job landed, and the probability-weighted line that is closer to what will really happen. Lost jobs drop out of both.

The part that is easy to get wrong. Spend is not spread evenly across a job. Construction spend is front loaded, peaking around a third of the way in, so the projection follows that curve rather than a straight line. It matters because a straight line tells you that you have money in month six that you actually collected in month three, and that is the shape of a cashflow problem you did not see coming.