Month seven of a twelve-month defects liability period on a forty-unit building. The owner of 1204 emails the office: the ensuite mixer drips, and while she has your attention, the balcony door seal has lifted in the corner. The plumber who fitted that mixer finished up in March and is on a job in Geelong. The site manager who would have known which plumber is running a different build. The email lands with whoever checks the info@ inbox, who forwards it to a director, who forwards it to the site manager, who replies "I think that was Dave" from a car park.
That is what a DLP looks like at most builders. Not neglect. A twelve-month job with no job number.
The DLP is a job. Run it like one
Here is the opinion. The defects liability period fails because the project team treats practical completion as the finish line, demobs, and hands a spreadsheet to someone in the office. Then for a year the building keeps producing defects into a process that has nobody on it, no due dates, and no way of proving what was done.
A DLP has all the parts of a job. Defects that arrive one at a time over twelve months. Trades who have to attend, some of whom have moved on and some of whom would rather not come back. Owners who are now the client, in the building, with a phone. A final inspection at month eleven. And money on the table at the end of it, because that is when the retention conversation happens.
So give it a register of its own, an owner, and a due date on every item. The same defect record you ran the build on. Not a fresh spreadsheet.
Keep the DLP items out of your build numbers
One thing that gets missed. The DLP register and the build register are the same list at different points in time, and it matters that you can tell them apart. A mixer that starts dripping in month seven is not the same kind of record as the paint run you caught at PCI, and if they count the same your defect-rate numbers lie about the build.
The record carries a Type field for exactly this. Warranty, not Defect, for the things that fail inside the period. Filter on it and you have the DLP register without running two systems. Filter it out and you have the honest build numbers to show the next client.
The trade who has left
The plumber in Geelong is the actual problem, and the process has to be built for him, not for the trades who are still on site.
He is not installing anything. He is not remembering a password for a building he finished in March. What he will do is tap a link in an email from his ute, look at a photo of the mixer, attend, take a photo of the fix, and mark it done. That is the whole interaction, and it works because the assignment email carries a link that opens the work directly, no account needed. He cannot mark it done without a photo. He cannot close it, either. That is your call, after you have looked at the photo.
If he does not come back at all, you send someone else and the record should say so. The defect carries two contractor links: who is doing the work and who is wearing the cost. Trade B fixes the mixer, Trade A is the cost-to contractor, cost category backcharge, and the accounts line writes itself. Without that split the backcharge is an argument in month thirteen with no paperwork behind it.
Nobody chases a spreadsheet
The reason DLP items sit for six weeks is that nothing reminds anyone. The build had a site manager walking past the problem every day. The DLP has an email thread.
Put a due date on every item when it comes in and let an overdue rule do the nagging: overdue by 48 hours, notify the trade and the person running the DLP; overdue by a week, escalate to a director. Immediate for the ones that matter, a Monday morning digest for the rest. The rule fires whether or not anyone remembers the building exists that week.
The honest line: IssuesId does not schedule your month-eleven DLP inspection. There is no calendar in it that says "final walk due". You put that in your own diary. What it does is make sure that when you walk in for it, the register is current, every item has a photo and a status, and nothing is sitting in someone's inbox.
The owner is the client now
The owners are in the building every day. They will find the defects before you do, which is fine, as long as they can report them somewhere other than a group chat with the other owners.
Hand them a QR card at settlement. They scan it, photograph the drip, and the item lands in your register attributed to unit 1204 with the time on it. They see their own items move, with the cost figures and the contractor's name stripped out, because how much it cost you to fix is not their business. They cannot change a status. Nothing goes live from a lobby scan without you approving the person first.
That single move turns the DLP from "the owners are unhappy" into a list you can work.
Month eleven
The final DLP inspection is a filtered view of the register, same as handover was. If you have run it properly the walk is short: every item logged since PC, when it was reported, who attended, the before-and-after photo, who verified it closed. Print that as the report and the retention release is a formality rather than a negotiation.
Run it from the info@ inbox and month eleven is a director walking forty units with an owner's committee, discovering the list for the first time.
The DLP is on the construction defect management page as the last step of the workflow. It is the step most builders do not build for. Do.