Knowledge · Business and operations
An unanswered question
is a delay in waiting.
When the drawings do not answer a question the build needs answered, the query that follows is not just a phone call, it is a piece of work waiting on someone else. This is the reference for running requests for information as a tracked process, so an unanswered query does not become a silent delay and an answer that adds scope does not become an unclaimed variation.
01 / Overview
The question the documents did not answer
A request for information, an RFI, is the formal query a builder raises when the construction documents do not answer a question the build needs answered. A detail is missing, two drawings clash, a specification is ambiguous, or the site turns out different to what was drawn. Every job generates them, because no document set is ever complete, and how a builder handles them is a quiet but real determinant of whether the job runs to time and whether the builder recovers what these gaps cost.
On a residential job the queries are often small, a window head height, a tiling setout, a bracket detail, but the mechanism and the cost of mishandling them are the same as on any project. An RFI is really a piece of information the site is waiting on, and information that is waited on is work that is stalled. This page sits alongside the broader construction documents reference, which covers the document set as a whole; this one is about the specific discipline of resolving the gaps in it.
Why it matters
The difference between a builder who runs RFIs well and one who does not is rarely the number of queries, it is whether they are tracked. A query raised by phone and never logged causes the same delay as a logged one, but silently, with no deadline, no accountability and no record. And an answer that adds scope or holds up the job carries a variation or an extension of time that only gets claimed if someone looks for it. Running RFIs as a process is how those hidden costs are made visible.
02 / The workflow
Running an RFI end to end
An RFI runs from the question on site to the closed entry in the register, and the two steps builders most often skip are logging it with a deadline and assessing its consequences once it is answered.
- 01
Raise the query
The site hits a question the documents do not answer, a clash between drawings, a detail that is missing, a specification that is ambiguous. The query is written up clearly, with the drawing reference and the decision it is holding up, rather than left as a phone call that leaves no trace.
- 02
Log it in the register
The query goes into the RFI register with a number, a date raised and the date a response is needed by. The register is what turns a scatter of questions into something the builder can chase, because an unlogged RFI is one nobody is accountable for answering.
- 03
Route it to whoever can answer
The RFI goes to the designer, engineer, certifier or client best placed to answer it. Routing matters, a structural query to the engineer, a finish query to the client or designer, because a query sent to the wrong person just adds a lap before the clock even starts.
- 04
Get the response, dated
The answer comes back in writing, tied to the RFI number and dated. A verbal answer that is never recorded solves the immediate problem and leaves nothing behind, which is a problem when the same question, or a dispute about the answer, comes back later.
- 05
Distribute and act
The response reaches everyone building to it, and where it changes the drawings it triggers a drawing revision so the site is not left working off a superseded set. An answer that reaches the supervisor but never updates the documents just creates the next version of the same confusion.
- 06
Close it, and check the consequences
The RFI is closed in the register, and its consequences are assessed, whether the answer added scope that is now a variation, or held the job up long enough to support an extension of time. A closed RFI with an unassessed cost or time impact is money or entitlement left on the table.
03 / The consequences
When an answer costs scope or time
The part of RFI management that most directly affects a builder’s money is what happens after the technical question is answered. An RFI response is not always neutral. If the answer adds or changes scope, it is a variation, to be documented, priced and approved before the work proceeds. If the wait for the answer held the job up, it may support an extension of time. Both are entitlements that exist whether or not the builder claims them.
The expensive habit is to treat closing the query and claiming its impact as one step. The technical answer arrives, the site acts on it, the RFI is marked closed, and nobody asks whether it added scope or cost time. The variation goes unclaimed and the delay goes unrecorded, both quietly absorbed by the builder. The record of when the RFI was raised and when it was answered, held in the register and reinforced by the daily site record, is exactly the evidence that turns an externally caused delay into a claimable one rather than a cost the builder simply wears.
04 / Failure modes
Where RFIs break down
RFIs go wrong in a handful of consistent ways, raised without a record, sent without a deadline, answered without updating the drawings, or closed without assessing what the answer cost.
Queries raised by phone, never logged
The supervisor rings the designer, gets an answer, and nothing is recorded. When the same question comes up again, or the answer is later disputed, there is no trace of what was asked or what was agreed, and the builder carries the uncertainty.
No response deadline, no chasing
An RFI sent with no by-when and no register entry sits in someone’s inbox while the trade behind it waits. An unanswered query on the critical path is a delay the builder is absorbing without even claiming it, because nobody is tracking the clock.
The answer never updates the drawings
The RFI is answered and the site acts on it, but the drawing it changed is never revised. The next person to read that drawing builds the old detail, and the RFI that was meant to resolve a problem quietly seeds another one.
Cost and time impact never assessed
The RFI response added scope or held the job up, and it was closed without anyone asking whether that was a variation or an extension of time. The entitlement existed and was let go, because closing the query and claiming its consequences were treated as the same step when they are not.
05 / FAQ
Common questions.
An RFI, a request for information, is a formal query raised when the construction documents do not answer a question the build needs answered. They happen because no drawing set is ever perfect, details go missing, drawings from different consultants clash, specifications are ambiguous, and site conditions turn out differently to what was drawn. On a residential job the queries are often smaller than on a commercial project, but the mechanism is the same, and the cost of handling them badly is the same. An RFI is not a sign the documents are bad, it is the normal process by which the gaps in any document set get resolved. What separates builders is not whether they have RFIs, it is whether they run them as a tracked process or as a series of untraced phone calls.
Because it usually sits in front of work that cannot proceed without the answer. A query about a structural detail holds up the frame; a query about a finish holds up the trade that installs it. While the RFI is unanswered, the trade behind it either waits or moves to other work and comes back later, and both cost time. If the query is on the critical path, the delay flows straight through to the completion date. The insidious part is that an unlogged, unchased RFI causes this delay silently, the builder absorbs the time without ever recording that an external party held them up, which means they also cannot claim the extension of time the delay might have entitled them to. Running RFIs through a register with response deadlines is how that silent cost is made visible and, where warranted, recoverable.
An RFI response often carries consequences beyond just answering the question. If the answer adds or changes scope, that is a variation, to be documented, priced and approved before the work is done. If the time waiting for the answer delayed the job, that may support an extension of time. The common and expensive mistake is to close the RFI once the technical question is answered and never assess these two consequences, so a variation goes unclaimed and a delay goes unrecorded. Closing the query and claiming its impact are different steps. The RFI register, read alongside the variations process and the extensions of time mechanism, is where a builder makes sure an answer that cost them scope or time is actually recovered rather than absorbed.
Because a register makes the queries chaseable, and email does not. An RFI in a register has a number, a date raised, a response-needed-by date and a status, so at any moment the builder can see what is outstanding, what is overdue and what is holding up work. Queries scattered through email threads have none of that, they get lost, they are nobody’s clear responsibility to answer, and there is no single place that shows what is waiting. The register also creates the record that protects the builder later, evidence of exactly when a query was raised and when it was answered, which is precisely what an extension of time claim built on external delay depends on. The register is the difference between managing information gaps and being managed by them.
06 / Keep reading
Related knowledge, guides and features
Turn a question on site into a tracked answer.
VIABUILD keeps queries, their responses and the drawing revisions they trigger against the job, so an RFI has a deadline and a record, the site always builds off the current answer, and an answer that adds scope or time surfaces as a variation or a claim rather than a silent cost.