What Is an RFI in Construction? A Plain-English Guide for Small Contractors

RFI stands for Request for Information. It's a formal written question sent during a construction project, usually from a contractor or subcontractor to a designer, architect, engineer, or owner, asking for clarification on something the drawings or specifications don't make clear enough to build from. An RFI is not a casual question texted to a foreman. It's a documented request that gets a documented answer, and that answer becomes part of the project record.

Construction drawings and specifications are detailed, but they're not perfect, and they can't anticipate every condition a crew finds once a wall is opened or a slab is excavated. Two sheets sometimes conflict with each other. A detail might be missing entirely for an unusual condition. A spec section might reference a product that's been discontinued. Rather than letting the crew on site guess and build based on their best interpretation, the RFI process routes the question to whoever actually has the authority to answer it, in writing, so the answer can't later be disputed or forgotten.

Guessing on an ambiguous detail is how rework happens. A crew picks a reasonable interpretation, builds it, and finds out two weeks later during a site visit that the architect meant something else. Now there's demolition, a schedule delay, and a conversation about who pays for the redo. If the question had been asked and answered in writing before the work started, none of that would have been in dispute. The RFI isn't bureaucracy for its own sake. It's the mechanism that moves the risk of an ambiguous answer off the person swinging the hammer and onto the person who's supposed to have the answer.

A vague question gets a vague answer, or no answer at all for a week while the architect tries to figure out what's actually being asked. A well-written RFI gives the person answering everything they need to respond quickly and correctly.

• A specific, unambiguous question, not a general description of a problem
• Reference to the exact drawing sheet, detail number, or spec section the question relates to
• A photo of the actual site condition, if the question comes from something found in the field rather than a drawing conflict
• The contractor's own suggested solution or interpretation, when there is one, so the person answering can simply confirm or correct it rather than starting from zero
• A date by which an answer is needed, tied to when the work is actually scheduled, not an arbitrary deadline
• A note on whether the question is likely to affect cost or schedule if the answer requires a change

On a typical project, a subcontractor or the general contractor's field staff identifies the question, the general contractor reviews and often forwards it (sometimes adding their own comment), and the architect or engineer of record provides the answer. On larger projects an owner's representative or construction manager may also be in that chain, reviewing RFIs for cost and schedule impact before or after the design answer comes back. Each of those handoffs is a place a question can stall if nobody's tracking it, which is the real argument for logging RFIs rather than just emailing them and hoping for a reply.

On a commercial project with a formal RFI process, each request gets a sequential number, a submission date, and a status, and the whole log is reviewed regularly so nothing sits unanswered for weeks without anyone noticing. The numbering matters less for its own sake and more because it creates a reference point: "per RFI 014" is a lot more specific in a later conversation, a change order, or a dispute than "that question we asked about the wall detail." Logging also makes the pattern visible. If the same designer is consistently slow to respond, or the same type of question keeps coming up, a log shows that; a scattered pile of emails doesn't.

Large commercial general contractors typically run RFIs through dedicated software built for exactly that workflow, with numbering, routing, and reporting built in. A small residential or light commercial contractor usually doesn't have that software, and for the volume of questions on a smaller project, standing up a formal numbered RFI system can feel like more process than the job needs. The risk isn't using a lighter-weight system. The risk is having no system at all, where questions get asked by text message, the answer comes back in a different text thread, and three months later nobody can reconstruct who actually approved what.

In ConstruDo, an RFI-style request is a task set up to carry the same information a formal RFI would: the task description is the question itself, written specifically enough to act on; it's assigned to whoever needs to answer it, the architect, the owner, or your own project lead who needs to go get the answer; a due date is set based on when the field actually needs the response; and a photo of the site condition or a reference to the relevant drawing gets attached directly to the task.

Because ConstruDo also supports task-based email communication, including emailing people who aren't ConstruDo users, the back-and-forth with an architect or engineer who's never going to log into the app happens as email tied to that specific task, rather than scattered across separate email threads disconnected from the project. The question, the attachments, and the eventual answer all stay in one place, attached to the task, rather than depending on someone remembering which thread the answer came back in.

Worth being direct about one thing: this is task management being used for an RFI-style purpose, not a dedicated RFI tool with sequential numbering and a formal submittal log. If your contract requires that level of formality, follow the contract. For a smaller contractor who just needs every open question tracked, assigned, and answered without losing it in a text thread, a task with a clear question, an owner, and a due date covers the same practical ground.

If your contract requires a formal RFI process, with specific numbering, submittal formats, or response timeframes written into the general conditions, follow that contract. Large commercial and public projects often require it, and an owner's representative or construction manager may be contractually required to track RFIs through a specific system. A lighter-weight, task-based approach is a reasonable substitute when nothing in your contract dictates otherwise, not a replacement for a documented contractual requirement.