What Inspection Management Software Must Do That Field-Service Tools Cannot

Certification currency is a scheduling constraint, not a report

A field-service scheduler asks whether a person is free. An inspection scheduler asks whether a person is free, qualified in the method, current at the level the client's written practice requires, endorsed for the specific technique, and inducted for that site. The last four constraints all carry expiry dates that move independently of each other. Software modeling availability alone will happily send a perfectly free technician whose UT Level II lapsed nine days ago, and the schedule will look correct on screen the entire time.

The enforcement point matters more than the data. Every system stores certification dates; few refuse the assignment. The behavior to demand is a hard block at assignment and a second check at dispatch, because jobs get rescheduled and a certificate valid when the job was booked in March expires before the rescheduled date in June. Certification tracking sets out the register that check runs against — method, level, technique endorsements, vision test date, and the written-practice rule governing each.

Recertification is the second half of the problem. A block at dispatch protects the client; a forward-looking view protects your schedule. Ninety, sixty and thirty-day flags against every qualification let a coordinator move examinations and refresher training into gaps that already exist rather than into the week a large campaign starts. The comparison of certification expiry tracking methods works through the spreadsheet, calendar and system approaches to exactly that flag logic.

Calibration status that blocks a job

Instrument calibration is handled in most systems as a maintenance reminder. In an inspection business it is a gate. The instrument, the probes, the wedges, the cables and the reference blocks each carry a certificate with a date, and the job needs all of them valid through the last day on site — not merely on the day the crew leaves the shop. A five-day turnaround starting on the twenty-eighth with a certificate expiring on the thirtieth is a nonconformance already written into the schedule.

So the check runs against the job's end date, at the moment equipment is allocated, and it has to understand the asset tree: a certificate on the flaw detector does not cover the wedge. Equipment calibration tracking describes the register — asset, serial, certificate, issuing laboratory, interval, next due, and current custody. Custody is the field that tells a coordinator at seven in the morning that the only in-calibration thickness gauge is three hundred miles away in somebody's truck.

Two failure modes justify the whole feature. The first is data taken on an instrument whose certificate lapsed, which forces rework at your cost and reappears at the next audit. The second is quieter: a job delayed because nobody knew the equipment was out until the crew opened the case on site. Both come from a register that is read rather than enforced. Report validation exists partly because the first failure is usually caught downstream, in the report, by somebody else.

Procedure and technique revision control

The written procedure is a controlled document and the technique sheet is its job-specific child. Both carry revisions, both are approved by a Level III, and clients frequently hold an approved copy of one specific revision inside their own document management system. When a procedure is revised, every open work order citing the old revision becomes a question that has to be answered deliberately: does this job continue under the revision approved for the contract, or move to the current one?

Software that stores procedures as file attachments cannot answer that. What is needed is a procedure object with a revision number, an approval record naming the Level III and the date, a client-approval status held per contract, and a link from every work order to the specific revision in force for that job. The report then prints the revision the work was actually performed under, which is the field an auditor reads before they read anything else.

The control extends to who may change what. A coordinator can attach a technique sheet; only the Level III can approve a revision or edit an acceptance criterion. Role separation inside the software is the digital form of the written practice, and a system without it puts a responsible individual's stamp on documents they did not control. Compliance tracking covers how the approval chain is recorded and how it is retrieved when somebody asks for it three years later.

Report numbering that survives an audit

A report number is an identifier in a contract, a line on an invoice, a reference in the client's own records, and the key an auditor uses to pull a file five years later. It has to be unique, sequential within its scheme, generated by the system rather than typed by a person, and carry its own revision lineage. Free-text numbering produces duplicates inside the first year and gaps that nobody left on purpose and nobody can explain afterwards.

The scheme itself is usually client-specific: a prefix per client or contract, a method code, a year, a sequence, and a revision suffix. The requirement is that the system generates it from the job record and refuses to reissue the same number without incrementing the revision. Reissue must preserve the superseded document, the reason for reissue, the person who authorized it, and the timestamp, because "we sent them a corrected version" is not an answer that survives contact with an auditor.

Test this during any trial. Issue a report, correct a reading, reissue it, then ask the system for both versions and the difference between them. A product that shows you the original, the revision, the specific change and the authorizer in under a minute has solved the problem completely. One that shows you only the current file has moved your audit exposure out of the software and into a folder on somebody's desktop.

Client-visible status without a phone call

Every hour a coordinator spends answering "where is my report" is an hour the software was bought to remove. Client-visible status means the client sees, without calling, that the job is scheduled, that the crew is on site, that the data is under review by the Level III, and that the report has been issued. The list of states is short. The value is entirely in their being accurate without anyone updating them by hand.

Accuracy comes from making the states byproducts of work already recorded. Dispatch sets crew en route. The first field record sets on site. Submission for review sets under review. Report issue sets issued and releases the document to the portal. A status field a coordinator has to remember to change is a status field that is wrong by Wednesday. The client portal describes the permission model deciding which client contacts see which jobs and which sites.

Larger accounts now write portal or SFTP delivery into the contract, alongside a required turnaround measured from demobilization to report issue. Both are measurable only if the system timestamps the underlying events. A contractor who can show a client its own on-time delivery rate, per site, from its own records, is in a materially different negotiation from one relying on the client's recollection of last quarter.

The field layer: capture once, offline, reconcile cleanly

The constraint layer is worthless if the data never arrives. Field capture happens inside tanks, in radiography vaults, under scaffolding, on offshore platforms and in plants where phones are prohibited, so the tablet has to hold a complete job — readings, sketches, photographs, indication records, signatures — and function with no connection for a full shift. Offline field data capture covers the sync model and the conflict rules that stop two devices editing one job from destroying each other's work.

The forms have to be method-specific. A UT thickness form needs CML identifiers, nominal thickness, previous reading, current reading and calculated remaining life. An MT form needs technique, yoke and current, particle type, lighting level and a written indication description. A single generic form with custom fields produces data that nobody can query a year later, which defeats the entire reason for capturing it digitally instead of on paper.

Capture also carries the compliance payload. The technician's identity and certification, the instrument serial and its calibration reference, the procedure revision, and the calibration verification performed at the start and end of the shift all attach to the record automatically, because the system already knows which technician was dispatched with which instrument under which procedure. That inheritance is the entire argument for these layers being one system rather than three that email each other.

Where the operational core meets the money

The same work order that carried the qualification constraints carries the cost. Hours by technician at a certification-dependent rate, per-diem, mileage, consumables, equipment on hire and subcontracted scope all attach to the job the crew was dispatched against, which turns job cost into a query rather than a month-end reconstruction. Unbilled revenue becomes visible as issued reports with no invoice line — the single most useful number a contractor can look at weekly.

Rate schedules are the part generic systems handle badly. Client contracts price by shift, by call-out, by hour with an overtime multiplier, by footage of weld, by radiograph, or by a mobilization fee plus a day rate, and the same technician can bill at different rates on two contracts on the same day. Encoding that once, in the contract record, is what turns approved timesheets into invoices without a person retyping anything.

None of this works if the operational record is thin. Costing a job to the consumable requires that the consumable was recorded in the field. Utilization requires that non-billable time was recorded honestly. The finance layer inherits the quality of the operational layer, which is the reason to build the operational core first and connect the ledger second. Contractors who reverse that order end up with accurate invoices for jobs they cannot explain.

What the data model has to hold

Nine objects carry the operation: client, site, client-owned asset or component, contract with its rate schedule, work order, technician with qualifications, equipment with calibrations, procedure with revisions, and report with revisions. Field records hang off the work order. Invoices hang off the contract and the work order. Every constraint described on this page is a rule joining two of those nine objects, which is why a product missing one of them cannot enforce the rule at all.

Assets are the object generic software gets wrong. A CMMS models assets you own, with maintenance histories and work orders you raise against yourself. An inspection contractor's assets belong to its clients, are inspected under the client's integrity program, and carry a history — thickness readings at named CMLs, indications at named welds — that the client will want handed back when the contract ends. The model has to express that ownership explicitly.

Ask a vendor to draw this model on a whiteboard in the first meeting. The drawing takes ten minutes and tells you more than a three-hour demo, because a product without a first-class procedure-revision object, or a qualification object with an expiry, cannot draw it. The NDT software category page explains why products from adjacent categories are missing these objects by design rather than by oversight.

The rollout order that works

Load the static registers first: clients, sites, technicians with current qualifications, equipment with current certificates, procedures at their current approved revisions. This is the week nobody enjoys, and it determines whether every constraint above means anything. A certification register that is ninety percent accurate produces enforcement that is ninety percent right, which is worse than no enforcement, because people learn within a fortnight to click through the warnings.

Then run scheduling and dispatch for two weeks in parallel with whatever you use now, on real jobs, with the constraints switched on. Overrides will fire. Each one is either a data error in the registers or a rule that does not match your written practice, and both are worth finding before the field layer goes live. Scheduling and crew dispatch covers the constraint set in operation and what a legitimate, recorded override looks like.

Field capture goes third, on one method with one crew, and reporting fourth. Client portal access goes last, once the status states are reliably accurate, because a client who logs in and finds stale information will not log in a second time. Atlantis delivers this layer on Odoo, cloud or on-premise, with registers, constraints, numbering and rate schedules configured to your own written practice. Ask for a demo or a quote.

Request a consultation