Building and Pest Inspections
A Custom Inspection Management Portal for a Building and Pest Firm
This Canberra inspection firm runs every booking through five teams and four outside parties. Osher Digital replaced their legacy booking system with a portal that carries the whole process: parallel team checklists on every job, route-aware scheduling, the shared mailbox filed against jobs, and in-house AI assistants that answer from the firm's own documents.
- Client
- A Canberra building and pest inspection firm
- Location
- Canberra, ACT
- Firm
- Building and pest inspections
- Each booking
- Five teams and four outside parties
- Replaced
- A legacy booking system
The problem
The client is one of Canberra's established building and pest inspection firms. A booking arrives, an inspector attends, a report is written and proofed, the invoice goes out. Simple to describe. Hard to run at volume, because one job touches five teams and a dozen people outside the business.
The customers are rarely the people who pay. An agent books for a vendor, a conveyancer wants the report for a purchaser, and the owner has to be reached for access. Every job is a small coordination problem, and most of the parties have no idea what stage anything is at.
They were running it on a booking system that knew about appointments and almost nothing else. Access arrangements arrived by email and stayed in someone's inbox. Whether the owner had signed the deferred payment agreement was a question you answered by searching your sent items. The office knew who was rostered on, but not whether the property had been inspected before, nor how far the inspector had to drive between the 11 AM and the 2 PM.
So work was invisible, handovers leaked, and the knowledge lived in people. When the person who knew a particular agency's arrangement was away, the job stalled.
The result
What changed
The day is visible
What is blocked, who it is with and why sits on one screen, instead of being reconstructed from a mailbox each morning.
Handovers stop leaking
Six team lanes run in parallel on the same job, each with its own checklist, so the next team can see what has already been done rather than asking.
The rules live in the software
Actions that are not ready are greyed out with the reason showing, so a new coordinator does not need to have memorised the process.
The office changes its own settings
Packages, prices, message templates, job types and journey steps are edited in the portal by staff, not by a developer.
No per-seat cost to grow
They own the source code outright, so adding an inspector or a coordinator costs nothing in licensing.
How it works
What we built
01
A job that carries its own process
A job here is not a status. It is six parallel lanes, one per team: Booking, Prepping, Inspecting, Proofing, Enquiries and Accounts, each with its own checklist, assignee and progress.
That came out of how the firm actually works. Prepping can be finishing title checks while Booking is still chasing a signature. A single linear status could never say that, so the office kept the truth in their heads.
Steps tick off two ways. A person ticks some. The system ticks others when the thing genuinely happened: the confirmation went, the inspection hit the calendar, the signed agreement came back. Those are marked "Auto" with a timestamp, so nobody has to trust a checkbox someone ticked out of optimism.
Beside the checklist sits every action available on this job: send the owner confirmation, reschedule, cancel, lock in confirmations. The ones that are not ready are greyed out with the reason showing. The staff member does not have to know the rules, because the page tells them.
The job page also surfaces what people used to learn the hard way. Inspected before? A banner says so and links to the history. Different inspector on the day? Called out in the header.
Six team lanes run in parallel on one job. Steps tick off by hand or automatically when the event really happened, and every available action is listed with its blockers shown. 02
Scheduling built for a driving day
Inspectors do not work a calendar, they work a route. So the day is one row per inspector, each job carrying its difficulty rating, whether keys are involved, whether the agent will be on site, whether it needs two people.
Between consecutive jobs sits the driving distance and time, peak-hour aware, with a running total. A booker dragging a job into an afternoon slot sees immediately that it adds 28 kilometres to somebody's day. Leave is drawn onto the same view, so an inspector who is away is struck through rather than quietly missing.
One row per inspector. Each job carries its difficulty rating and its access flags, and the gaps show the driving distance and time to the next job. 03
The mailbox, attached to the work
The shared mailbox is where the coordination actually happens, so the portal brought it inside. Mail syncs into a triage queue, and filing a message against a job attaches it to that job's history. The next person to open the job finds the access instructions without going looking.
Contacts follow the same logic. Agencies, agents, owners and conveyancers are separate registers with real relationships, not one flat list. An agency has teams. A property has an ownership history. A job links the owner, the agent and the conveyancer, so the right confirmation reaches the right person without anyone deciding who that is each time.
Client mail syncs into a triage queue. Filing a message against a job attaches it to that job's history for whoever picks it up next. 04
Configuration the office owns
The parts of the business that change are configuration, not code. Packages, prices, message templates, job types, the step definitions for each lane, the public holidays: staff edit all of it. When a price changes or an email needs rewording, nobody waits for a developer.
The process itself is configuration. Job types, journey steps and team assignments are edited here, not in code. 05
Assistants that cite their sources
Inspectors carry a set of in-house assistants covering compliance, report comments, termite risk and energy ratings. Each answers from the firm's own document library and cites what it drew on, with an authority hierarchy behind it so a current standard outranks an older internal note.
The value is not the novelty. It is that a junior inspector in a roof cavity gets the answer the senior inspector would have given, with the source attached, instead of a phone call that may not be answered.
Four assistants answer from the firm's own document library, with the source documents cited on every answer.
Two decisions worth stealing
The step engine is data, not code
Steps, exclusions, team assignments and trigger conditions are all records, which is the only reason the office can edit its own process without us.
One database, not two
The knowledge base runs on pgvector inside the same PostgreSQL database rather than a separate vector service. For a business this size, one less moving part to operate is worth more than the performance headroom.
See it
Every screen
Open a section to browse it. Click any screenshot to enlarge.
These screens come from a demo account. The business name, the staff and every client, agent and conveyancer in them are invented, so no real party appears.
Watch it work
More walkthroughs
No slides and no mock-ups. These are recordings of the running software.
What it is built on
- Rails 8
- Application server, PostgreSQL, Solid Queue and Solid Cache
- React 19 and Inertia.js
- Typed frontend with server-side rendering
- Tailwind CSS and shadcn/ui
- Interface system
- pgvector
- Knowledge-base retrieval inside the same database
- Google Maps Platform
- Peak-hour aware travel times between consecutive inspections
- Microsoft 365
- Shared mailbox sync and calendar invitations
- Coolify and Docker
- Deployment
