Construction punch list: from logging to acceptance, so there are no disputes

On Wednesday evening someone writes in the group chat: "hey, did that crack by the column on the fourth ever get fixed". From there three people scroll back up, hunt for the photo, find a different photo of a different crack, and eventually someone says they think the painters were through there last week.

Handover is Thursday morning.

The expensive part of this story is not the crack. That is half a day of work with thirty euros of material. What is expensive is that nobody can show when it was spotted, who was told, and whether anyone accepted it after the repair. Without a record like that, the question gets settled a different way: by who has the better memory and the louder voice. Usually the owner of the site pays.

Why it turns into a dispute

A punch list rarely falls apart because people do not know what needs fixing. Everyone usually knows that much. The problem is in the record.

Most often what is missing is the author and the date. "I told him on site" is not a record, and two weeks later the two sides remember it differently, both in good faith. The due date is missing too, and a defect with no date by which it should be fixed is just a wish - there is nothing to measure lateness against.

Last, the photo is missing. Not just any photo, but the one taken on the phone at the moment the defect was found, before anyone touched anything. It shows the condition as it actually was, which is why it carries more weight than three pages of description. Without it, the conversation is one person's word against another's, and in that kind of fight the more stubborn person wins.

From here I will show what keeping a list like this looks like in Construction Team. The demo below runs through the whole life of one defect.

One defect, up close

Every defect is its own record with its own number, and the number builds itself from the project code: for a project coded LOZ the defects run DEFLOZ-001, DEFLOZ-002 and onward. It looks like a small thing, but on site it earns its keep. The number gets written in chalk right next to the crack, and later it takes seconds to find in the list.

Logging one requires just two things: the project and the title. Everything else gets filled in if it is known at the time, and there is a fair amount of it - sub-object, floor and axis as free text, an internal assignee, a subcontractor, a due date, category, priority. Keeping it to two required fields is a deliberate choice. A defect logged in passing while someone is walking the floor does more good than the defect that never gets logged at all because the form asked for twelve things and the walk-through had to keep moving.

Photos upload to the server after the record already exists. On a site with a weak connection, that is the difference between a walk-through that finishes and one that gets stuck on the third floor.

If the project has drawings uploaded, a defect can also be pinned directly on the sheet. Then the location is not described in words, it is shown, and the location text fills itself in.

Done does not mean accepted

There are five statuses: open, in progress, ready for review, closed, and rejected. Movement between them is not free. From "ready for review" there are only two ways out - accept it, or send it back for rework.

The reason is not a love of procedure. The contractor marks the defect as ready, and closing it stays with whoever is responsible for quality, with the system recording who accepted it and at what moment. Put both actions in the same hands and the defect gets closed by the person who fixed it, and the record no longer proves anything.

A defect is overdue when its due date has passed and it is still not closed or rejected. Once accepted, it stops counting as overdue even though the date itself stays the same. Every morning at seven a reminder goes out for due dates that are approaching or already past, and how many days ahead it looks is configurable.

The list for the subcontractor

Beyond the list on screen there is also an export for a specific contractor: a PDF with their defects under the current filters, complete with photos and the relevant drawing sheets. This snagging list is the document that goes to the tiling company, instead of forwarding them fourteen messages spread across four different days. Comments on the defects are deliberately left out of it, since they are internal back-and-forth, and the sheet goes outside the company.

There is also a field for the expected cost impact, meaning what the fix will cost. It is not required, but once it is filled in, the conversation about deducting it from the next act starts with a number.

How far it goes

There is no import from a file. Defects get logged straight into the system; export exists, to Excel, CSV or PDF, but the reverse direction does not. An old spreadsheet list gets moved over by hand, and if the project is near its end and one file holds four hundred rows, that is a day of work, and it is worth knowing that in advance.

The list does not replace the acceptance protocol. It is the working tool that leads to the protocol.

Nor does it decide who is at fault. It records who said what and when, that is all. How responsibility gets split stays a conversation between people, only now a conversation with dates.

When it pays off

Keeping a list like this pays off the moment logging a defect takes less time than the dispute it prevents. That is why two required fields and a number that builds itself do more work than a detailed form nobody fills in while it is raining and the phone is being held in one hand.

And the question from Wednesday evening gets its answer in thirty seconds: the date it was logged, a photo from that day, and the name of the person who accepted the repair.