Keep the finding connected to the follow-up.

Two ways into the same work record.

Some return visits begin with a failed inspection check. Others begin with a customer reporting a new problem. Squigg supports recorded targeted work in that asset context, so the reported problem does not become an isolated note with no connection to earlier visits.

For a follow-up linked to an inspection, the original finding provides the starting point. For a reactive call-out, record the reported problem and the asset involved. Both journeys need a clear account of what the engineer found and did.

Record the work, not just a completion tick.

Keep the reported problem separate from the findings and work carried out. Record the outcome and any further action required. Photos can support the account of the work, while a works-completed report gives the customer a record of the visit.

In the fictional AHU-023 example, the reported issue is a worn drive belt. The follow-up records removal and replacement, restarting the unit and checking operation. “Fixed” then describes the recorded outcome; it is not a substitute for explaining the work.

• Reported problem
• Findings and work carried out
• Evidence linked to the work
• Recorded outcome and further action

Leave a useful starting point for the next engineer.

Completed follow-ups become part of the asset’s history. If the customer calls again, the earlier inspection and return visit can be reviewed together. This avoids rebuilding context from Word documents, phone photos and separate email threads.

Not every call-out confirms or resolves a fault. A No fault found outcome leaves the reported fault unconfirmed. The record should preserve that uncertainty rather than implying every completed visit is a repair.