Evaluate site inspection software with a failed inspection

Identify the package, inspection stage, applicable specification, approved inspection and test plan, required records and reviewing authority. The quality and engineering owners determine the technical criteria and any hold or witness requirements. Software configuration should implement those decisions without inventing thresholds.

Record the revision used for each inspection. If a template changes, historical inspections should retain the criteria and form version that applied when they were performed. A current template displayed over an old result can misrepresent what was actually checked.

The Works Manual's quality-assurance section provides public-works context for inspection and quality records. The project’s approved plan and contract determine the required evidence and authority; review a vendor’s standard checklist against them before configuration.

In this fictional example, the device holds an earlier copy of the inspection record. The inspector submits a pass while offline. Meanwhile, the quality owner records a hold based on newer evidence. When the device reconnects, both records must remain visible and the newer hold must not disappear through a last-upload-wins rule.

The system should flag the conflict and route it to the authorised reviewer. That reviewer checks the timing, evidence, applicable revision and actual conditions, then records the disposition under the project's quality process. The offline pass remains part of the history, with its status explained.

Test the user's experience, not only the database result. The inspector should know that their upload is pending review, and downstream users should not see an unqualified accepted status while the conflict is unresolved. The quality team needs a practical queue rather than an obscure technical error log.

A mobile form linked to a controlled register may be adequate for a narrow, stable inspection process. An existing project platform can simplify locations, drawings and contractor access. A dedicated quality system may offer richer inspection and nonconformance workflows. Compare the actual workflow and maintenance burden, not a feature count.

Give each option the same examples: a failed inspection, a revised criterion, a retest, an offline conflict and a reviewer whose authority changes. Record whether each behaviour is native, configurable or custom. Include the effort required to maintain templates and permissions across projects.

A product can produce excellent inspection PDFs while providing weak history or poor offline recovery. Ask how records are retrieved, exported and reconciled at handover. The receiving team may need the full evidence chain, not just the latest passed certificate.

A failed inspection should link to its disposition and any subsequent retest. Do not overwrite the failed result when a later test passes. The history explains what changed, who authorised the next step and which evidence supports the accepted outcome.

Use stable item, location and inspection identities so the retest can be associated correctly. Similar descriptions or adjacent asset tags are not enough. If a record was attached to the wrong item, correct the association through a controlled history rather than deleting the inconvenient evidence.

Procore's observation response states illustrate a separate submission-and-review pattern. That product example can inform action handling, but it does not replace the project's technical inspection or nonconformance procedure. Keep the inspection result and corrective-action state distinct where they answer different questions.

The user who can collect evidence may not be authorised to approve it. Configure roles by the actual scope: project, discipline, package or inspection type. Test an attempted approval outside that scope using an ordinary account.

When an approver leaves or changes role, retain their historical decisions but remove current authority as required. Check delegated approval, shared devices, notifications and integration access. A permission removed from the desktop screen should not remain available through a mobile endpoint.

The interface should explain the next owner when an action is blocked. Users are more likely to maintain the controlled process if they can see how to resolve an exception without creating a parallel email approval that the system never records.

Each record should connect the inspection basis, observed result, attachments, identity, timing and review. Capture and upload times may differ; preserve both where relevant. For photographs, provide enough location and descriptive context that another reviewer can understand them.

Test an interrupted upload, duplicate submission and lost device under the proposed operating arrangement. Confirm what is stored locally, what has reached the server and how the user knows the difference. The approved quality process must define any permitted work while current status cannot be confirmed.

Export a complete sample package and inspect it outside the vendor's live environment. Check links, identifiers, revisions and failure history. Confirm that restricted information remains appropriately protected and that the organisation can recover its records at contract end.

Run a bounded trial with field inspectors, the quality owner and a receiving user. Acceptance should include correct conflict routing, preserved history, scoped authority and usable exports. A critical status-overwrite defect should remain a release blocker even if the forms are otherwise easy to use.

The objective is a trustworthy record of what was inspected and accepted under which basis. A software pass status is meaningful only when that chain is intact.

1. Define the approved inspection basis and decision roles for one package.
2. Demonstrate the offline-pass versus newer-hold conflict in every shortlisted tool.
3. Test failure, retest, changed authority and complete export.
4. Resolve critical history and permission gaps before using the system for live acceptance.