A Job, Report and Field Capture Platform for an Arboriculture Practice

The problem

The client is an Adelaide consulting arboriculture practice. Councils,
developers and property owners engage them to assess trees, and what they sell
is the report: a formal document that has to stand up in a development
application. The reports are the product, and they were slow to make.

Tree data was recorded on site, typed into a spreadsheet, then retyped into a
report. Every hop was a chance to get a diameter wrong.

The reports themselves were six Word documents that shared most of their
content. Updating a standards citation meant finding every template that
mentioned it, and the ones that got missed shipped anyway.

Around all that sat the quoting, the drafting contractor and the chasing of
payment, with no single place to see where any of it stood.

A job that runs on a journey

Every job moves through a defined sequence, from new enquiry to report
delivered, with drafting and on-hold as side lanes. The portal advances the
job when the underlying thing happens, not when someone remembers to update a
status. Setting a booking date moves it and emails the client. Field data
arriving moves it again.

Staff can override any of it, and when they do the portal stops
auto-advancing that job and says so. Automation that cannot be overruled is
worse than none, because people stop trusting the status.

An Android app for the assessment

Site data had been going into an off-the-shelf app the practice paid for and
could not shape. We built a replacement they own.

The work happens in back yards and on building sites with no signal, so the
app is offline first: its own SQLite database, syncing when it can. An
arborist records each tree with its species, dimensions, protection zones,
health, structure and retention value, with a GPS fix and photographs. A
satellite map shows a pin per tree so the survey takes shape as they walk it,
and voice notes are transcribed on the handset, which matters when both hands
are busy.

Arborists can start a job from the phone too, so a walk-up does not wait for
someone at a desk. Handsets enrol from the portal with a one-time code.

Reports assembled from blocks

A report is no longer a document. It is a template: an ordered list of
sections, each pointing at a reusable block. Some blocks are fixed text, like
the retention definitions. Some are tables built from the tree data. The rest
are AI prompts that write this job's narrative from this job's trees.

Six report types are composed from one library, so a wording change happens
once. Templates are versioned, so you can see what any report was built from
on the day it went out.

The office controls the AI. The prompts behind the narrative sections are
editable in the portal, so when a report reads wrong the fix is a wording
change by the arborist, not a ticket to us. Everything generated lands in an
editor for review. Nothing reaches a client unread.

Drafting, tracked

Drafting is done by an external contractor, and the portal does not try to
replace their tools. It tracks the handoff. Send the job to CAD and it enters
a queue with its age visible; sit too long and a reminder goes out. Finished
drawings upload into named slots and render in the right place in the report,
with nobody pasting images into a document. The contractor gets a login
showing their own jobs and nothing else.

Selling the report, not the invoice

Pricing runs off the rate card, with ad hoc line items and an override that
records its reason. The settled price is snapshotted onto the report when it
is sent, so later edits do not rewrite history.

Delivery is the part worth copying. The client gets a link, not an
attachment. It opens a preview with the rest blurred, and payment unlocks the
PDF. The report is the product, so the report is what gets sold, and the
practice stopped chasing invoices for work already delivered.

Two decisions worth stealing

The sync is idempotent and deferential. Re-running it updates rather than
duplicates, and it leaves the office's manual overrides alone instead of
stamping over them with field values. Field data is an input, not an
authority.

Photographs and PDFs go straight to object storage, so they survive a deploy
without a second backup path to maintain.