Insights
How do you measure the ROI of AI in construction?
Nobody on your team would price a job without doing the takeoff first.
You count the doors before you price the doors. You measure the linear feet of curb before you put a unit price on it. Then the number you take to bid day is something you can defend, line by line, to anybody who asks.
AI projects rarely get a takeoff. Somebody sees a demo, buys some licenses, and six months later tries to figure out whether it was worth it. By then there’s no “before” to compare to. So the answer is a shrug, and the shrug loses to every other line in next year’s budget.
Why is AI ROI so hard for contractors to prove?
AI ROI is hard to prove mostly because nobody measured the work before the AI showed up. The AI isn’t the hard part. The baseline is.
In a poll of Tyler Campbell’s LinkedIn audience (n=65), 31% said the biggest barrier to fixing their tech was that it’s hard to prove the ROI. In a separate poll (n=44), 61% said leadership would pay someone to streamline their tech “maybe, if ROI is clear.”
My read: those numbers describe the same stuck spot. Owners are willing. They just want the math first. And the math is very doable, as long as you do it in the right order.
What’s the formula?
The return on an AI workflow is the annual cost of the work before, minus the annual cost after, minus what it costs to run. The cost of the work is hours, times people, times rate, times weeks.
| Input | What it means | Where it comes from |
|---|---|---|
| Hours | Hours a week the work takes, per person | Measured on real cycles, not guessed |
| People | How many people do it | Your org chart, checked against reality |
| Rate | What one of those hours is worth | Loaded labor cost, or revenue per hour for sellers and billers |
| Weeks | How many weeks a year it happens | Your calendar. Monthly work is 12 cycles, not 52 weeks |
| Cost before | Hours × people × rate × weeks | The baseline |
| Cost after | Same math, measured once the workflow runs | Includes review time |
| Return | Cost before, minus cost after, minus running cost | Licenses, setup, upkeep |
We call the “cost before” number the Cost of Chaos. It’s the takeoff. Everything else gets priced against it.
Write every input down where someone can argue with it. If your controller can’t follow the multiplication, it isn’t a number yet. It’s a hope.
Which hourly rate should you use?
Use loaded labor cost for office and operations work, and revenue per hour for people whose time is sold. Picking the wrong one is the fastest way to make an AI project look far better or far worse than it is.
Most construction work gets the loaded rate. Your APM building the submittal register, your project accountant reconciling the SOV, your super writing the daily. Their hours cost what you pay them, plus burden.
Some people are different. A seller, an estimator chasing more bids, a billable engineer at a service firm. When their time comes back, it doesn’t just save cost. It turns into more work sold or billed. That rate is a lot higher, and you have to be honest that you’ll actually use the hours that way.
Here’s the one client example we publish. At a managed-IT firm serving large capital programs, the FieldProof assessment found each seller losing 10 to 14 hours a week to pure admin: CRM logging, duplicate entry, hand-built project setup. Call it one selling day a week. The firm valued a selling day at $12,000. One day a week back is 50 selling days a year.
50 days × $12,000 = $600,000 ± in lost revenue capacity per person.
Two honest notes on that one. First, it used the revenue rate because these were sellers. At a loaded labor rate the number would be much smaller, and still worth fixing. Second, the fix needed zero new software. Most of it was automation inside the platform they already paid for, not fancy AI. The cheapest automation is the step you delete.
How do you measure the “before” without fooling yourself?
You measure the before by watching real cycles of the work, not by asking people to estimate. Sit with the person who does it. Time an actual pay app, an actual submittal package, an actual week of dailies. Count every handoff and every time the same number gets typed twice.
Ask a PM how long the pay app takes and you’ll get a guess. Sometimes low, because nobody likes admitting they spend Sunday night on it. Sometimes high, because they’re hoping somebody fixes it. Either way it’s a guess, and you wouldn’t bid off a guess.
And you don’t need a stopwatch on everybody for a month. A few real cycles of the work, watched closely, beat a hundred survey answers.
What about workflows where the payoff is cash?
On cash workflows, measure dollars and days, not just hours. Change order backup, pay apps, lien waivers, and closeout don’t just eat time. When they go wrong, money you already earned sits on the table or shows up late.
So the “before” for those workflows has more lines:
- How many change orders went in without complete backup, and what happened to them.
- How often a pay app came back for corrections, and how many days that added.
- How long retainage sat after substantial completion, and what was holding it.
That math matters most for subs. A GC feels a slow month. A sub waiting on a pay app that bounced over a missing lien waiver from a second-tier is financing the job out of its own pocket. Faster, cleaner paper is a real return even if the hours saved are small. More on fixing a cash workflow.
Where does AI ROI math usually go wrong?
AI ROI math usually goes wrong by counting savings that never turn into money and skipping costs that are easy to forget. These are the ones to watch:
- Counting hours that go nowhere. An hour back is only worth something if it gets used. If the APM saves a few hours and spends them in the same meetings, the return is real but small. Say so.
- Forgetting the review. AI drafts, and a person reviews. Review time isn’t zero, and it belongs in the “after.”
- Measuring the champion. Your sharpest PM will get great results. Measure the average user on the average job.
- Picking a rare workflow. A brilliant fix to something that happens twice a year rarely pays. Repetition is what makes the math work.
- Skipping the running cost. Licenses, setup, and the hours someone spends keeping it current all come off the top.
Get those right and the number you end up with is smaller than the demo promised. Smaller. Honest. Defensible. That’s the one you want.
What happens after the number?
After the number, you build, then you measure again the exact same way. Same inputs, same rate, real cycles. The difference between the two is your return, and it’s the number that gets the next workflow funded.
If the “before” comes back small, that’s a result too. It means you just avoided buying something you didn’t need. I’d rather tell a contractor that on day one than find it out together six months later.
Count first. Price second. Same as every job you’ve ever bid. If you’d like the count done on one of your real workflows, that’s part of what a Workflow Sprint does.
Sources
- Poll of Tyler Campbell’s LinkedIn audience, n=65, Q1 2026: biggest barrier to optimizing your tech stack.
- Poll of Tyler Campbell’s LinkedIn audience, n=44, Q1 2026: would leadership pay someone to streamline your tech.
- Anonymized client story, numbers as published on fieldproof.io.
- Full poll results and method: Construction tech stack poll results.