What Belongs on a Council Tree Inspection Form

Inspection forms grow over time. Every incident, every audit finding and every consultant adds another field. After a few years the form is longer, slower to complete and no more useful than it was.

The fix is not to redesign the form from a blank page. It is to map every existing field to a destination and remove the ones that have nowhere to go.

The destinations a field can have

A field on an inspection form is justified by one of these destinations:

• It updates the tree record (condition, risk, defect notes, next action)
• It triggers a work order or follow-up
• It feeds a routine report (canopy, planting, risk band roll-up)
• It supports compliance evidence (method declaration, level of assessment)
• It captures something the next inspector needs to know

A field that has no destination is filler. It slows down the inspection, dilutes the inspector's attention and does not improve the record.

The fields almost every form should keep

• Tree identifier (asset ID where available, otherwise GPS + photo)
• Date and inspector
• Inspection method declaration
• Current condition rating
• Identified defects with severity
• Risk rating using the council's framework
• Recommended action and target timeframe
• Next inspection date
• Photos and GPS

Those nine fields cover what most councils actually need from a routine inspection.

The fields most forms could probably drop

• Categorical fields with overlapping definitions that no one can apply consistently
• Free-text fields that duplicate structured ones
• Measurements that no one uses downstream (precise canopy spread, when the council does not roll it up)
• Codes that were added for a one-off report years ago
• Fields whose answers always default the same way

If you cannot point to where a field is used in decisions, it is probably filler.

The fields worth adding if they are not there

Some fields are surprisingly often missing:

• Inspection method (level 1 visual, level 2, etc.) — important for defensibility
• A clear "next action" with target timeframe — not just a free-text note
• A "next review date" — separate from the next action
• A "confidence" or "qualification" flag where the inspector is unsure and a higher-level assessment is recommended

These improve the operational value of each inspection without adding much time.

Form design follows record design

If the tree record has clear fields for condition, risk, defects, recommended action and next review date, the inspection form should map directly to those. Each field on the form should land on a corresponding field on the record. When form design follows record design, closeout becomes mechanical rather than judgement-heavy.

The reverse — designing the form first and then trying to figure out where its outputs go — is one of the more common reasons inspection programs collect lots of data and improve few decisions.