Property developer Nextensa runs snagging, handover and aftercare through Letsbuild and Ziggu, so the building team and the homebuyer work from the same list of open points.
Handover breaks down at the point where the site team's defect list and the homebuyer's version of it stop being the same list. The site team records snags by trade, by status and by contractor. The homebuyer wants one thing: is my point fixed yet.
Between those two lists sits the customer advisor, retyping updates into email. Points get resolved and nobody tells the buyer. Points get missed and nobody notices until the buyer calls. Contractors return to the same apartment three times, because two of those visits were never recorded against the right point.
None of that is a construction problem. It is a bookkeeping problem with a construction deadline attached.
Snagging and aftercare describe two phases of one list, split by the moment the keys change hands.
Snagging is the pre-handover round: the site team or an inspector walks the unit, records every defect and unfinished item, and assigns each one. Aftercare is everything after the keys, including the hidden defects that only surface once somebody lives there and the guarantee period attached to them.
The work is the same. What changes is who finds the defect, and after handover that is the buyer.
Nextensa runs both phases through two connected systems: Letsbuild for the building team, Ziggu for the homebuyer, joined by the Letsbuild integration so that nobody retypes a status.
Before the keys change hands, the pre-handover inspection is recorded in Letsbuild. Every defect gets a category, a status and an owner. The building team works its own list the way it always has, by trade and by contractor, in the tool its site people already use.
The homebuyer never sees that list. What they see in Ziggu is the state of their own unit: a point is open, a point is being worked on, a point is done. Snags sync across on a daily basis, and someone on the developer's side decides per report whether the buyer gets to see it. That decision is deliberate. It keeps the site team's working notes out of the buyer's portal, and once a report is published, later updates on that report reach the buyer without anyone touching it again.
When a contractor marks a point resolved in Letsbuild, the change reaches the customer advisor in Ziggu without anyone chasing it. The advisor then asks the homebuyer to confirm the fix, with one click.
After handover the direction reverses. The buyer finds a hidden defect and reports it in Ziggu, against their own unit, with a photo and a location. The customer advisor reads it, decides whether it belongs with a contractor, and pushes it into Letsbuild. The same list carries on across the handover date instead of restarting as an email thread. For a developer delivering several hundred units at a time, that continuity is the whole point.
Every step in this workflow exists twice: once in the building team's tool, once in the homebuyer's portal. Setting the two columns next to each other is the fastest way to see where the integration does the work.
| Step | Building team, in Letsbuild | Homebuyer, in Ziggu |
|---|---|---|
| Pre-handover inspection | Defects recorded per unit, categorised and assigned | Their unit shows open points |
| Work under way | Contractor updates the status of the point | The point shows as being worked on |
| Point resolved | Status set to resolved | Advisor requests confirmation |
| Buyer responds | Point closes, or returns with the buyer's comment | Accept the fix, or ask for another look |
| After handover | Advisor escalates the report to a contractor | Buyer reports a new defect with photo and location |
Nothing in that table needs a meeting. The two columns move because the systems are joined, not because somebody copied a status across.
The approval request is what separates this workflow from a shared spreadsheet: a point is closed by the buyer, not by the person who fixed it.
Without that step, a resolved point is only resolved on the developer's side. The buyer walks into the apartment two weeks later, finds the same skirting board loose, and reports it again as a new complaint. The contractor has invoiced and moved to another site. Everyone starts over, and it is the buyer's confidence that takes the hit, not the schedule.
With it, the loop has an end. The buyer accepts, and the point closes with their agreement on record. Or the buyer does not accept, says what is still wrong, and the point stays open with the reason attached. Both outcomes are useful. The second one is more useful, because it arrives while the contractor is still on site.
Two things follow. The customer advisor stops being a status relay and starts handling the exceptions, which is the part of the job that needs a person. And the aftercare period starts from a list both sides agree on, instead of from two lists that quietly diverged on handover day. That is the shape of it for a property developer running several projects at once: one list, two audiences, one point of agreement per defect.
