Using AI to Check an Estimate, Not to Build It

Why this matters

An estimate that misses a line item loses that line's margin and usually more, because the missing item turns up mid-job as a change order the customer did not budget for and resents. An estimate with an arithmetic error is worse: it goes out under your name with a total that is simply wrong. A general-purpose chat assistant is genuinely good at the first problem and genuinely bad at the second. It is a fast, tireless second reader that asks "did you account for this?" about a scope it has seen described a thousand times. It is also a text predictor that produces a confident sum which may not be the sum. The skill is splitting those two jobs cleanly: let it question the takeoff, and never let it touch the number.

The division of labor

A takeoff is the list of quantities and items you pull from the job before pricing: feet of pipe, fittings, hours by task, permits, disposal. Most missed lines are takeoff misses, not pricing misses, and they come from the same place: the estimator built this kind of job so many times that the steps they always do disappear from view, and the step this particular house needs is the one that was never on the template.

That is what a language model is suited to. It has absorbed thousands of descriptions of jobs like yours, so it can list what a typical scope includes and point at what yours does not mention. It does not know your local code, your supplier's pricing, your crew's speed or this house. And because it generates text by predicting what usually comes next, arithmetic it performs in its answer is prediction too, which is why a column of eleven numbers can come back with a total that is close and wrong (the mechanism is its own card, see related: What a Language Model Is Actually Doing When It Answers).

So the rule is two sentences. The tool asks questions about the scope. The estimating software, or a person with a calculator, produces every number.

A worked case: one water heater, one catch, one error

A plumbing shop is quoting a straight replacement: a 50-gallon gas tank-type water heater, same location, in a basement. The estimator builds it in the shop's estimating software as usual. The labor lines, in hours:

• Drain and remove old heater: 1.0 hour
• Set new heater, connect water and gas: 2.5 hours
• Vent connection and draft check: 0.75 hour
• Haul-away and cleanup: 0.5 hour
• Permit and inspection visit: 1.0 hour

That is 1.0 plus 2.5 plus 0.75 plus 0.5 plus 1.0, which is 5.75 hours. Materials are the heater, a gas connector, a vent connector section, two dielectric unions, a drain pan and fittings.

The estimator then pastes a version stripped of the customer's name, address and all pricing into the shop's approved assistant, with this request:

PROMPT:
Here is my scope and takeoff for a residential gas
water heater replacement, same location, basement.
Do not price anything. List items a scope like this
often needs that mine does not mention, and for each
one say what I would need to check on site to know
if it applies. Then total my labor hours.

ANSWER (excerpt):
1. Thermal expansion tank. Often required where the
   supply has a check valve, backflow preventer or
   pressure-reducing valve. Check: is there one at
   the meter or main?
2. Seismic strapping. Required in some states.
   Check: your local code.
3. Combustion air. Check the room volume and any
   new tightness in the basement.
Total labor: 6.25 hours.

The catch. Item 1 was real. The estimator had not looked at the main; the photo from the site visit showed a pressure-reducing valve on the supply line, which makes the system closed, and the local code (the shop's own jurisdiction adopts a model plumbing code that addresses thermal expansion on closed systems) calls for expansion control. The estimate gained a line: expansion tank, mounting and connection, 0.75 hour plus the tank. Without it, either the tech adds it on site as a surprise, or the tech skips it and the shop has installed a heater on a closed system with no expansion control, which shows up later as a dripping relief valve and a callback.

The noise. Item 2 did not apply: the shop's state does not require seismic strapping for this installation. Item 3 was worth a glance and cleared: the basement was large and unaltered. One useful question out of three is a normal ratio, and it is the reason the triage step below exists.

The error. The tool's labor total read 6.25 hours. The real total of the five lines it was given is 5.75 hours, so it overstated by 0.5 hour, about 9 percent of 5.75. Nothing in the answer signaled doubt. Had the estimator copied 6.25 into the estimate, the quote would have been padded by half an hour of labor the takeoff did not support, and the next estimator to use that job as a template would inherit it. With the expansion tank line added in the software, the correct total became 5.75 plus 0.75, which is 6.5 hours, computed by the software, not by the assistant.

Notice that the tool's wrong total and the correct new total are close to each other. That is the trap: a reader who half-remembers "about six and a half" will look at 6.25 and think it is near enough. It is not near enough, because it was computed on the wrong lines.

The routine that came out of it

1. Build the estimate yourself first, completely, in your own software. Do the takeoff and the pricing before the tool sees anything. If you ask the tool first, its list becomes your scope, and you will price its typical job instead of this one. Skip this and the check is worthless, because there is nothing independent to check.

2. Strip everything the tool does not need. No customer name, address or phone number; no prices, margins or supplier costs. The tool needs the scope and quantities, not who or how much. What may go into a tool at all is set by the shop's policy (see related: The Shop AI Use Policy SOP). Skip this and you have handed a third party your pricing structure and a customer's details for no gain in the answer.

3. Ask it to question, and tell it not to price. The words that work: "list items a scope like this often needs that mine does not mention, and for each say what I would check on site." Asking for the check matters, because it turns each suggestion into something you can verify instead of something you accept. Asking it to price invites it to fill your estimate with national-average guesses. Writing prompts that get usable output is its own card (see related: How to Write a Prompt That Gets a Usable Scope of Work).

4. Triage every suggestion into one of three bins. Applies (add it), does not apply (note why), or cannot tell without a site check (call the customer or flag it on the estimate as conditional). Expect most suggestions to fall in the second bin. If you add everything the tool lists, you are padding the estimate and you will lose bids you should have won. Skip triage and the tool has quietly become the estimator.

5. Treat any number in the answer as wrong until recomputed. Totals, unit conversions, square footage from dimensions, hours from a crew-day. Do not copy them, and do not ask the tool to "double-check" its own sum, because the second answer is another prediction. Recompute in the software or on a calculator. If the tool's figure and yours disagree, yours wins, and the disagreement is worth a minute of your attention because it sometimes means you gave it a different list than you think.

6. Record what the check changed. One line in the job notes: "AI scope check: added expansion tank (PRV on supply); strapping N/A in our jurisdiction." Over a few months these lines are the evidence of whether the check earns its time. If it never changes anything, stop doing it on that job type. If it keeps finding the same miss, the miss belongs on your template, and the tool is no longer needed for it.

Where the tool's suggestions are dangerous rather than noisy

Most wrong suggestions just cost you a minute of triage. A few kinds cost more:

• Code claims. "Required by code" from a chat assistant means "commonly required somewhere." Your jurisdiction's adopted code and its local amendments decide. A suggestion that cites a specific section number deserves extra suspicion (see related: The AI Quoted a Code Section That Does Not Exist).
• Safety-relevant omissions it does not flag. The tool's list is a list of what is typical, not what is critical. It mentioned combustion air for the water heater; it might as easily not have. Its silence on venting, gas leak testing or a relief valve discharge line does not mean your scope covers them. Your own checklist covers them.
• Scope it invents from a vague prompt. Paste "bathroom remodel" with no detail and you get a generic remodel scope. The more specific your takeoff, the more specific the questions.

What would change the approach

A job type you have built a hundred times. The check finds less, because your template already carries what experience taught. Run it on a sample, not on every estimate, and use step 6's record to decide.

A job type you rarely do. The check is worth the most here, and so is the triage, because you are less able to tell a real omission from a typical-but-irrelevant one. Pair it with a call to someone who does this work often.

A commercial or bid job with a formal scope document. The tool can usefully compare your takeoff against the specification's sections and list anything the spec names that your takeoff does not. It still does not compute, and the spec, not the tool, decides what is in scope.

How to know the check is working

Two numbers, kept for a month on the job types you check: how many estimates gained a real line from the check, and how many change orders on those jobs came from an item that should have been caught at estimate. If the first is near zero and the second has not moved, the check is costing time and catching nothing. Whether a tool saved time at all is its own measurement (see related: Measuring Whether an AI Tool Actually Saved Time).

References

• Your jurisdiction's adopted plumbing, mechanical or building code and local amendments, which decide what is required
• See related: What a Language Model Is Actually Doing When It Answers
• See related: The Shop AI Use Policy SOP
• See related: How to Write a Prompt That Gets a Usable Scope of Work
• See related: The AI Quoted a Code Section That Does Not Exist