Sunday night, forty indoor units
The engineer serviced a multi-storey office on Friday: dozens of indoor units, three condensers, a set of readings per system, photos of dirty filters and a corroded drain line. He has a notebook, a camera roll of photos and a form that needs a row per unit. On Sunday evening he types it up, matches photos to unit numbers from memory, and emails it to the office, who reformat it and send it to the client on Wednesday.
The facilities manager wanted it on Friday, because her director asked about the noisy unit on the fourth floor.
Reports built after the fact
The information needed for a good report is all gathered on site. The problem is that it is gathered in the wrong shape: free notes, unlabelled photos, readings on paper. Turning it into a document afterwards is where the time goes, and where errors creep in.
- Readings and checks are written on paper or in phone notes.
- Photos are not linked to specific units.
- Each engineer writes reports differently.
- The office reformats reports before sending.
- Defects are buried in text rather than listed for action.
What slow reports cost
Engineer evenings, which contribute to tiredness and turnover. Office time reformatting. Clients who wait days for a report and wonder what they are paying for. Defects that should become quotes get lost in paragraphs, which means remedial work you could have done is not raised. And inconsistent reports make a capable team look disorganised to the facilities managers who compare contractors.
Facilities managers in particular are measured on documentation. They need to show their own clients or landlords that the plant is maintained, and a late, inconsistent report makes their job harder, which is remembered when contracts are reviewed.
It also costs you evidence. If a unit fails and the client asks what was found at the last service, a clear per-unit record is far more useful than a narrative typed on Sunday night.
The on-site report flow we build
- The engineer's app opens the visit with the site's asset list. They tap each unit as they service it.
- For each unit, the app asks for the checks and readings your template requires, as fields with sensible ranges. Values outside the range your engineers set are highlighted for a comment.
- Photos are taken inside the unit's page, so they are attached to the right asset automatically.
- Defects are recorded as separate items with severity and a recommendation, not as prose.
- When the visit closes, a branded report is assembled: summary, unit-by-unit results, photos and a defects list. It goes to the client contacts and is stored on the site record.
- Defects feed a remedial quote queue for the office, so nothing found on site is lost.
| Report element | Written up later | Captured on site |
|---|---|---|
| Readings | Transcribed from paper | Entered per unit, range-checked |
| Photos | Matched from memory | Attached to the unit |
| Defects | Buried in text | Listed with severity |
| Format | Varies by engineer | Your branded template |
| Delivery | Days later | When the visit closes |
The checks and ranges are set by your engineers and manufacturers' guidance. The app records them; it does not decide what is acceptable.
Reports that are done when the job is
Engineers finish on site and go home. The client has the report the same day, in the same format as every other visit. Defects appear in the office's queue for quoting instead of waiting for someone to read the report. And the history per unit builds up over time, so the next engineer can see what was found last time before opening the casing.
Office staff stop reformatting and start following up the defects, which is a better use of the same hours.
Is this your reporting?
- Engineers write reports in the evening or at weekends.
- Clients wait days for service reports.
- Photos in reports are sometimes attached to the wrong unit.
- Reports look different depending on the engineer.
- Defects found on site are not always turned into quotes.