An RFI (request for information) in construction is a formal written question raised during a project to clarify drawings, specifications, or site conditions before the work proceeds. It exists because no set of contract documents is ever complete: details conflict, specifications leave gaps, and the ground rarely matches the survey. When a builder hits one of those gaps, the RFI is the mechanism that gets a binding written answer from the party with the authority to give one, and creates a record of the question, the answer, and the dates on both. This guide covers what an RFI is and is not, how the process actually runs, what separates a good RFI from a bad one, and how to manage the flow so it protects the project instead of stalling it.
An RFI is a question, not a submittal and not a change order
The three document types get confused because they travel the same routes between the same parties, but they do different jobs. Keeping them straight matters, because each one carries different contractual weight.
An RFI asks. It says: the documents are unclear, incomplete, or contradictory on this point, and we need a decision before we can build it. The answer becomes part of the project record and often becomes a contract interpretation, which is exactly why it must be written down rather than settled in a corridor conversation.
A submittal proposes. Shop drawings, product data, and samples are the contractor showing the design team what it intends to install, so the design team can confirm the proposal meets the design intent. A submittal is not a question about a gap in the documents; it is evidence offered for review. The two often interact, because an RFI answer can change what a submittal needs to show, which is why linking them in one system is worth having.
A change order changes the deal. It adjusts the contract sum, the contract time, or both, and it needs agreement from the parties to the contract. An RFI never changes the contract by itself, but it is frequently the first domino: the answer reveals that the documents were wrong or the conditions differ, and a change order follows. A well kept RFI record is often the evidence that supports or defeats that change order months later.
The RFI process runs on a simple loop with several hands in it
The mechanics vary by contract form and by country, but the loop is recognizable everywhere. A question starts at the point of work and travels to the person with design authority, then the answer travels back down the same chain.
- The question is identified. Usually by a subcontractor's engineer, a site manager, or the general contractor's project engineer, at the moment the documents stop answering the question the work is asking.
- The subcontractor raises it to the general contractor. On most projects subcontractors do not send RFIs to the design team directly; the general contractor is the contractual channel. The GC reviews it, and this review step is not a formality: the GC checks whether the answer already exists in the documents, merges duplicates, and adds context the design team will need.
- The general contractor formalizes and forwards it. The RFI gets a number, a clear title, references to the relevant drawings and specification sections, a proposed solution where the contractor has one, and a response date. It then goes to the architect or the relevant engineer, sometimes via a contract administrator, depending on the contract.
- The design team answers, or routes it further. The architect may answer directly, or pass structural, mechanical, or electrical questions to the relevant consultant. Some answers need the owner's input, typically where cost or scope is touched.
- The answer travels back and gets actioned. The GC reviews the response, checks whether it has cost or schedule consequences, distributes it to everyone affected, and closes the RFI. If the answer changes the work, the change management process starts from here.
Two features of this loop deserve attention. First, every handoff is a place where the RFI can sit idle, which is why knowing who currently holds each RFI, often called ball-in-court, is the single most useful piece of status information. Second, the loop is asymmetric: the person who needs the answer is usually standing next to the work, while the person who has the answer is in an office, so the cost of delay lands on the party least able to control it.
A good RFI makes the answer easy to give
The fastest way to a quick, usable answer is a question that can be answered without a site visit and without three clarifying emails. The RFIs that come back quickly share the same anatomy.
- One question per RFI. Bundled questions get partial answers, and a partially answered RFI is neither open nor closed. If there are four questions, raise four RFIs.
- A specific, searchable title. "Level 2 slab edge detail conflict" will be findable in a year; "Question about level 2" will not.
- Precise references. Drawing numbers with revisions, specification sections, grid lines, room numbers. The responder should be able to open exactly what you are looking at.
- The conflict stated plainly. What document A says, what document B says, and why the crew cannot proceed on either reading alone. Photos of the site condition help more than paragraphs.
- A proposed answer. The contractor usually knows the practical options. Proposing one turns the design team's task from composing an answer into approving or correcting one, which is faster, and it puts the contractor's preferred solution on the table first.
- A response date and the consequence of missing it. Not as a threat, as information: "answer needed by the 14th or the pour moves" lets the responder judge urgency honestly.
Response time is where RFIs earn or burn money
An unanswered RFI is rarely idle. Behind many of them sits a crew that has been resequenced, a procurement decision on hold, or a fabrication order waiting to be released. The direct cost of the delay is only part of it: work done at risk before the answer arrives may need redoing, and work resequenced around the gap disrupts the trades that were not waiting for anything. None of this needs invented statistics to be believed; anyone who has run a site knows the pattern, and anyone who has sat through a claims review knows that slow RFI responses feature in a large share of delay narratives.
The practical countermeasures are unglamorous. Set a default response period and put it on every RFI. Flag the small number of RFIs that are genuinely schedule-critical, and say why, so the design team can triage honestly instead of treating everything as urgent. Review open RFIs at the weekly project meeting by age and by who holds them, not just by count. And answer the design team's own complaint fairly: a good portion of slow responses are caused by bad questions, which is what the previous section is for.
Most RFI problems are process problems, not people problems
The failure modes repeat from project to project, and almost all of them are structural.
Vague questions force the responder to guess or to ask for clarification, doubling the round trips. Missing context, no drawing references, no photos, no location, turns a five minute answer into a research task. No response date means the RFI has no urgency signal and sinks to the bottom of someone's inbox. Email as the system of record is the biggest one: the question lives in one thread, the answer in another, the attachment in a third, and six months later nobody can prove what was asked, what was answered, or when. Nobody owns the log, so open items age silently until one of them stops a pour. RFIs used as a weapon, raised in volume to paper the record for a claim, poison the process for the questions that are real; the defense against that is the same discipline, applied visibly, that makes the honest process work.
The RFI log is the minimum viable system
Whatever tools a project uses, there must be a single list of every RFI with its number, title, who raised it, who holds it now, when it was raised, when the answer is due, when it arrived, its status, and its cost or schedule impact. That list is what turns a pile of correspondence into a managed process: it is what the weekly meeting reviews, what surfaces the items that are quietly aging, and what a claims consultant will ask for first. A spreadsheet is enough to start; we publish a free RFI log template with the exact columns and the reasoning behind each one. The log's weakness is the same as any spreadsheet's: it is only as current as the last person who updated it, which is the honest argument for the next section.
Software changes the process by removing the manual bookkeeping
Dedicated RFI software does not change what an RFI is; it removes the gap between the correspondence and the record. Each RFI is raised from within the project it belongs to, carries its references and attachments with it, and updates the log automatically because the RFI and the log entry are the same record. Status, who holds the RFI, and time to deadline are visible without anyone compiling anything, and reminders fire on the due dates people would otherwise have to remember. The searchable history matters more than it sounds: the second time a question comes up, on this project or the next one, the previous answer is findable in seconds. And because subcontractors, clients, and consultants can work in the same system (in Archdesk, external collaborators are free), the handoffs that used to happen by email happen inside the record, where they are timestamped and visible.
Six criteria separate real RFI software from a shared inbox
When comparing tools, the feature lists blur together. These are the capabilities that determine whether the software will actually run the process.
- Status tracking with real visibility. Open, answered, closed, overdue, visible across the whole project at a glance, not buried in individual records.
- Accountability for who holds the RFI. Ball-in-court must be explicit. If the system cannot say who the project is waiting on, it cannot shorten the wait.
- Response deadlines with reminders. Due dates on every RFI, and automatic nudges when they approach or pass, so chasing is not a human job.
- Searchable history. Full text search across questions, answers, and references, on the current project and past ones.
- Submittal and document linkage. RFI answers frequently affect submittals and document revisions; the tool should relate these records so consequences do not get lost.
- Mobile access. Questions start in the field. If raising an RFI requires a laptop and a desk, the field will keep using text messages, and the record will be incomplete.
Weigh these against how the tool fits the rest of your delivery process: an RFI tool that shares records with your project, document, and cost management beats a better standalone tool that creates one more silo.
Frequently asked questions
What does RFI stand for in construction?
RFI stands for request for information. It is a formal written question raised during a construction project to clarify drawings, specifications, or site conditions, and the written answer becomes part of the project record.
Who is allowed to raise an RFI?
Anyone on the delivery side can identify the question, but the formal RFI usually travels along contractual lines: subcontractors raise RFIs to the general contractor, and the general contractor raises them to the architect, engineer, or contract administrator. The contract defines the exact channel.
How long should an RFI response take?
Many contracts set a default response period, commonly in the range of one to two weeks, and the RFI itself should always state the date an answer is needed. Genuinely schedule-critical RFIs should be flagged as such, with the reason, so responders can triage honestly.
What is the difference between an RFI and a change order?
An RFI is a question and its answer; it does not change the contract by itself. A change order changes the contract sum or the contract time and requires agreement between the contract parties. RFI answers often trigger change orders, and the RFI record is frequently the supporting evidence.
