Why Council Tree Registers Fail in the Field

Most councils have a tree register. Most councils are also quietly uncertain about how accurate it is.

The honest answer, in most cases, is that the register was built once — through a procured tree audit or an in-house GIS exercise — and then slowly drifted as the world kept moving. Trees were removed. New trees were planted. Inspections were done but the results lived in PDFs. Contractors did work but the register was not the place the closeout landed.

The register itself rarely fails. What fails is the operational loop that should keep updating it.

Failure pattern 1: The register was built as a survey, not as a system

A tree audit produces a snapshot. A tree management system produces a living record. Many registers were funded as audits, which means they were never designed to receive ongoing updates from inspections, work orders, contractor reports and resident requests.

The fix is not to redo the audit. The fix is to wrap an operational loop around the existing data and decide which fields will be updated routinely.

Failure pattern 2: GIS is treated as the source of truth

GIS is excellent for spatial visualisation. It is usually a poor place to record condition history, defect notes, work orders and contractor evidence. When GIS is the only system, councils end up with rich location data and thin operational data.

The fix is to keep GIS for what it is good at — spatial reference and reporting — and connect it to an operational record that owns the condition, risk, works and evidence fields.

Failure pattern 3: Inspections end as PDF reports

A tree inspection is only as valuable as the changes it triggers. If the inspection report is a PDF in someone's inbox, the register did not learn anything. The condition rating did not move. The recommended action did not become a work order. The next review date is not on a list.

The fix is to define which inspection outputs must update the asset record — typically condition rating, identified defects, risk rating, recommended actions and next inspection date — and treat the PDF as supporting evidence, not the result.

Failure pattern 4: Work orders close in finance, not in the register

When tree works close out against a finance code rather than against the tree record, the register has no way to know what changed. The asset record falls behind real-world activity.

The fix is to require the works closeout to also update the affected tree records: latest known condition, work performed, date, contractor and attached evidence.

Failure pattern 5: Contractor evidence is detached from the tree

Contractor photos, forms and GPS traces are often attached to the job, not the tree. That is fine for paying the invoice. It is not fine for keeping the register defensible. Two years later, when a resident asks what happened to the tree out the front, no one can find the photo.

The fix is to attach evidence to the tree record, in addition to the job record.

Failure pattern 6: Resident requests run in a separate system

Resident tree requests live in customer service systems. The same tree may collect three requests over twelve months. If those requests do not touch the tree record, the register never sees the pattern, and the inspector who eventually visits the tree has no idea about its complaint history.

The fix is to log resident requests against the tree record where the tree is identifiable, not only against the request ticket.

Failure pattern 7: No one is responsible for register quality

Operational data degrades by default. Without a named owner for register quality — usually someone in the parks, environment or asset team — the register has no advocate. Other priorities will always win.

The fix is to make register quality someone's accountability, with a short list of measurable checks: percentage of trees with a recent inspection, percentage with a current condition rating, percentage of recent works closed out against the tree record, and so on.

The pattern underneath all of these

In each case, the register is treated as a destination rather than a working record. The fix is to design the operational loop so that inspections, works, contractor activity and resident requests all update the same tree record, with the GIS layer as the spatial view rather than the operational system.