Reality Capture ROI: How to Calculate the Return on Construction Technology
By Kush Agarwal, President and CEO, YelloSKYE. Published .
Executive Summary
- The Question: How do you put a defensible number on the return from reality capture or any other construction technology, before and after you buy it?
- The Answer: List every cost, including your own staff time. Split the benefits into hard savings, avoided losses and value you will not price. Build the case on hard savings alone, show avoided losses as the upside, and prove both with a pilot that measures a baseline first.
- The YelloSKYE Angle: Construct IQ produces a dated record of every capture on DEX, which is also the evidence an ROI review needs: when each deviation was found, which claims were checked and what the site looked like on the day.
The return on reality capture is the value of the costs it removes and the losses it prevents, minus everything you spend to run it, divided by that spend. Calculating it well is mostly a matter of discipline: count all of the cost, count only the benefits you can evidence, and keep the uncertain ones in a separate column so the decision does not rest on them.
This guide sets out the formulas, the cost and benefit lines to include, an illustrative worked example and a pilot design that turns an estimate into a measured result. It draws on the way we assess value with clients who use Construct IQ for construction monitoring. If you have not yet decided which capture methods suit your project, from drone surveys to laser scans, start with our reality capture guide and come back here once you know what you would deploy.
The formulas
Four calculations cover almost every technology business case on a construction project.
| Measure | Formula | What it tells you |
|---|---|---|
| Net benefit | Total benefits − total costs | The money left over after paying for the programme |
| ROI | Net benefit ÷ total costs × 100 | Return per unit of money spent, as a percentage |
| Payback period | Total costs ÷ monthly benefit | How many months until the programme has paid for itself |
| Benefit-to-cost ratio | Total benefits ÷ total costs | A simple multiple, useful when comparing options |
Two rules make these numbers comparable. First, measure costs and benefits over the same period, usually one project or one year. Second, decide in advance which benefit lines you will include, so the result is not shaped after the fact.
For multi-year portfolio decisions, a finance team may prefer net present value, which discounts future benefits. For a single project, simple ROI and payback are usually enough.
Cost lines: what you actually pay
Most business cases understate cost because they stop at the vendor's quote. A complete list looks like this.
| Cost line | One-off or recurring | Notes |
|---|---|---|
| Capture service or subscription | Recurring | Drone flights, fixed-camera rental, scanning visits, platform access |
| Hardware | One-off, sometimes recurring | 360° cameras, fixed-camera mounts, power and connectivity on site |
| Set-up and integration | One-off | Loading drawings, BIM and programme; connecting to project management tools |
| Training and onboarding | One-off, repeated for new staff | Time for site teams and reviewers to learn the workflow |
| Internal capture time | Recurring | Staff walking 360° routes or supporting flights |
| Internal review time | Recurring | Engineers and project managers reading outputs and acting on flags |
| Permissions and compliance | One-off or per site | Flight permissions from the relevant national aviation authority (the FAA, the UK CAA or the UAE's GCAA, for example) and any site access approvals |
Internal time is the line people forget, and it can move the result from positive to negative. Price it at a loaded hourly rate that includes employment costs, not salary alone.
Benefit lines: three columns, not one
Benefits differ in how certain they are. Mixing them in a single total is the most common reason an ROI case is not believed. Keep three columns.
Hard savings
Money you would otherwise have spent and now do not. Typical lines:
- Verification trips. Fewer journeys for project managers, owner's representatives and consultants to confirm progress.
- Survey call-outs. Fewer separate surveys to settle quantities, because volumes come from routine drone captures.
- Reporting effort. Fewer hours compiling photos and progress reports, counted only where those hours replace paid overtime, agency staff or consultant fees, or are moved to work you would otherwise buy in.
- Meeting time. Shorter reviews when everyone opens the same capture, priced on the same terms as reporting effort.
Avoided losses
Costs that would have happened without the programme. These are often larger than hard savings, but they are lumpy and need evidence event by event.
- Rework caught early. A deviation found before the next trade covers it, priced as the late-fix cost minus the early-fix cost. Our guide to the cost of rework explains how to cost an event properly.
- Over-claimed work not paid. Quantities or progress claimed beyond what the capture supports, corrected before certification. Count only the share you would not otherwise have recovered.
- Disputes shortened or avoided. Commercial and legal time saved when a dated record answers a question about what was built and when.
- Delay costs avoided. Site overheads and finance costs saved when slippage is spotted earlier. Hard to attribute, so count only with a clear cause and effect.
Value you should not price
Some benefits are real but too uncertain to put in a number: owner and lender confidence, a complete handover record, better data for the next tender, safer sites because fewer people need to walk hazardous areas. List them in the business case and leave them out of the ROI.
| Benefit line | Column | Evidence you need | Confidence |
|---|---|---|---|
| Verification trips avoided | Hard saving | Trip log before and during the programme | High |
| Survey call-outs avoided | Hard saving | Survey orders before and during | High |
| Reporting hours saved | Hard saving, if redeployed | Timesheets plus where the hours went | Medium |
| Rework caught before cover | Avoided loss | Dated capture, issue log, priced late and early fix | Medium |
| Over-claims corrected | Avoided loss | Claim, capture on the cut-off date, certified amount | Medium |
| Disputes shortened | Avoided loss | Time log on each disputed item | Low to medium |
| Handover record, confidence | Not priced | Described, not counted | n/a |
Worked example: one project over twelve months (illustrative)
Every figure in this example is an invented round number used to demonstrate the method. None is a YelloSKYE price or a customer result.
A contractor runs a reality capture programme on one building project for 12 months of active construction.
| Cost line | Basis | Amount |
|---|---|---|
| Capture service and platform | Annual fee | 48,000 |
| Set-up, onboarding and integration | One-off | 6,000 |
| Internal review time | 2 hours a week × 50 weeks × 60 per hour | 6,000 |
| Total cost | 60,000 |
| Benefit line | Basis | Hard saving | Avoided loss |
|---|---|---|---|
| Reporting hours | 10 hours a week × 48 weeks × 50 per hour, replacing agency support | 24,000 | |
| Verification trips | 4 fewer trips a month × 12 months × 500 per trip | 24,000 | |
| Survey call-outs | 4 avoided × 5,000 each | 20,000 | |
| Rework caught before cover | 2 events, each 15,000 to fix late versus 1,000 early | 28,000 | |
| Over-claimed quantities | 30,000 corrected, half counted as otherwise unrecoverable | 15,000 | |
| Totals | 68,000 | 43,000 |
Reading the result
| View | Benefits | Net benefit | ROI | Payback |
|---|---|---|---|---|
| Hard savings only | 68,000 | 8,000 | 13% | about 10.6 months |
| Hard savings plus avoided losses | 111,000 | 51,000 | 85% | about 6.5 months |
| Hard savings, reporting hours not redeployed | 44,000 | −16,000 | −27% | not within the year |
The table makes three points. The programme pays for itself on hard savings alone, but only just. The avoided losses, two caught errors and one corrected claim, are what make it clearly worthwhile. And a single assumption, whether saved reporting hours turn into money, swings the hard-savings case from positive to negative.
That last row is the useful one. It tells you which assumption to test in a pilot before you rely on the number.
Where ROI calculations go wrong
- Counting hours as cash. Time saved is only a financial return if something you pay for goes away or new work fills the time.
- Double counting. Shorter meetings and fewer reporting hours often describe the same saving. Count it once.
- Borrowing someone else's results. A vendor's case study, ours included, tells you which lines to measure. It does not tell you your numbers.
- Ignoring adoption. Captures that nobody reviews produce cost and no benefit. Review time belongs in the cost lines, and a review routine belongs in the plan.
- Mismatched periods. Set-up costs arrive in month one; avoided losses may not appear until month six. Short evaluations understate the return, and long ones invite optimistic attribution.
- Claiming every improvement. If a new site manager arrives at the same time, not all of the change belongs to the technology.
Running a pilot that proves the number
An estimate gets approval for a trial. A pilot with a baseline gets approval for a rollout. The steps below are about measuring the return; for a design that compares capture methods side by side on accuracy and speed, see our guide to AI versus manual progress verification.
- Write the decision rule first. Agree with finance what result would justify rolling out, for example a positive ROI on hard savings alone, before any data is collected.
- Record a baseline. For four weeks before capture starts, log verification trips, survey orders, reporting hours and disputed claim items on the pilot package.
- Choose a package where the money is. Earthworks, structure or a big services package carries claims and deviations worth measuring.
- Run for at least three payment cycles. Time a capture just before each claim cut-off so every claim has a dated reference.
- Keep one benefit log. Every trip avoided, survey cancelled or deviation found goes in it, with the date, the capture that supports it and a costed estimate agreed with the commercial team.
- Track adoption. Note who opened the captures, in which meetings and for which decisions.
- Report in three columns. Present hard savings, avoided losses and unpriced value separately, and apply the decision rule you wrote in step 1.
Speed of start matters for a pilot, because the first claim cycle is where much of the evidence comes from. On Construct IQ, our usual lead time from agreement to first capture on a newly set-up project is 48 to 72 hours.
What YelloSKYE deployments have measured
Our use cases show which benefit lines tend to move. Treat them as a list of what to measure, not as inputs to your own case.
| Use case | What was measured | Benefit column |
|---|---|---|
| Aerial progress capture | Site managers saved more than 15 hours of manual reporting a week; stakeholder meetings fell from two hours to 30 minutes | Hard saving, if redeployed |
| Contractor billing disputes | 80 per cent fewer site visits needed to verify progress claims, with flights timed to each billing cycle | Hard saving |
| Portfolio monitoring | Leadership reviews 10+ sites in 30 minutes; billing disputes reduced by 90 per cent | Hard saving and avoided loss |
| Interior fit-out | 70 per cent less coordination time using navigable 360° digital twins | Hard saving, if redeployed |
The portfolio case also shows how the return scales. Travel and leadership review time grow with the number of sites, so the hard savings column grows faster than the cost once every site is captured to the same standard.
Checklist: building your ROI case
- List every cost line, including internal capture and review time at a loaded rate.
- Sort benefits into hard savings, avoided losses and unpriced value.
- Build the decision on hard savings; show avoided losses as the upside.
- Find the one assumption that swings the result and plan to test it.
- Record a four-week baseline before the pilot starts.
- Run the pilot for at least three payment cycles, with a capture before each cut-off.
- Log every benefit with a date, a capture and a costed estimate agreed with the commercial team.
- Review the result against the decision rule agreed at the start.
Frequently asked questions
How do you calculate the ROI of reality capture?
Add up every cost of the programme over a set period, including service fees, hardware, set-up and your own staff time. Add up the benefits you can evidence over the same period, such as reporting hours, avoided site visits, survey call-outs and errors caught early. ROI is the net benefit divided by the total cost, shown as a percentage.
What costs should be included in a construction technology ROI calculation?
Include the subscription or service fee, any hardware such as cameras, mounts, power and connectivity, set-up and integration work, training, and the time your own team spends capturing and reviewing data. Internal time is the line most often left out, and it can decide whether the return is positive.
How long does it take for reality capture to pay back?
It depends on the project and on which benefits you count. Hard savings such as fewer verification trips and fewer survey call-outs appear within the first few payment cycles. Savings from rework and disputes avoided are larger but less frequent, so they need a longer period to show up reliably in the figures.
Should time saved count towards ROI?
Only if it turns into money or capacity you can name. Hours saved count when they replace overtime, agency staff or consultant fees, or when the person takes on work you would otherwise have paid for. Hours that simply disappear into a busy week are a real benefit, but they should be shown separately from the cash return.
How long should a reality capture pilot run?
Long enough to cover at least three payment cycles on one live package, which on most projects means about three months. That gives you repeated claims to check, enough time for deviations to be found and costed, and a fair view of whether the team actually uses the data.