The RFI Problem Isn't the Answer. It's Everything Before It.
Burn this number into the wall of every PM's office: seventeen.
That's the average number of person-hours a single RFI cycle consumes when you count everything—the field super capturing the issue, the PE writing it up, the PM routing it, the design team interpreting, the response, the field communication, the file management. Seventeen hours per RFI. A study of 168 Australian and New Zealand projects put the average cost of processing RFIs at roughly $656,000 per project in Australia alone. Not the cost of the answer. The overhead of the process.
And that number assumes the RFI got written in the first place.
Most RFIs Don't Start as RFIs
They start as conversations.
A field issue surfaces during a coordination call. Someone flags a conflict in a Teams meeting. A superintendent mentions something during a site walk but never writes it down. A planning session surfaces three unclear details that should become RFIs—and one actually gets logged.
That gap at the front end is where the clock starts running before anyone knows it. Missed or poorly captured questions don't show up on aging reports. They show up two weeks later when the pour is scheduled, the crew is mobilizing, and somebody's pulling a Friday afternoon fire drill to get three people on the phone at once.
What a Late RFI Actually Costs
Two weeks out from a major concrete pour. An electrical sub has an RFI on conduit embed locations that's been open twelve days—sitting because the EOR is waiting on a separate structural response about a related detail. Nobody flagged it as a critical-path block because nobody was running an aging report.
The PM finds it Friday afternoon. Now it's calls to the structural engineer, the EOR, the GC's PX, and the electrical sub—trying to consolidate three conversations into a 48-hour answer that should have happened two weeks ago.
The pour goes a day late. That day flows through the schedule for the next six weeks. The framing crew that was supposed to start Monday gets bumped to Wednesday. The drywall sub is going to be annoyed in three weeks. All of it traces back to a single RFI nobody escalated.
The Process Problems That Compound It
The seventeen-hour figure isn't just a staffing problem. It's a system problem. A few things that consistently make it worse:
-
Bench depth. Projects where three or more people were managing RFIs averaged turnaround under five days. Projects with only two averaged over fourteen. The variable isn't design team skill or contract complexity—it's whether there's enough depth to absorb when one person is out. Two people per side is not enough. If your team is running RFIs through a single PM and a single PE, cycle time will slip every time one of them takes a Friday off.
-
No aging reports. The conversation about a 14-day RFI is different than the conversation about a 5-day RFI—and that conversation only happens if someone is looking. Run aging reports weekly at minimum. The PM should know exactly which RFIs are over five days, ten days, fourteen days, and which ones are sitting on the critical path.
-
Poorly written RFIs. RFIs that come in without a clear question, drawing reference, spec reference, and proposed answer bounce back and forth for days. Set the template. Train the field to use it. The PE who insists on writing prose RFIs is costing the project real hours every week.
-
Undefined routing. Every RFI category should have a default reviewer and a default escalation path. The PE shouldn't be guessing where to send a structural question.
-
Unenforced contracts. Many contracts specify RFI response timelines. Most teams don't enforce them. If your contract says ten business days and the design team is averaging eighteen, that conversation belongs at the OAC—not buried in a status report at month nine.
Delivery Method Matters Too
Design-build projects are more sensitive to RFI delay than design-bid-build or CM/GC—more late RFIs, more clustering at the back end, more compounding when one slip turns into two. If you're delivering DB and running the same RFI process you'd run on DBB, you'll feel it.
Timing patterns vary by sector as well. Education projects tend to resolve around 80% of RFIs by the midpoint of the schedule. Commercial often pushes half or more into the second half—which is exactly when the field has the least flexibility to absorb the delay.
Where Automation Actually Helps
Routing, aging, threshold notifications, reports that surface critical-path RFIs versus nuisance RFIs—automation handles all of that well. What it can't do is answer the design question. The bottleneck on most slow RFIs isn't visibility. It's the design team being slow. The tools surface the slowness. Someone still has to make the phone call.
But there's a different automation opportunity that most teams haven't touched—and it's further upstream.
Capturing RFIs Before They Get Lost
Since most RFIs start as conversations, the smarter intervention is at the point of capture, not the point of routing.
Most teams are already recording coordination calls, planning meetings, and OAC sessions in Teams, Zoom, or Google Meet. Those platforms generate transcripts. A transcript is structured data. And structured data is something AI can work with.
A practical first version of this workflow looks straightforward: record the meeting, export the transcript, run it through an AI extraction step that identifies potential RFIs, review the output, and log the ones that hold up. You're not automating the decision. You're automating the capture—which is the part that currently relies on someone remembering to do it after the meeting when they're already onto the next thing.
The AI isn't being asked to "find RFIs." It's being asked to identify signals: unanswered technical questions, conflicts between drawings or trades, statements like "we need clarification on this," missing dimensions or specs, assumptions being made in the field. A prompt like this handles the extraction:
Where the Output Goes
This is where most teams overcomplicate things on the first build. You don't need a perfect system on day one.
The simplest starting point is a spreadsheet—Excel, Google Sheets, or a SharePoint list with fields for trade, title, description, date, and status. The team reviews it and manually logs approved RFIs into Procore or whatever system they're using. It's not elegant, but it proves the value fast and costs almost nothing to set up.
From there, the natural next step is a direct integration. Most modern platforms support this through APIs or middleware like Power Automate, Make, or Zapier. The flow becomes: transcript → AI extraction → human review → draft RFI created in Procore. Not submitted. Drafted. The system creates the record with title, description, references, and trade. The PM reviews it and hits submit. That distinction matters.
A hybrid approach—AI outputs to a structured log, a second step pushes approved RFIs into Procore—gives you the best early balance of visibility, control, and audit trail without taking on too much integration risk upfront.
Keep the Human in the Loop
Don't automatically submit RFIs from transcripts. Use this as a drafting and capture tool.
The PM or PE should still review each RFI, clean up the language, confirm it's actually necessary, and decide how to route it. AI accelerates the front end. It doesn't replace the judgment call about whether something is worth sending at all—which, on a busy job, is half the work.
Why This Is Worth Building
The input already exists. Transcripts are already being generated on most jobs. The output is high value—RFIs written earlier, with better context, by someone who was in the room when the question came up. The workflow is repeatable across every coordination meeting on every project. The risk is low because a human is reviewing before anything gets submitted.
Eighty percent of RFIs answered within five business days is a reasonable target on most jobs. Getting there requires the right staffing, the right templates, and a design team being held to the contract. But it also requires capturing the right questions in the first place—and right now, most teams are leaving a significant number of them on the floor of a Teams call that nobody followed up on.
That's the fixable part.