The Construction RFI Process: A Practical Guide for GCs and PMs
Ask any superintendent what quietly eats a schedule and you'll hear the same thing: waiting on answers. A dimension that doesn't close, two drawings that disagree, a spec that calls for a product nobody stocks anymore. Each one is a small question, but left unanswered it can idle a crew, hold a material order, or force rework a month later. The Request for Information, or RFI, is the formal tool the industry uses to get those questions answered and to prove, on paper, who was asked what and when.
A good construction RFI process is not about paperwork for its own sake. It's about turning a field question into a documented answer fast enough that nobody has to guess. This guide walks through what an RFI actually is, when to write one, how to draft it so it comes back answered the first time, and how to keep the whole log from turning into a black hole.
What an RFI actually is (and isn't)
An RFI is a formal, written request from one party on a project to another asking for clarification, a decision, or missing information needed to keep work moving. Most often it flows from a general contractor or subcontractor up to the architect or engineer, but owners, suppliers, and specialty trades all send and receive them. The defining trait is that it's on the record: a numbered question with a documented response.
It helps to be clear about what an RFI is not. It is not a change order, though it sometimes surfaces one. It is not a substitution request or a submittal, though it can be confused with both. And it is not a substitute for reading the documents. The fastest way to lose credibility with a design team is to send RFIs for answers that are already spelled out in the drawings or specs. Reserve the RFI for genuine gaps, conflicts, and ambiguities.
- Clarification: two documents conflict, or a note is ambiguous.
- Missing information: a dimension, detail, or spec that simply isn't there.
- Field condition: existing conditions don't match the drawings.
- Design intent: the documents are technically complete but a decision is needed to build it.
When to write an RFI (and when not to)
The judgment call every PM makes is whether a question deserves a formal RFI or a quick phone call. The rule of thumb: if the answer will affect cost, schedule, safety, scope, or the permanent record, put it in writing. A verbal answer that changes how something gets built but never gets documented is a dispute waiting to happen.
Conversely, not every question needs a numbered RFI. Coordination questions between trades, obvious typos, and details you can resolve by reading one more sheet are better handled directly. Flooding the log with trivial RFIs slows down the real ones and trains the design team to skim. Write fewer, better RFIs and they get taken seriously.
Timing matters as much as judgment. Raise the question the moment you spot it, not the week the work is scheduled. RFIs written during shop drawing review or preconstruction cost nothing; the same question asked with a crew standing by costs real money.
Anatomy of a clear RFI
An RFI comes back answered the first time when the reviewer can understand it in under a minute without hunting for context. That means giving them everything they need in one place. A vague, one-line question forces a phone call or, worse, a non-answer that starts the clock over.
Every strong RFI carries a few core elements. Include the specifics below and you dramatically cut the back-and-forth.
- A unique RFI number and clear, specific subject line.
- The drawing sheet, detail, and spec section the question references.
- A plain statement of the question or conflict, one issue per RFI.
- Your proposed solution or interpretation, so the reviewer can simply confirm or redirect.
- The cost and schedule impact if the answer is delayed, with a needed-by date.
- Attachments: marked-up drawings, photos of the field condition, or product data.
- Distribution list so everyone who needs to see it does.
How the RFI process flows, step by step
The mechanics vary by contract, but a healthy process follows a predictable path. Knowing the sequence helps you spot where yours is getting stuck.
- 1. Identify the gap. The field or a trade partner flags a conflict, missing detail, or ambiguity.
- 2. Vet it internally. Confirm the answer isn't already in the documents and that the question is worth formalizing.
- 3. Draft and number the RFI. Write it clearly, attach markups, and propose a solution.
- 4. Submit through the agreed channel. Send it to the responsible party per the contract's routing.
- 5. Log and track. Record the submit date, assign an owner, and set the response due date.
- 6. Follow up before it's late. A short reminder a day or two ahead beats a scramble after.
- 7. Receive and review the answer. Check that it actually resolves the question and doesn't quietly change scope.
- 8. Distribute and act. Push the answer to the field and everyone affected, and file it against the drawings.
- 9. Flag any cost or schedule impact. If the response constitutes a change, start the change order or claim process immediately.
Why RFIs stall and how to keep them moving
The single biggest complaint about the RFI process isn't writing them, it's waiting on them. RFIs stall for a handful of predictable reasons, and most are preventable. Questions get sent to the wrong person. They're too vague to answer without a follow-up. There's no agreed turnaround time, so nothing feels urgent. Or the log lives in someone's inbox where no one can see what's overdue.
The fixes are equally practical. Agree on a response window in the preconstruction meeting and hold to it. Route every RFI to a named individual, not a general inbox. Keep the log visible to the whole team so accountability is shared rather than hidden. And track the age of every open item, because a stack of RFIs sitting past their due date is a schedule risk you can measure before it becomes rework.
This is where tracking software earns its keep. A tool like MyBuildTracks keeps every RFI numbered, assigned, and time-stamped, shows which ones are aging, and gives subcontractors and clients a free portal to submit and follow their own questions, so nothing lives in a single person's email.
RFIs as your project record
Long after the crews are gone, the RFI log is one of the cleanest records of what happened on a job. It documents what was unclear, who asked, who answered, when, and what the answer changed. If a dispute arises over cost, delay, or defective work, that trail is often the deciding evidence.
Treat every RFI as a permanent record from the day you write it. Keep responses attached to the questions, mark up the drawings with the resolved answers so the field builds to the latest information, and close items out formally rather than letting them fade. A disciplined log protects you in a claim, but more often it simply prevents the confusion that leads to claims in the first place.
Key takeaways
- An RFI is a formal, numbered question-and-answer used to resolve gaps, conflicts, and ambiguities in the contract documents, not a workaround for reading them.
- Write an RFI whenever the answer affects cost, schedule, safety, scope, or the permanent record; handle trivial questions directly to keep the log credible.
- Clear RFIs reference the exact sheet and spec, ask one question, propose a solution, state the impact, and include a needed-by date.
- Most RFIs stall for preventable reasons: wrong recipient, vague wording, no agreed turnaround, or an invisible log.
- The RFI log is a core project record; keep answers attached, mark up drawings, and close items formally to protect against disputes.