Recurring Defects: Why Job-Based Inspection Software Loses the Plot

Almost all inspection software organises around the job: a visit is created, evidence is attached, a report is produced, the job closes. It is a clean model that matches how work is scheduled and billed.

It also throws away the most valuable thing a repeat-inspection business generates. The building, the tower, the elevator, and the fire system all persist. The job is a moment in their history — and if history only exists inside closed job folders, nobody can see across it.

What disappears when the job is the organising unit

Each of those is answerable in a job-based system by a person doing manual work. The difference is not capability. It is whether the answer is available at the moment it is useful — which, for a recurring defect, is while the inspector is standing in front of it.

The finding job-based systems cannot produce

"This defect has now been recorded on three consecutive inspections" is one of the most consequential sentences in a repeat-inspection report. It converts a routine observation into a documented pattern of inaction, which changes how the recipient responds and creates a record that matters if the condition later causes harm.

Producing it requires linking an observation to the same observation on prior visits — which requires the prior visits to be attached to the asset rather than filed separately. In a job-based structure, the inspector has to notice the recurrence themselves, from memory or by reading last year's report before the visit. Most of the time, neither happens.

The defect lifecycle

Treating findings as belonging to the asset rather than the visit makes a lifecycle possible:

• Open — first recorded on an inspection
• Recurring — observed again on a subsequent inspection, linked to the original
• Resolved — confirmed corrected, with the inspection that confirmed it recorded
• Reopened — observed again after resolution, which is itself a meaningful signal about repair quality

That lifecycle is the raw material for everything a facilities or compliance client actually wants: what is outstanding, what keeps coming back, what was fixed and stayed fixed.

Recurrence and statutory scheduling

In compliance-driven trades — fire safety, elevator, pressure systems, many environmental permits — the next inspection is not a preference. It is a date derived from a rule, and missing it has consequences beyond an unhappy client.

Those due dates attach to the asset, not to the job. An elevator's certification expiry is a property of the elevator. Deriving the schedule from the asset means the system can say what is due, what is overdue, and what is approaching — rather than relying on a spreadsheet somebody has to remember to update.

The important design constraint is that scheduling should propose rather than book. Silently creating work in a customer's calendar destroys trust quickly. Surfacing that fourteen certificates expire within thirty days, and letting a human decide, is the useful behaviour.

What asset history is worth commercially

Three things change when history accumulates against assets rather than being scattered across job folders:

1. Reports get better. Recurrence, trend, and prior-condition context are available without research.
2. Renewal gets easier. A client who can see their own portfolio's compliance position in one place has a reason to stay that is not about price.
3. The record becomes an asset in itself. Several years of structured inspection history against known assets is genuinely valuable, and it is not something a competitor can replicate by matching a feature list.

What to look for when evaluating

• Do inspections attach to a persistent asset record, or only to a job?
• Can assets nest — a site containing systems containing components?
• Are prior open findings surfaced during a new inspection, in the field, at the relevant checklist item?
• Can a defect be marked resolved, and does reappearance link back to the original?
• Are due dates derived from a rule attached to the asset?
• Can a portfolio-level compliance position be produced without manual assembly?

These asset-history questions sit alongside offline behavior and evidence integrity in the complete inspection software buyer’s checklist.

A system that cannot answer these is not necessarily a bad tool. It is a tool for one-off inspections being used for recurring work, which is a different problem.