The dispute lands months into the defect liability period. A buyer insists a defect was reported and never fixed — or that it was there at handover and the developer ignored it. To respond, the team goes looking for the record. And the record, on most projects, is a defect management system that is really just a spreadsheet: a master tracker someone has been updating by hand, sitting next to a folder of paper defect forms. Both are meant to prove what was reported, when, and what happened next. Neither actually can.
The question a developer should ask before the dispute arrives is simple. When a buyer challenges a defect, what can you actually prove?
Paper and Excel Are the Same Defect Management System
It is tempting to think the organised teams — the ones running a proper spreadsheet rather than a drawer of forms — have solved this. They have not. Paper and Excel are the same defect management system wearing different clothes. One is printed, one is digital, but both are manual, and both break in exactly the same places.
Consider what neither can hold. Neither records where a defect is — “crack in master bedroom” means one thing to the buyer and another to the contractor who arrives and finds three walls. Photos live somewhere else entirely: in an email, on a phone, in a WhatsApp thread, disconnected from the row in the sheet. Status is whatever a staff member last typed, with no history — a cell that read “pending” can be overwritten to “resolved” with no record of who changed it or when. The buyer has no visibility into any of it, so they chase by phone. The contractor is on a separate channel, so assignment happens by message. And the developer sits in the middle, manually stitching four disconnected sources into something resembling a record.
That is the real failure. Not that the data is missing — that it is scattered, editable, and unprovable.
A Defect Is Only as Good as Its Record
This is where iNeighbour replaces the spreadsheet with a system built to produce a record that holds. Buyers report defects in a few taps, attaching photos and videos, and pinpoint the exact location directly on the unit’s floor plan — so the contractor knows precisely where to look and the location is part of the record, not a description open to interpretation. Each report is filed against a Category → Type → Item taxonomy with fourteen built-in categories, so a defect is classified the same way every time rather than described differently by every buyer.
From there the ticket has a life the spreadsheet could never track. Several defects can be bundled into one ticket, each with its own status, aging counter, and due date. Contractors are registered and assigned to specific defects with their own deadlines. Submissions are approved or rejected on the record. If a repair is not accepted, a resubmission setting controls how the buyer reopens it — so a defect is not quietly closed while the buyer still considers it open. And eighteen automated email triggers keep the buyer, the developer, and the contractor informed at each step, so nobody is chasing status by phone.
The result is a full audit trail from submission to acknowledged rectification — every state change timestamped, attributed, and impossible to overwrite silently.
| Paper form or Excel tracker | Defect management system |
|---|---|
| “Crack in master bedroom” — open to interpretation | Pinpointed on the unit’s floor plan |
| Photos scattered across email and chat | Photos and videos attached to the ticket |
| Status is the last cell someone typed | Status with aging, due dates, and history |
| Buyer chases by phone; contractor on another channel | Automated emails keep all three informed |
| Cells overwritten with no record | Full audit trail, timestamped and attributed |
What This Changes When the Dispute Comes
The value of the record is invisible right up until it is challenged. When a buyer disputes a defect, the developer is not defending a staff member’s recollection or a spreadsheet cell that may have been edited. They are pointing to a ticket: reported on this date, pinpointed here, photographed, assigned to this contractor, rectified on this date, and acknowledged by the buyer. The dispute stops being an argument and becomes a matter of record.
That is also what the incoming JMB inherits — a documented defect history for the development, not a folder and a spreadsheet no one can vouch for.
A spreadsheet tells you what someone last typed about a defect. A defect management system tells you what was reported, where, by whom, who fixed it, and when the buyer accepted it.