How to track field issues until they close: RFIs and punch lists

An open item is a promise with a date

A question nobody answered, a door that does not latch, a guardrail missing at a slab edge: on site these are all «things to fix», and they end up on the same whiteboard, in the same notebook or in the same email thread. That is where they get lost. Not because people are careless, but because a list that mixes everything cannot tell anyone what to do next.

An open item is really a small agreement: somebody owes somebody else a move, by a date, and everybody knows what «done» looks like. When any of those three parts is missing, the item is not being tracked. It is being remembered, and memory does not survive a change of project engineer or a three-week vacation.

Five kinds of open item, five different lives

The first discipline is to stop treating every issue the same way. Each kind has a different person who owes the answer, a different pace and a different proof of closure. Put them in one list with one set of statuses and the urgent ones wait behind the slow ones.

Names change by company and contract — «deficiency», «non-conformance», «field observation», «issue». What matters is that each kind keeps its own owner, pace and proof of closure.

Two of these can turn into the other. A coordination issue that cannot be solved by moving something becomes an RFI the moment it needs a design decision. And an observation found during punch is still a punch item if the fix is obvious, but becomes an NCR if someone has to decide whether to tear it out.

What a good RFI contains

An RFI is a formal question to the people who designed the building. It is not a chat message, not a complaint and not a negotiation. The design team answers dozens of them in parallel, so the ones that get answered first are the ones that can be answered without a phone call.

The same RFI, written badly and written well

Ball in court: who owes the next move

Every open item has exactly one party holding the ball at any moment. On an RFI it starts with the project engineer drafting it, passes to the architect when it is issued, may pass to the structural engineer inside the design team, comes back to the general contractor (GC) with the answer, and ends with the PE distributing it to the subs. On a punch item it goes from the superintendent to the trade, back to the superintendent or the PE to verify, and on to the owner's side for final acceptance.

• One party, and if possible one name. «The design team» is not a ball in court. «The architect of record, Dana Ortiz» is.
• The log keeps the history, not only the current holder. Who held the ball, from which date to which date. That history is what shows, months later, where the time went.
• Passing the ball is a recorded act. An RFI emailed to the architect is not «with the architect» until the log says it was issued, on what date and to whom.

Due dates and aging

Contracts usually define how long the design team has to respond to an RFI, and sometimes how long the contractor has to correct defective work. Read those clauses before the first RFI goes out; they set the due dates you can defend. When the contract is silent, agree on response times at the kickoff meeting and write them in the minutes.

Aging is simply how long an item has been open, and how long it has been with its current holder. Many teams group items in buckets — for example up to a week, one to two weeks, two to four weeks, and over a month — so the weekly review starts with the oldest. The buckets are the team's choice; what matters is that overdue items are visible without anyone having to go looking for them.

How to log a punch item so it can be closed

A punch item that only its author understands will bounce back and forth three times. The trade foreman reading it tomorrow morning, with no one to ask, has to be able to find it, fix it and know when it is done. Four things make that possible:

• Location down to the floor, zone and unit — and inside the unit. «Building A · Level 4 · Unit 4B · Bathroom · behind the door». Not «4th floor bathroom».
• A photo, with something marked on it. An arrow or a circle on the defect, and enough of the room in frame that someone can recognize where it is.
• The trade responsible. The company that installed it, not the one that is on the floor that day. If you are not sure, find out before you assign it; a misassigned item waits a week and comes back.
• A clear acceptance criterion. What the verifier will check. «Door latches without pushing and does not rub the frame», not «fix door». If the specification sets the criterion, point to it.

Write the item as a fact, not an opinion: what is wrong and where, not who is to blame. The punch list will be read by the trade, by the owner's representative and, sometimes, by someone else much later. Neutral wording ages well.

Whoever did the work does not sign it off

This is the rule that makes the whole system trustworthy. The trade marks an item ready when they believe it is fixed. Someone else — the superintendent, an assistant super, the project engineer, the owner's representative or the architect on the final walk — marks it verified, after looking at it in place.

It is not about distrust. The installer sees what they meant to do; a second person sees what is there. And a list where the same person fixes and closes each item tells the owner nothing about whether the unit is actually ready.

Statuses: a short life cycle, and void instead of delete

Each kind of item needs few statuses, and each status needs one clear meaning. If the team argues about whether something is «in progress» or «pending», there are too many.

An RFI marked «answered» is not closed. The answer still has to reach the foreman who is building it, and the drawings the field uses have to show it. Closing an RFI means the answer left the office.

Void, never delete. A deleted item leaves a gap in the numbering and a question nobody can answer: what was RFI-031? A voided item keeps its number, its dates and a one-line reason («duplicate of RFI-029», «withdrawn — resolved in the coordination meeting of the 4th»). Numbers are never reused.

Transmittals: for the parties who are not in the system

Not everyone who needs an item will be in the same log: a small sub, an inspector, a utility, a consultant brought in for one question. For them the item travels in a transmittal — a numbered cover sheet that says what is being sent, to whom, on what date, for what purpose (for action, for review, for information) and by when a response is needed.

• The transmittal is the envelope, not a second log. The item stays in its one list; the transmittal records that it went out and when.
• Log the reply against the item, not in an email folder. If the answer arrives by phone, confirm it in writing and file the confirmation.
• Keep the copy that was sent, including the revision of each sheet attached.

The weekly review and a one-page report

A log that is only opened when someone asks goes stale in a month. The fix is a short weekly review with the people who hold the ball: the superintendent, the project engineer, the lead of each active trade and, for RFIs, someone from the design team or CA when possible.

• Overdue first, oldest at the top. Then what is due this week. New items last.
• For each item, three things: who has the ball, what the next move is, and the date. If the answer is «we're working on it», the item needs a new date, not a new discussion.
• Decide, don't solve. The meeting assigns and escalates. Technical fixes happen afterwards, between the people involved.

What comes out is one page for the project manager and the owner: open items by kind and by who holds the ball, the overdue list, the items that threaten the schedule, and the answered RFIs that are heading into the change process. If it does not fit on one page, the list has stopped being managed.

When an answer changes the scope: from RFI to change order

Many RFI answers only clarify: the detail meant what the builder thought it meant. Some add work, remove it or change it. When that happens, the RFI does not carry the cost. It triggers a separate process — often called a change event, potential change order or proposal request, depending on the company — which prices the change and, once agreed, becomes a change order.

• Link them both ways. The change record cites the RFI number, and the RFI notes the change record it opened. Anyone reading either one should find the other.
• Notice goes out on time. Contracts usually require written notice of a claimed change within a set period. The RFI answer is often the moment that clock starts, so flag cost as soon as you see it.
• Close the RFI anyway. The question is answered; the money has its own track. Leaving the RFI open «until the cost is settled» hides a technical item that is actually done.

This describes how the records connect, not what anyone is entitled to. What counts as a change, and the notice required, depend on the contract.

Keeping the record for when it matters

Most open items close quietly. A few end up in a dispute over cost or time, sometimes long after the project team has moved on. On that day, the log is the only witness that was there every day. It helps if it was kept with that day in mind:

• Dates on every status change, not only the current status.
• Who said what, in writing. Verbal direction on site gets confirmed by email or in the daily report the same day.
• Answers are added to, never edited. If an answer is revised, the revision is a new entry with its own date.
• Photos with their date and location, before and after.
• The documents as they were. Keep the sheet revision each RFI referenced; the current set will not show what the question was about.

Worked example 1: one RFI from question to closure

An illustrative example, not a real project. It follows the stair RFI from the table above through each change of hands.

Worked example 2: a punch walk of one apartment

An illustrative example. The superintendent walks Unit 4B (Building A, level 4) before the architect's walk. Each item is logged with a photo, the trade and what will be checked. Two weeks later, this is where the list stands.

Seven items, three owners of the next move, no item closed by the trade that fixed it. Item 4B-04 shows the most useful line on the list: a fix that was not accepted, and why.

When every item in the unit is verified or void, the unit is ready for the architect's or the owner's walk. Their walk produces its own list, logged the same way, and the same rule holds: the GC's team marks items ready, and the owner's side verifies them.

The most common mistakes

• One list for everything. Safety hazards wait behind paint touch-ups, and RFIs get closed by the superintendent because they looked like punch items.
• RFIs with three questions, or with no reference, no location and no proposal. They come back as questions instead of answers.
• «Answered» treated as «closed». The answer sits in the PE's inbox while the crew builds from the old detail.
• The installer closing their own item. The list says 100% complete; the owner's walk finds the same defects.
• Deleting instead of voiding. The numbering has gaps and nobody can explain them.
• A ball in court that says «team» or «TBD». Nobody moves it, because it is nobody's.
• Direction given on site and never written down. Everyone remembers it differently six months later.
• Leaving an RFI open until the cost is settled, or settling cost inside the RFI. Technical and commercial tracks get tangled, and both slow down.

Frequently asked questions