Construction punch list: how to keep one so handover is not a dispute
Handover is set for Thursday. Wednesday evening someone asks in the group chat "hey, did that crack by the column on the fourth ever get sorted", and from there half an hour goes into working out who photographed it, when, and whether the subcontractor was ever told at all.
That is the expensive moment. Not the crack itself - that is half a day's work. What is expensive is that nobody can prove when it was spotted, who it was assigned to and whether it was accepted. In a dispute, the side with dates and photos wins. On a tie, the owner of the site pays.
What actually breaks
A punch list rarely fails because someone does not know what needs fixing. It fails in three places:
No author and no date. "I told him" is not a record. Two weeks later, the two sides remember it differently.
No due date. A defect without a due date is not a task, it is a wish. Nobody can say whether it is running late.
No evidence. The photo taken on site at the moment the defect is found is worth more than three pages of description. Without it, the dispute is one person's word against another's.
From here on I show what keeping such a list looks like in Construction Team. The demo below runs through the whole life of one defect and loops on its own.
Punch Lists
Field / Punch Lists
Open
2
In progress
1
Ready for review
1
Closed
2
Overdue
2
Every defect across your sites in one place: who owes what, by when, and which deadlines have already slipped. The red is not decoration - those are the two overdue items counted in the card above.
How it is kept
Every defect is a separate record with a number. The number builds itself from the project code - for a project with code LOZ the defects run DEFLOZ-001, DEFLOZ-002 and so on. That means the number can be written on the spot, in chalk on the wall itself, and found in the list later.
Only two things are required: the project and the title. Everything else - location, assignee, contractor, due date, category - gets filled in if it is known. A defect logged on the run with two fields is more useful than a defect that never got logged because there was no time for the full form.
Photos go up from the phone on the spot. They upload to the server after the record is created, which means you are not waiting on a signal to finish the walk-through.
There are five statuses and the moves between them are restricted. Open, In progress, Ready for review, Closed, Rejected. The system does not allow arbitrary movement: from "Ready for review" there are only two ways out - accept it, or return it for rework. That is not a restriction for its own sake, it is a way to stop a defect being closed that nobody ever looked at.
Overdue means the due date has passed and the item is still not closed or rejected. An accepted defect stops counting as overdue even though the date is the same. Every morning at seven a reminder goes out for due dates that are approaching or already past - how many days ahead it looks is a setting.
The three things that settle the dispute
If it comes down to what matters most, a list that is actually kept gives you three records that paper and chat do not.
Number and date logged. They show when the problem was spotted, not when someone got around to mentioning it.
A photo from the moment. Attached to the record, not sent into a chat and lost among four hundred other messages.
Who accepted it and when. The timeline keeps the person who created it, the moment it was declared ready, the moment of acceptance and the name of whoever accepted it. That is the record that speaks for you in a dispute, and exactly why acceptance is a separate action from the fix.
To that you add cost impact - a field where you record what the fix costs. It is not required, but when it is there, the conversation with the subcontractor about a deduction becomes a conversation about numbers instead of feelings.
What it does not do
No import from a file. Defects get logged in the system. Export exists - to Excel, CSV or PDF, for a protocol or to send on - but the other direction does not. An old list in a spreadsheet gets moved over by hand.
It does not replace the acceptance protocol. The list is the working tool that leads to the protocol, not the protocol itself.
It does not decide who is at fault. It records who said what and when. Responsibility stays a conversation between people, only now a conversation with dates.
In short
A punch list is kept well when logging an item takes less time than the argument it prevents. That is why two required fields, a number that builds itself and a photo from the phone do more work than a detailed form nobody fills in on site.
And at handover on Thursday morning, the answer to "did that crack ever get sorted" is one screen, not half an hour of digging.
Frequently asked questions
When do you log a defect and when do you just tell the tradesman?
If the fix depends on another person or another company, log it. Something said out loud has no date, no author and no way of being checked two weeks later. The small things sorted out on the spot in a minute are not worth the record.
Should the person who fixed the defect be the one to close it?
No. Fixing and accepting are two different actions, and that is exactly where the chain breaks. The contractor marks the item Ready for review, and closing stays with whoever answers for quality. The timeline records who accepted it.
Why keep it in a system instead of a group chat?
A chat has no status, no due date and no way of answering "which defects are still open on this entrance". Three months later, searching chat history costs more than keeping a list did.
What happens when the due date passes?
The defect turns red and joins the Overdue counter. On top of that, a reminder goes out every morning for due dates that are approaching or already past, but only for defects that are not closed.