Most roof survey reports are built for the wrong reader. They are long PDFs with a photograph on every page, designed to look thorough, and they are opened once, skimmed, and filed. The person who actually has to do something with the findings, the asset manager or the surveyor planning the next programme, needs the information in the system they work in, not in a document.
This article describes what a roof evidence pack should contain if it is going to be used rather than filed.
Start with who reads it
Three people receive a roof survey and each wants something different.
The asset manager wants component condition data in the stock condition format their system already uses, keyed by UPRN, so it can be imported without retyping. Their measure of a good survey is how quickly it disappears into the database.
The surveyor or repairs manager wants to see the defects: where they are, how bad they look, which ones need doing this month. Their measure is whether they can brief a contractor from it without a site visit.
The director, board or regulator wants assurance: that the roofs were looked at competently, on a known date, with known limitations, and that anything dangerous was dealt with. Their measure is whether the document would stand up if something went wrong later.
A pack that serves all three has four parts.
Part one: the component data
One row per roof component per property. The components follow the way UK housing data is normally structured: roof covering, roof structure, chimney, rainwater goods, flashings, fascia and soffit, rooflights and vents, parapet, flat roof area. Each row carries the UPRN, address, block reference and roof zone, the material observed, the observed condition on the client's own scale, a priority code, notes, and the photo references that support the row.
Two points matter here. The condition scale should be the client's, whether that is 1 to 4, Good to Bad, or A to D, because a survey delivered on a different scale creates a translation job that nobody does. And on an evidence pack, as opposed to a rated survey signed by a chartered surveyor, the condition value is an observation, not a professional opinion. The pack should say so.
For rated surveys, where a competent signatory has been engaged, the same rows gain remaining-life bands, replacement-year bands and indicative cost bands. Bands, not numbers. A single visual pass cannot honestly say a covering has seven years left; it can say five to ten.
Twenty to fifty roofs on one estate, flown to a standard shot list, reviewed by a named person, delivered as component rows your asset system can import.
Part two: the observations
Each defect the reviewer accepted becomes an observation: property, component, defect type from a fixed list, a plain-English sentence describing what is visible, a priority code, and a photograph with the location marked. Observations are numbered so the report, the photo pack and the data all refer to the same thing.
The fixed defect list is important. Free-text descriptions of the same problem in four different ways make the data useless for programme planning. A slipped tile is a slipped tile whether it is on a 1930s semi or a 2010 block.
Part three: the photo pack
The photographs are where most packs go wrong by including too much. A drone captures 100 to 200 stills per house. The client needs perhaps 40: a crop of each accepted observation with the defect circled and numbered, and one annotated overview per slope with the callout numbers placed on it.
Each file should be named so it files itself: UPRN, roof zone, slope, callout number. A folder of numbered images that cannot be attributed to a property is a folder nobody opens.
Two exclusions are deliberate. Frames that mainly show neighbouring property or people should not be delivered. And location metadata should be stripped from the delivered images, with the coordinates held only in the survey record.
Part four: the report
The report is the cover letter for the data. It should carry a cover with the property list, the flight details, and the limitations recorded on the day: wind, slopes obscured, chimneys not seen. It should include the priority schedule, one section per property with the annotated overviews and the observation table, and a methodology section that says plainly what the survey is and is not.
It should name the reviewer. If artificial intelligence was used to pre-screen the imagery, it should say so, and it should be clear that a person accepted every observation. And it should be frozen on issue: a report that can quietly change after the client has acted on it is not evidence.
The urgent flag
One process sits outside the pack and matters more than any of it. If the reviewer sees something that needs making safe, a loose stack above a doorway, a slate hanging over a path, that item should reach the client by phone on the day it is reviewed, before the report exists. The client's own hazard process then decides what happens next. A P1 item discovered in a PDF three weeks later helps nobody.
A checklist for buyers
When comparing providers, ask:
- Will I get component rows per UPRN in my own import format, or only a PDF?
- What condition scale will the rows use, and is it mine?
- Are photographs named by property and slope, and are neighbours' frames excluded?
- Who reviews the imagery, and who signs the report?
- What happens if you find something dangerous on the day?
- Is the report frozen once issued?
A provider who can answer all six without hesitation is selling evidence. One who can only answer the first two is selling photographs.