An RFI is a schedule event, not a form
The cost of a request for information is almost never the time spent writing it. It is the time the answer takes to arrive and what the crew does in the meantime. A wall that cannot be closed, a rough-in that cannot be inspected, a fixture that cannot be ordered. When an RFI sits for three weeks, the project absorbs that as lost float, remobilization, or overtime later, and it rarely gets attributed back to the delay that caused it.
Treating the RFI log only as a compliance artifact can leave scheduling consequences out of view. Treating it as a live schedule input changes what you measure. The important numbers are days open, days past the contractual response period, and what activity is blocked behind each one.
Cut the delay between the question and the draft
Field questions rarely arrive as clean RFIs. They arrive as a photo with a caption, a phone call, or a comment during a walk. Someone in the office then has to turn that into a written request that references the correct drawing, the correct specification section, and the actual ambiguity. That translation step is where days quietly disappear, because it competes with everything else on a project engineer's desk.
This is a strong fit for AI assistance. Given the field note, the drawing reference, and the relevant specification text, a system can produce a first draft with the background stated and the question posed clearly. The project engineer then does what only they can do: confirm the question is technically correct, that it has not already been answered, and that it is worth asking. The draft is scaffolding, not the submission.
Chase on a schedule, and record the chase
Following up on RFIs is repetitive, time-sensitive, and easy to defer. It is also the single highest-return administrative habit on most commercial projects. Build a rhythm: a reminder to the responsible party a few days before the response is due, a direct follow-up when it passes, and an escalation to the project manager after that. The intervals should be set once and applied consistently.
Record every follow-up with a date. If the project later turns into a dispute about delay, the contemporaneous record of when you asked, how often you chased, and when the answer arrived is worth considerably more than a reconstruction from memory. This is documentation that costs nothing to create while the work is happening and is impossible to recreate afterward.
Connect the answer back to the work
An answered RFI is only useful if the answer reaches the people executing. Closing the loop means the response is distributed to the foreman, attached to the affected drawings, checked against any cost or schedule impact, and converted into a change order request when it changes scope. That last connection is frequently missed, and it is often where the RFI process quietly turns into an unpaid change.
Start the improvement on one project. Pull the current RFI log, add days open and blocked activity for each item, and sit with the project team for twenty minutes. The pattern will be obvious, and it usually points at one or two handoffs rather than at the log itself.
Fewer, better RFIs beat more of them
There is a counterproductive pattern where a project team submits a high volume of RFIs, many of them answerable from the documents already issued. Response quality degrades, the design team starts triaging your requests by reputation, and the ones that genuinely matter get slower answers because they are buried in noise.
Before submitting, check whether the question is already answered in the specifications, an earlier RFI, or an addendum. This is a search problem across documents you already hold, and it is well suited to automated assistance. A prompt showing the three most likely existing answers before an RFI is submitted cuts the volume and protects the credibility of the ones you do send.
