That makes sense. The dirt level seems like the hardest part to standardize. When an estimate turns out wrong, what causes the biggest problem for your business: losing money, running behind schedule, or having to explain a price change to the customer?
From a profitability standpoint, I’d put losing money first, because that can happen even when the schedule and customer experience seem fine.
If a job takes longer than estimated, I’d want to know whether the original price still covered the actual labor cost and other job costs, plus enough contribution toward overhead and profit. If it did, the estimating error may mainly be an operational issue. If it didn’t, then it becomes a pricing issue too.
Running behind schedule would probably be next because one underestimated job can affect the jobs after it. Having to explain a price change is important too, but ideally the pricing and condition assumptions give enough buffer that you don’t have to renegotiate after work has started.
That’s why I think tracking estimated vs. actual hours and estimated vs. actual profit is useful—they tell you whether the problem is the time estimate, the price, or both.
That makes sense. One last question — if there were a simple tool that used your past estimated vs. actual hours and job costs to help flag potentially underpriced jobs before you send a quote, would that be something you'd actually pay for, or would a spreadsheet be good enough?
