Build an NDT software ROI case from four cost lines you already track

The unit of cost in an NDT business is the report, not the licence

Software business cases are usually built around seat count, because seats are how software is sold. That is the wrong denominator for an inspection business. An NDT contractor's cost structure is driven by how many reports leave the building and how much human handling each one absorbs between the probe coming off the weld and the client's document controller accepting the file. So count reports first. Pull the issued-report count for the last full financial year from your job register, your invoicing system, or the client's acceptance log — whichever is most complete.

Once you have the annual report count, every other line becomes a rate applied to it. Administrative handling is minutes per report. Rework is a share of reports multiplied by minutes per revision cycle. Certification and calibration failures are events per year expressed as lost crew hours. Unbilled field time is a percentage of paid hours. Four rates against one denominator. That structure is what lets a finance reviewer challenge one input at a time instead of rejecting the entire case as vendor arithmetic.

It also makes the model portable. A five-inspector shop issuing 700 reports a year and a sixty-inspector firm issuing 18,000 use identical arithmetic at different magnitudes. Nothing in the structure assumes a method mix, a client, or a product. That is deliberate. A business case that only works with one vendor's feature list is a sales document wearing a spreadsheet.

Line one: the minutes between field data and an issued report

Define the measurement window precisely or the number will be useless. It starts at the technician's last reading on site and ends when the client's document control system accepts the file. Inside that window sit transcription of instrument output, selection of the correct report template and procedure revision, insertion of calibration references, technical review by the qualified level, signature, PDF assembly, and upload to whatever portal the client mandates. Every one of those steps is a place where a report waits on a human.

You do not need a time-tracking system to measure it. Take the twenty most recent completed jobs and reconstruct the timeline from timestamps you already hold — instrument file write time, the email that carried field data to the office, report file creation, signature date, upload confirmation. Record handling time rather than calendar time, and use the median. One stalled job caused by a client holiday shutdown will wreck a mean and make your baseline indefensible under challenge.

Be honest about which minutes software actually removes. Direct instrument-to-report data transfer removes re-keying, transposition checks and template hunting; a structured review queue removes chasing a Level III for a signature; an integration removes manual portal upload. See how that transfer works in practice on our walkthrough of taking OmniScan data into a client report. What software does not remove is the technical judgement time of the reviewing Level III. Leave that in the baseline and out of the savings.

Line two: rework is the most under-counted number in the model

Rejected reports rarely appear in any system of record, because the correction happens in the same inbox thread that raised it. The coordinator fixes the file, re-issues it, and no one logs an event. That is why rework is the line most companies underestimate by the widest margin, and why it is worth reconstructing carefully rather than estimating from memory.

There is a reliable proxy hiding in your own numbering convention. Count how many reports were issued at Rev B or later as a share of total reports issued. That share is your reject rate, and it requires no new logging to obtain. Cross-check it against client rejection emails and your document control resubmission log. Then exclude revisions caused by client scope change, because those are billable and do not belong in a savings line.

Separate the causes before you claim the saving. Mechanical rejections — wrong procedure revision cited, missing calibration block reference, transposed CML identifier, report signed by an unqualified level, incorrect acceptance criteria pulled from the wrong code edition — are the ones a properly configured system prevents at data entry. Interpretive rejections, where the client disputes a call, are not. Split your reject population between the two and only monetise the first half. A model that claims all rework disappears will not survive review.

Line three: certification currency, and the cost of finding out at the gate

Certification generates two distinct costs, and they need separate rows. The first is chasing: coordinator hours spent every month confirming that each technician mobilising to a site holds a current ticket, a current vision test, a current site induction and a current medical. The second is lapse: a technician turned back at the gate, a crew standing down, and a client relationship that now carries a mark against it.

Chasing is easy to count. Ask the coordinator how many hours a month they spend verifying credentials before mobilisation, then multiply by twelve. The underlying schemes make the workload unavoidable — an employer-written practice under ASNT Recommended Practice No. SNT-TC-1A (2024) sets its own recertification intervals, ISO 9712:2021 certificates carry a maximum five-year validity with a defined renewal window, and API's Program Document ICP-PD-102-Inspector requires 24 CPD hours per three-year certification cycle alongside continued inspection experience and a six-year web quiz. Different clocks, one coordinator.

Lapse is counted as events. Pull the number of site-access rejections in the last twelve months and multiply by the crew hours lost each time — not one technician's hours, the whole crew's, plus travel already incurred. Add any contractual consequence you can document. For the hours and scoring rules behind the schemes themselves, see our NAS 410 certification requirements breakdown and the cross-scheme NDT training hours matrix.

Line four: the gap between paid field hours and invoiced field hours

This is the line most contractors have never measured, and often the largest one in the model. Take payroll field hours for a defined period and set them against invoiced field hours for the same period and the same crews. The difference is work you paid for and did not bill. It is not fraud and it is not laziness — it is the predictable result of authorising work verbally in a live plant and reconstructing it from memory a fortnight later.

The gap has consistent hiding places. Standby time during a permit delay that nobody logged. Travel that the contract allows but the timesheet never claimed. Overtime worked before written approval arrived, then written off to keep the client comfortable. Scope added by a supervisor at the workface and never converted into a variation. Each of these is a data-capture failure at the point of work, which is exactly the failure a mobile field capture tool addresses.

Value this line at your bill rate, not your cost rate, because recovering it produces revenue rather than avoiding expense. The worked table above values it at cost rate deliberately, to keep the total conservative. If you value it correctly it becomes the dominant line for any firm above roughly twenty technicians, which is a useful signal about where your management attention belongs regardless of what software you buy.

The arithmetic, written out end to end

Here is the twelve-technician example in full so it can be checked line by line. Inputs: 3,200 reports issued last year; median report handling falling from 45 to 20 minutes; reject rate falling from 6% to 3% at 90 minutes per revision cycle; certification chasing falling from 6.0 to 0.5 coordinator hours per month; three gate turnbacks at 16 crew hours each; two calibration-recall re-shoots at 24 crew hours each; 22,800 paid field hours with 1.5% recovered into invoices.

The multiplications: 25 minutes × 3,200 reports = 80,000 minutes = 1,333 hours. 96 avoided rejections × 90 minutes = 144 hours. 5.5 hours × 12 months = 66 hours. 3 × 16 = 48 hours. 2 × 24 = 48 hours. 22,800 × 1.5% = 342 hours. Total 1,981 hours. At a loaded internal cost of $65 per hour, that is $128,700 a year, of which $22,200 is recoverable revenue rather than avoided cost.

Now build the denominator. Take the annual figure the vendor quotes you — subscription plus implementation plus your own internal effort hours converted at the same loaded rate — and divide it into $128,700 to get a payback period in months. Do not accept a model that omits your internal hours. And halve every benefit input before you present it; a case that still clears the threshold at half strength is a case that will not be argued with.

The other side of the ledger

A credible model has a cost side with the same level of detail as the benefit side. Ask every vendor for five numbers in writing before you calculate anything: configuration hours on their side, configuration hours expected from your team, migration hours for legacy records, training hours per user role, and the planned length of parallel running. Vendors who will not commit these to writing are telling you something about how the implementation will go.

Then add the costs no vendor quotes. Someone inside your company has to own the system — writing templates, maintaining the procedure library, keeping the client list and the equipment register current. That is a real fraction of a real person, and it recurs every year. Change management is the other unbudgeted line: technicians who have written reports the same way for fifteen years will need supervised time to switch, and that time is not billable.

Data migration deserves particular scepticism. Historic thickness readings, CML identifiers and calibration certificates that live in spreadsheets and scanned PDFs do not migrate cleanly, and the cleanup effort is proportional to how disciplined your naming has been. Scope migration explicitly — decide what genuinely needs to come across versus what stays archived and searchable — and cost it. Our NDT software RFP requirements checklist sets out the questions that surface these numbers before contract.

Sensitivity: which input actually moves the answer

Run the model three times: at your measured inputs, at 70% of every benefit input, and at 130%. Two things become obvious immediately. Report volume and administrative minutes dominate the total, so those two numbers deserve the most measurement effort and the most scrutiny from your reviewer. Get them from records rather than recollection, and the whole model firms up.

The certification and calibration lines behave differently. In dollar terms they are small — a few thousand a year in the worked example — but they carry the highest variance, because a single lapse on the wrong contract can cost far more than the modelled crew hours. Do not inflate the dollar figure to reflect that. Present those rows at their honest value and describe the tail risk separately in words. Inflating a small line to make a case is exactly what gets business cases rejected.

If the model only clears your threshold at 130% of measured inputs, the honest conclusion is that you do not yet have the case. That is a legitimate outcome. It usually means report volume is too low for the admin line to carry the investment, in which case the right next move is to fix data capture at the workface first and revisit the full system when volume grows.

What the model deliberately cannot capture

Four real benefits resist honest quantification, and they should be listed rather than monetised. Client retention: a contractor whose reports arrive same-day and never come back for revision gets renewed on terms that a slow contractor does not. Tender qualification: an increasing number of framework agreements require demonstrable data-handover capability, and failing that screen removes you from the bid list entirely, which is a revenue event with no denominator.

The third is audit posture. When an accreditation body or a client quality auditor asks to trace a specific report back to the technician's certification status on the day of the inspection, the procedure revision in force, and the instrument's calibration record, the answer is either a query or a fortnight of archaeology. Firms holding or seeking accreditation should read that requirement in detail — see ISO 17020 software for NDT inspection bodies for the clause-to-record mapping.

The fourth is recruitment and retention. Experienced technicians consistently rank paperwork burden among their reasons for leaving contracting work. Replacing a certified Level II costs recruitment fees, onboarding time and lost billable weeks. You can estimate it, but you cannot defend the estimate, so use these four as tie-breakers between shortlisted options rather than as line items in the total.

Baseline for thirty days before you sign anything

The single highest-value action in this whole exercise costs nothing and takes a month. Starting on the first of next month, have your coordinator log four fields for every report: the timestamp field data arrived in the office, the timestamp the file was accepted by the client, whether the report was re-issued at any revision, and any crew hours lost to a credential or calibration problem. Thirty days of that gives you a measured baseline instead of a remembered one.

That baseline does two jobs. Before purchase, it turns your business case from estimate into evidence, and it lets you challenge any vendor demonstration against your own numbers rather than their reference customer's. After purchase, it becomes the control group — you can rerun the same four fields ninety days post go-live and produce a genuine before-and-after that your finance function will accept, which is the only way software investment gets renewed.

If you want the model applied to your actual report volume, method mix and client list rather than the illustrative twelve-technician case above, send us those four numbers and we will run it with you and show the working. Atlantis builds NDT reporting, digital twin and Odoo-based ERP systems for inspection contractors — affordable, accessible and fully customisable, with a quote issued against your scope. Reach us at /contact or info@atlantisndt.com.

Request a consultation