Every job has a stack of unanswered questions sitting somewhere between the field and the architect's desk. On a bad project, that stack is the reason a crew stands around at 7 a.m. wondering why the wall they were supposed to frame has a dimension that doesn't close. RFIs are how those questions get asked and answered, and how well you run the RFI process has a direct line to whether your crews stay productive or spend the morning burning labor waiting on a drawing.
The paperwork side of RFIs has moved off the fax machine and into software, and that's a genuine improvement. But the tool only helps if you understand what actually goes wrong with RFIs on a jobsite. Let's walk through the real workflow, the failure points, and where a system that ties questions to your schedule earns its keep.
Why RFIs kill schedule (and it's rarely the architect's fault)
Ask a super why the job is behind and you'll hear "we're waiting on RFIs." Dig in and the real problem is almost never the design team's turnaround time alone. It's the invisible days on either end of that turnaround.
A field question gets noticed on Tuesday. The foreman mentions it at the huddle Wednesday. Someone writes it up Thursday. It sits in a PM's inbox until Monday because nobody flagged it urgent. The architect answers in five business days, which everyone agrees is reasonable. By the time the answer lands, two weeks are gone and the crew has been rerouted twice. The design team ate five days; your own process ate nine.
That's the number that matters and the one most teams never measure: the gap between when the field first knew there was a problem and when the RFI was actually logged. Good software shrinks that gap by letting the person who found the problem submit it on the spot, from the field, with a photo and a location, before the detail gets lost.
Submit from where the question lives
The best RFI is written by the person standing in front of the conflict, not translated third-hand through a PM who wasn't there. When your foreman can pull out a phone, snap the pipe that's running through the beam, mark the grid line, and send it, you get three things you almost never get otherwise:
- A photo that says what a paragraph can't. "Duct conflicts with structure at grid C-4" means nothing until someone sees the 14-inch trunk sitting exactly where the joist wants to be.
- A real location. Grid, floor, room number, sheet reference. Answers come back faster when the reviewer isn't guessing which of the fourteen similar conditions you mean.
- Speed while it's fresh. The question gets asked the hour it comes up, not at the end of a week when the crew has already improvised something you'll have to tear out.
Keep a short template so field-written RFIs still capture the essentials: the question, the specific location, the drawings involved, your proposed solution, and the date you actually need an answer to keep working. That last field is the one people leave blank and the one that matters most.
Always propose an answer
Here's a habit that separates crews who get fast RFI turnaround from crews who don't: never send a question without a proposed resolution. "Beam and duct conflict at C-4 — request permission to drop the duct 4 inches and run below the beam, maintaining 8'-2\" clear. See attached." That's a different animal than "Please advise."
When you propose a solution, you turn the architect's job from "design something" into "approve or redline," which is far faster and far more likely to come back the way you want it. It also puts your read on the problem in the record. If they don't like your fix, they'll tell you what they want instead, and you've still moved the ball. An RFI with no proposed answer is an invitation to a phone call that never gets returned.
Routing and the ball-in-court problem
The single most useful concept in RFI management is ball-in-court: at any moment, exactly one party owns the next action, and everyone can see who it is. Most RFI delays aren't caused by anyone refusing to answer. They're caused by an RFI sitting in a place where nobody thinks it's theirs.
A structural question routes to the architect, who forwards it to the structural engineer, who needs the mechanical engineer to confirm the duct can move. If that hand-off is invisible, everybody assumes someone else has it, and the thing rots for a week. When the routing is tracked and the current owner is named on a dashboard, that ambient stall goes away. You can look at any open RFI and know exactly whose desk it's on and how long it's been there.
Set escalation rules and use them. An RFI you marked schedule-critical that's been sitting untouched for three days should be lighting up somebody's screen, not waiting for you to remember to chase it. And chase it anyway — software flags the stall, but a phone call from a super who's been polite up to now still moves things faster than any automated reminder.
Tie every RFI to the schedule
This is where an RFI process and a look-ahead schedule have to talk to each other, and where most teams fall down. An open RFI isn't just a document sitting in a log. It's a constraint on a specific activity that's coming up in your three or four week window.
Run your look-ahead the right way and every activity in the near-term plan gets screened for constraints before it's committed: material on site, prior work complete, inspection passed, and — critically — no open RFI blocking it. When you build weekly work plans this way, an unanswered question stops being a surprise. It shows up as a red flag on the activity two weeks before the crew is scheduled to touch it, while you still have time to push for an answer or resequence around it.
That's the whole game with short-interval scheduling: surface the blocker early enough that it's a planning decision instead of a morning emergency. A tool like LookAheadWall is built around exactly that screening step — you're pulling activities into a weekly plan and checking each one for what would stop it, and an open RFI is one of the constraints you flag. The RFI log and the schedule shouldn't be two separate worlds; the question you asked on Tuesday should be visibly attached to the framing activity it's holding up.
A few practical rules of thumb:
- When you log an RFI, note which upcoming activity it affects and how many days of float that activity has. That tells you the real urgency.
- Give the design team a required-by date tied to your schedule, not a generic "ASAP." Reviewers triage by deadline. No deadline means no priority.
- If an answer will land too late, resequence now. It's almost always cheaper to move a crew to productive work elsewhere than to leave them parked waiting.
Getting the answer back to the field
An answered RFI that never reaches the guy holding the tools is worth nothing. This is the mirror image of the submission problem, and it's just as common. The PM gets the response, files it, means to mention it, and the foreman frames the wall the old way because nobody told him the dimension changed.
When a response is distributed, it has to hit everyone the answer touches — not just whoever submitted it. A change to a beam elevation affects the framer, the mechanical sub running duct under it, and the fire sprinkler crew. Push the answer to all of them, get an acknowledgment that they saw it, and make sure the response stays accessible next to the drawing it modifies. Six weeks later when someone asks "wait, why is this beam low here?" the answer should be one search away, not lost in an email thread.
The log is your claims file
Nobody enjoys thinking about claims, but the RFI log is often the difference between getting paid for a delay and eating it. If a design question genuinely held up work, the record needs to show it cleanly: when you asked, what you asked, when they answered, and what it did to your schedule.
This is why you document schedule impact on the RFI itself, in real time, while it's happening — not reconstructed from memory in a conference room nine months later. "RFI 214 open 11 days, held framing on floor 3, 4-day net schedule impact after resequencing" written the week it happened is evidence. The same sentence recalled during a dispute is an argument. A searchable, time-stamped log turns a pile of questions into a defensible history of who owed what and when.
What to actually watch on the dashboard
Once you've got the process running, a handful of numbers tell you whether it's healthy:
- Aging. How long open RFIs have been sitting, oldest first. Anything past your agreed turnaround needs a phone call today.
- Ball-in-court by party. If forty open RFIs are all on one engineer's desk, that's a bottleneck you escalate, not a mystery.
- Schedule-critical open count. The short list that can actually stop a crew this month. This is the one you read every morning.
- Your own log-to-submit lag. The internal delay from field discovery to formal submission. Bring this down and you'll shave more days off your average RFI cycle than any pressure on the design team ever will.
The habit that makes all of it work
Software gives you fast submission, clean routing, visible ball-in-court, and a log that holds up. But the discipline is human. Walk the near-term schedule every week and ask, for each activity coming up: is there any question that could stop this? Get those questions in the system early, propose answers, tie them to real dates, and chase the schedule-critical ones like your labor budget depends on it — because it does.
Do that, and RFIs stop being the thing you blame at the end of a slipping job and become just another constraint you clear before the crew ever shows up. The best superintendents I've worked with don't have fewer questions than anyone else. They just ask them two weeks earlier.