If you've been a superintendent or PM long enough, you've felt this: it's 9 a.m., the ironworkers are waiting on a clarification for a beam connection detail, and the RFI you submitted yesterday afternoon is still sitting in someone's inbox. By the time you get an answer, half a day is burned. The pour schedule slips. The concrete truck gets rescheduled. The ripple runs two weeks.
The 48-hour RFI response window is treated as normal in commercial construction. It shouldn't be.
Where the Hours Actually Go
The mechanics of a slow RFI aren't mysterious once you map them. Consider a ground-up office build in the Austin metro — a 6-story mixed-use project with 14 active subcontractors. The super identifies a conflict between the structural drawings and the MEP coordination drawings at a mechanical penthouse penetration. He needs an answer before his HVAC crew can set a 48-inch duct run.
Here's where time disappears in the paper-and-email workflow:
- Step 1 — Discovery to documentation: Super finds the conflict at 10:30 a.m. He finishes his rounds, gets back to the trailer at 1 p.m., and drafts the RFI. Another 40 minutes to attach the relevant drawing sheets from the binder set. Submitted by 2 p.m. — 3.5 hours after discovery.
- Step 2 — Inbox to acknowledgment: The PM gets the email around 3 p.m. but is in a progress meeting until 4:30 p.m. She logs it, creates a tracking number, and sends the RFI to the EOR (engineer of record) by 5 p.m. — 3 hours after submission.
- Step 3 — Engineer review: The EOR has a standard 48-hour SLA. Their office closes at 6 p.m. The RFI hits their queue the next morning. Response comes back the following afternoon. — 18–20 hours.
- Step 4 — Response distribution: PM gets the answer at 2 p.m. on day two. She replies to the super's email. The super is on the roof. He checks email that evening. — 4–6 more hours to close the loop.
Total elapsed: 28–32 hours, just for a clarification that took the engineer 20 minutes to answer. And that's a fast cycle. When the EOR needs to loop in the owner's rep, or when the RFI requires an Architect's Supplemental Instruction (ASI), the timeline pushes past 72 hours without anyone doing anything wrong.
The Actual Bottleneck Is the Handoff, Not the Review
It's worth being precise here: we're not saying the engineer is slow, or that the PM is dropping the ball. The review time itself is usually reasonable. What kills the schedule is the dead time between handoffs — the gap between when information exists and when it moves. That gap is entirely a workflow design problem, not a people problem.
The paper-and-email RFI process has at least four handoffs, each with a variable delay. Each handoff relies on someone checking something — an inbox, a voicemail, a binder — that has no active push notification tied to schedule urgency. An RFI affecting a pour scheduled for tomorrow morning looks identical in an inbox to an RFI about a minor spec clarification on a distant activity.
What a 4-Hour RFI Cycle Looks Like
Four hours is achievable for many RFI types, not as an aspirational number but as a practical outcome when the handoffs are tightened. The same project scenario above, run through a mobile-first real-time workflow:
- Discovery to submission: The super is standing at the penetration conflict. He opens the RFI form on his phone, photos the plan versus field condition side by side, adds a voice note, and submits in under 8 minutes. Elapsed: 8 minutes.
- Submission to PM notification: The PM receives a push notification with the RFI flagged by the super as schedule-impacting. She reviews the attached photos on her tablet in the trailer and routes to the EOR immediately. Elapsed: another 12 minutes.
- EOR notification and response: The EOR is also on the platform and receives the RFI with full context — photos, affected drawing callouts, activity schedule. For a straightforward mechanical penetration question, the EOR resolves with a sketch markup and written response in under 90 minutes. Elapsed: ~2 hours from submission.
- Response loop-back: The super gets a push notification. He's still on-site. He reads the response, confirms receipt, and briefs the HVAC foreman. Elapsed: another 15 minutes.
Total: approximately 2.5 to 4 hours, depending on EOR availability. The HVAC crew proceeds the same afternoon.
Where This Argument Has Limits
It would be dishonest to suggest that every RFI can be answered in 4 hours. Anything requiring owner approval, design changes, structural re-evaluation, or coordination across multiple design disciplines will take longer — and should. An RFI that asks a structural engineer to re-evaluate a connection detail based on a changed load condition needs careful review. Rushing that is worse than the schedule slip.
What faster workflow design can address is the time wasted in transit — the hours that the RFI sits in an inbox or waits to be routed. The review time is owned by the design team; the transit time is owned by the field-to-office communication process. These are separate problems. Fixing the workflow doesn't put pressure on engineering rigor — it just eliminates the dead time around it.
The Schedule Math
On a commercial project with 25–40 active subcontractors, you'll typically see between 8 and 20 RFIs per week during peak structural and MEP coordination phases. If half of those affect near-term schedule activities, and each one carries an average 24-hour delay beyond what's necessary, that's 4–10 schedule days per month of recoverable time. Not all of it converts to schedule compression — some activities are float-buffered — but on a project running near critical path, even 2–3 days per month of recovered RFI time is meaningful. On a 14-month project, that could be the difference between substantial completion and a late delivery penalty.
Making the Shift Practical for Field Crews
The failure mode of most construction tech rollouts isn't the software — it's the adoption curve. Asking a foreman who has been running projects for 20 years to change how he submits RFIs requires the new method to be faster and simpler than the existing one, not just philosophically better.
The design constraint that matters most: photo-first, text-second. A superintendent can take a photo of a drawing conflict and annotate it faster than he can describe it in a written RFI form. Any mobile RFI tool that leads with a text field and buries photo attachment is going to lose to the email habit. The right model mirrors how field crews already document issues — photo, short annotation, submit. The PM's job then becomes routing and tracking, not transcribing field descriptions.
The other constraint is connectivity. Remote sites, parking structures, and high-rise upper floors all have spotty coverage. A mobile RFI tool that fails to queue and sync when signal is restored creates distrust quickly. Offline-first behavior, where the submission is stored locally and pushed when connectivity returns, is a table-stakes requirement for actual field adoption.
What Changes When RFIs Flow Faster
Beyond the schedule recovery math, there's a less-talked-about benefit: the quality of the RFI itself improves. When submission is fast and photo-native, field crews submit more context — the actual field condition, not just a reference number. The EOR gets better information and can respond with more precision. Fewer back-and-forths. Fewer clarification requests on top of the clarification request.
And the complete log — timestamp, submitter, attached photo, response, linked schedule activity — becomes a clean audit trail that survives project closeout. When the owner's attorney wants to understand why the penthouse ductwork was modified, that record is retrievable in seconds, not dug out of an email archive.
Forty-eight hours isn't a natural law. It's the product of a workflow design that hasn't been updated since the fax machine. The path to four hours runs through the handoffs, not through pressuring your engineers to work faster.