RFI tracking: closing the gap between field questions and engineering responses
RFIs that move through email and informal follow-up create field delays, missed cost impacts, and decisions made without the right answer. Here is where the workflow breaks and how to fix it.
An RFI is supposed to be a short loop: question asked, question answered, work proceeds. In practice, the loop stays open longer than it should—and the delay costs more than most RFI logs show.
The issue is not the volume of RFIs. It is how they move: through inboxes, verbal conversations, and spreadsheets that sit outside the systems tracking schedule, cost, and risk.
Where the RFI workflow loses control
The trigger is undocumented. A field crew hits an ambiguity—a drawing conflict, a missing dimension, an undocumented site condition. The supervisor texts the project manager. The PM emails the architect. The RFI starts as a conversation, not a record. If that conversation does not convert to a formal request, it does not appear in any log.
Response time is tracked but not enforced. Most RFI logs record submission date and expected response date. But when a deadline passes without a reply, the follow-up is a manual call or email. There is no automatic escalation. The project manager discovers the delay when the field crew is already waiting.
The response does not update the affected drawings or specifications. When an answer arrives, it is typically attached to the RFI record. The change it directs—dimensions to update, details to revise, scope to clarify—lives in the email thread, not in the current drawing set. A crew member working from an earlier version does not know the answer exists.
Cost and schedule impact is assessed separately, if at all. An RFI that affects scope, cost, or timeline should trigger a review for a change order. In practice, that connection is made by memory or not at all. Impacts accumulate invisibly until the project closes and reconciliation reveals what was missed.
A better workflow structure
Capture RFIs at the source. A short structured form—submittable from a phone—creates a record at the moment the question arises. The record includes the location, drawing reference, question, and who submitted it. The trigger is searchable, not conversational.
Route and escalate automatically. The submitted RFI routes to the responsible party with a response deadline. If the deadline passes without a logged response, an alert goes to the person who can escalate—not to the person who is waiting.
Connect the response to the affected documents. When the response is logged, the relevant drawing or specification is tagged. Teams working from current documents can see that the question was asked and answered.
Flag potential cost and schedule impact. An RFI that references a scope change, unforeseen condition, or delayed instruction can automatically route for a cost and schedule impact review—before work proceeds.
The right implementation depends on the systems already in use—Procore, Autodesk Construction Cloud, or a combination of project management and document control tools. The goal is not to replace those systems. It is to close the gaps where RFIs currently move through email and memory.
Related: change order tracking: closing the gap between field and accounting and which construction workflow to automate first.
If RFIs in your operation sit open longer than they should—and the cost of the delay does not make it into the project record—describe the current process to us. We will map where the loop is open.
Is one recurring workflow still held together by re-entry, email, or spreadsheets?
Map that workflow