Forty buildings surveyed, forty reports to write
A housing association asks your practice to survey the structural condition of its blocks: concrete frames, balconies, walkways, masonry, roofs. Engineers spend weeks on site, with notebooks, cameras and a spreadsheet of defects. Then comes the write-up: a report per building in the client's format, a defect schedule with priorities, and a portfolio summary so the client can plan work.
The typing takes longer than the surveying. Priorities and descriptions drift between engineers. And when the client asks for all balcony defects across every block, someone has to pull them out of forty separate documents.
Why portfolio surveys are so slow to report
- Site notes and photos are captured separately and matched later.
- Each engineer describes and prioritises defects slightly differently.
- Reports are Word documents built one by one.
- The portfolio summary is compiled by hand from the individual reports.
- Clients want data they can use in their asset system, and reports give them prose.
Scale changes the nature of the job. One condition survey is an engineering report. Forty is a data project, and treating it like forty separate reports means the client ends up with forty documents rather than a picture of their estate.
What that costs
| Issue | Effect |
|---|---|
| Long write-up after surveys | Report delivery slips, client waits |
| Inconsistent descriptions | Harder for the client to compare and plan |
| Portfolio queries answered by hand | Unbilled engineer time |
| No structured data for the client | Their asset system gets retyped too |
Consistency is what the client is really buying. An estate manager deciding which blocks to repair first needs priorities that mean the same thing across every building. If one engineer's 'urgent' is another's 'monitor', the portfolio summary misleads, however carefully each individual report was written.
How we build portfolio survey reporting
- The client's building list, with addresses, block names and elements, is loaded before surveying starts.
- Your defect categories, element types and priority definitions are set up as pick lists, with free text for the engineer's description.
- On site, engineers record each defect with photo, location, element, category, priority and notes, on a tablet that works offline.
- A language model can tidy dictated notes into clear sentences, which the engineer reviews. Priorities and assessments are always the engineer's.
- A building report is produced in the client's or your template, with defects, photos and a summary.
- The defect schedule and portfolio summary are produced from the same data, with filters by element, priority or building.
- Data is exported in a structure the client can import into their asset management system.
A senior engineer reviews priorities across the portfolio before issue, using a view that shows every engineer's entries side by side, which makes inconsistencies easy to spot.
We usually build the defect categories and priority definitions with the senior engineer leading the commission, and trial the app on one or two buildings before the full programme. Adjustments after the trial are cheap; after forty buildings they are not.
What delivery looks like afterwards
Reports are drafted as the surveys progress, and the office time goes on review rather than typing. The portfolio summary is ready when the last building is surveyed.
When the client asks about all balcony defects, the answer is a filter.
Is this your survey process?
- Portfolio surveys take longer to write up than to carry out.
- Defect descriptions vary by engineer.
- Portfolio summaries are compiled by hand.
- Clients ask for data in a format you do not have.
- Photos are matched to defects at the desk.