An RFI is what happens when the drawings and the real world stop agreeing. A framer finds a beam sitting where a duct main is supposed to run. The plumber discovers the architectural and plumbing sheets show the floor drain in two different places. Somebody has to ask the question, somebody has to answer it, and until they do, that piece of work is frozen. The whole point of good RFI handling is to shrink the gap between "we found a problem" and "we have an answer we can build to."
For decades that gap was measured in days for a reason that had nothing to do with how hard the question was. A foreman would spot the conflict, mention it at lunch, tell the super that afternoon, the super would write it up the next morning, the PM would forward it to the design team, and the clock the contract actually cares about — the review clock — wouldn't even start ticking until it landed in the architect's inbox two or three days after the problem was discovered. That lag is pure waste, and it's the part field management software is genuinely good at killing.
Why field-originated RFIs are the ones that hurt
Plenty of RFIs come out of the office during preconstruction or drawing review. Those are usually the cheap ones — nobody's standing around with a nail gun waiting on the answer. The expensive RFIs are the ones born in the field, mid-installation, when a crew hits a condition the drawings didn't anticipate. Those questions come with a crew attached, and every day of turnaround is a day that crew either stands down or, worse, keeps building past the conflict and creates rework.
The single biggest improvement you can make is closing the discovery-to-submission gap. If your foreman can open a question on his phone the moment he finds the conflict — photograph it, drop in the sheet number, and route it — you've just recovered the two or three days that used to evaporate between discovery and paperwork. The formal review window is usually fixed by contract (commonly seven to fourteen calendar days), and you can't change that. But the self-inflicted delay before the RFI ever reaches the reviewer is entirely yours to eliminate.
Write the question so it can be answered in one pass
The slowest RFIs aren't slow because the design team is lazy. They're slow because the question was bad, and the answer comes back as another question. A vague RFI ("please clarify the wall at grid C") buys you a full review cycle for nothing, because the architect writes back asking which wall, on what level, referencing what detail.
A good field RFI does three things every time:
- Pins the location precisely. Grid lines, level, room number, sheet and detail callout. "North wall, Level 3, grid C-4, detail 5/A-501" gives the reviewer everything they need to open one sheet and look at one spot.
- States the actual conflict, not just confusion. "Structural S-201 shows the beam bottom at 9'-2"; mechanical M-301 routes the 20" main through that same elevation. They can't both be right." That's answerable. "The mechanical doesn't work here" is not.
- Proposes a solution when you have one. This is the move that separates a foreman who's been around from one who hasn't. If you offer "recommend dropping the main 14" and furring the ceiling in this bay," you often get a one-word approval instead of a redesign. You've done the reviewer's thinking for them, and you've protected your own preferred outcome.
Photos are not optional on a field RFI, and one good photo beats three paragraphs of description. Shoot the conflict wide enough to show context, then tight enough to show the specific interference. Mark it up — an arrow and a dimension on the photo tells the design team more in two seconds than a page of text. This is exactly where mobile capture earns its keep: the man who found the problem is standing in front of it with a camera in his pocket, which is the only time the perfect photo is easy to get.
Run an internal gate before it leaves the site
Here's a discipline that saves more RFIs than any software feature: the superintendent reviews every field RFI before it goes out. Not to slow it down — to catch the three-quarters of them that never needed to be RFIs at all.
A surprising number of field "questions" are answered by a detail the crew didn't find, a spec section nobody read, or a coordination drawing that already resolved the conflict. Every one of those you submit anyway costs you credibility with the design team and clutters your own log. The super's thirty-second read — "did you check detail 5, and is this really a design question or a means-and-methods issue we should just solve?" — is the highest-leverage filter on the whole process. When that internal gate lives inside the same tool the field uses to submit, it's a quick approve-or-kick-back instead of another email chain.
An open RFI is a schedule constraint — treat it like one
This is where RFI handling and look-ahead scheduling stop being separate topics. An outstanding RFI on next week's work isn't a paperwork item; it's a constraint that will stop a crew cold if it isn't answered in time. The trades that get burned worst are the ones downstream of the question — the drywall crew that shows up ready to close a wall that's still waiting on an electrical routing answer.
The practical move is to pull open RFIs into your weekly work planning and read them against the look-ahead. If a task is scheduled to start Tuesday and it depends on an RFI that's been sitting five days with a fourteen-day review window, that task is not ready — full stop. Flag it, sequence something else into that slot, and escalate the RFI. In the Last Planner world this is exactly what "make work ready" means: you screen the next few weeks of activities for constraints and knock them down before the crew is standing there. An unanswered RFI is one of the most common constraints on that list, right next to missing material and incomplete predecessor work.
This is the honest place where a tool like LookAheadWall fits the RFI conversation. It doesn't replace your RFI log or your document control system, but when your weekly work plan can show which upcoming activities are blocked by open questions, the RFI stops being an office document and becomes a visible reason a task is or isn't ready to build. That linkage — pending question tied to the specific week and location of the work it blocks — is what keeps a slow answer from turning into a surprise standdown.
Track turnaround, and make overdue impossible to ignore
You should be able to answer three questions about your RFI log at any moment: how many are open, how old is the oldest, and which open ones sit on scheduled work. If you can't, RFIs are managing you.
Log the ball-in-court status honestly — an RFI waiting on the design team and one waiting on your own sub for more information are two different problems, and lumping them together hides where the delay actually lives. Watch your own turnaround as closely as theirs. Plenty of "slow architect" complaints turn out to be RFIs that sat three days in the GC's inbox before anyone forwarded them. Automated overdue flags help, but only if someone owns the follow-up. Software surfaces the aging RFI; a person still has to make the phone call.
Close the loop — the part everyone skips
Getting the answer back is only half the job. The response has to reach the crew that asked, it has to get built, and the fact that it was built has to be verifiable later. The classic failure is an RFI answered by email, read by the PM, and never actually communicated to the foreman who's now building it wrong from the original drawings.
Make it a habit that the answer distributes to the people in the field, not just the office, and that the resolution gets marked as implemented once the work reflects it. Attach the response to the original question so the whole thread lives in one place — the field condition photo, the question, the answer, and confirmation it was built. Two years later when a warranty claim or a dispute lands on that exact wall, that complete record is worth more than you'd guess. A closed RFI with a photo of the finished condition ends arguments before they start.
Read the patterns before they cost you again
A log full of RFIs isn't just a to-do list — it's a diagnostic. If a third of your questions cluster in one trade or one area, the drawings for that scope are weak, and you can get ahead of the next round by flagging the coordination gaps proactively instead of discovering them one crew standdown at a time. Repeated structural-versus-mechanical clashes in the same zones usually mean the coordination drawings were never truly reconciled, and that's a conversation to have with the design team now rather than after the ceiling grid is up.
None of this requires a fancy platform to start. It requires shrinking the discovery-to-submission gap, writing questions that can be answered in one pass, treating every open RFI as a real constraint on real work, and closing the loop so the answer actually reaches the man with the tools in his hands. Field management software makes each of those faster and harder to drop — but the discipline is what carries the day. The tool just makes sure the question, the photo, and the answer all end up in the same place, tied to the week and the wall they belong to.