Estimating and production decisions keep returning to the owner.

Prepare the estimate with its history.

The owner’s pricing judgment depends on understanding the job. A useful first proof would examine how much work goes into assembling that understanding before a price can be approved.

Composite demonstration. The following workflow is a proposed design, not a deployed system or a measured client result. Millbrook combines patterns from previous client work while protecting client confidentiality. The proposed extension would require its own feasibility assessment, baseline and measured results.

Start with an estimate and follow what it takes.

In this demonstration, custom pricing combines material cost, labor, scope risk and the client relationship. Estimates wait when the owner is away. Pricing errors become visible at close-out. Before building, I would follow a completed quote back through its intake and forward through the finished job.

Which details were available when the price was set? Where did the owner supply something from memory? Did a later change alter the work without changing the estimate? Those questions help distinguish missing information from a decision that properly belongs to an experienced person.

Make the preparation inspectable.

The proposed process starts by collecting the details needed for an estimate. Software would bring relevant past jobs and written pricing rules together with the request. A draft would show the source of each important assumption and flag missing or conflicting details.

Prior work supplies context; someone still has to decide whether it is comparable. An old quote may describe a different scope or reflect costs that no longer apply. The design would need a defined response when the available records cannot support an estimate.

Define completion beyond a generated draft.

I would test the whole process from receiving a request to recording an approved estimate. That includes questions sent back, the owner’s review and corrections. The comparison would count that full effort, including drafting.

During a proof, the existing estimating process would remain the fallback. Unsupported assumptions would return to the responsible person. The system would not send a price or make a customer promise on its own.

Agree what evidence would justify continuing.

Before changing the process, measure a dated sample of comparable estimates. Record preparation and review time, corrections and customer waiting. Include unusual cases needing a person and the effort required to make the underlying records usable.

Then compare complete, accepted estimates under the proposed process with that baseline, alongside implementation and running costs. A faster draft could still leave the owner with more checking. Released time would count as capacity; cash savings would require an actual spending change.

Estimating quality also needs the job’s eventual outcome. The proof would preserve a way to compare the accepted estimate with close-out evidence when it becomes available. It should state that limitation if the evaluation ends before the work is complete.

Let the result determine the next move.

If preparation becomes less burdensome while the agreed quality and authority boundaries hold, the evidence may support continuing. If the records are unreliable, improving the intake and job history may deserve priority. If review consumes the benefit, revise or stop the proposed design.

The useful change would be having the request, relevant job history and pricing rules ready for the owner’s decision. I call the connected records, instructions and software a Business Nervous System. The test would tell us whether that setup improves the estimating process.

See how Prove is scoped and measured → · Read the architecture standard →

The Read is my $2,500 business assessment: a 90-minute session and a report with one recommended first change, delivered within two business days afterward. Building the change and looking after it are separately agreed and priced.