How to answer a construction RFI

Search for advice on construction RFIs and you will find a great deal of it. Almost all of it is written for the person asking — how a contractor should phrase a question, what to attach, how to escalate when nobody replies.

Very little is written for the person who has to answer.

That is the half that lands on an architect's desk, usually at 4:40 on a Friday, usually about a detail you thought was clear. What follows is how to answer one so that it closes the question, holds up when someone reads it two years from now, and does not quietly hand you work you were never paid for.

What an RFI actually is by the time it reaches you

By the time it reaches you an RFI is three things at once, and separating them is most of the job.

It is a question — someone in the field genuinely does not know what to do next. It is a schedule instrument — the clock started when it was submitted, and your response time is being recorded whether or not anyone mentions it. And it is a piece of the project record — a document that will be read later by people who were not there, possibly in a dispute, possibly by you.

Most bad responses come from answering only the first of those and forgetting the other two.

Answer the question that was asked

The most common failure is not a wrong answer. It is an answer to a slightly different question.

An RFI arrives asking what the head condition is where the storefront meets the soffit at grid 4. You know that detail. You also know the contractor has been getting the jamb condition wrong all month. So you answer both, and you add a note about the sill while you are at it.

Now you have created three problems. You have buried the answer to the actual question inside a paragraph about two others. You have introduced conditions the contractor did not ask about and may not have priced. And you have made the record ambiguous about what was actually clarified on that date.

Answer what was asked. If the other conditions need attention, that is a separate RFI response, a field report, or a supplemental instruction — a separate document with its own date.

Cite the sheet and the spec section

An answer without a reference is an opinion. An answer with a reference is an instruction that points back into the contract documents.

"Provide the 6 inch metal stud with the 1 1/2 inch rigid, as detail 1/A-501" is a different sentence from "use the 6 inch stud." The first tells the contractor where to look, tells the next person which document governs, and tells a reader in two years that you did not invent the requirement on the spot — it was already there.

Reference the sheet and the revision it is on. "Detail 1/A-501" is incomplete if A-501 has been through three revisions and the field is holding Rev 2. Say which one.

Where the answer touches materials or performance, cite the specification section too. 05 40 00 carries weight that a sentence in an email does not.

The non-answers that generate a second RFI

Some responses are technically replies and functionally nothing. Each of these will come back:

• "As shown on the drawings." If it were clear on the drawings, the RFI would not exist. Either the drawings do answer it — in which case say where, precisely — or they do not, in which case answer it.
• "Per specifications." Same problem, one degree worse, because specifications are long.
• "Contractor to verify." Sometimes correct and necessary. Frequently a way of returning the question to sender without deciding anything.
• "See attached." With no indication of what in the attachment matters. A sixteen page product data sheet is not an answer.
• A question back. If you genuinely need information to answer, ask for exactly that one thing and say what you will do when you have it. Do not answer a question with a question and stop the clock.

The test is simple: could the person in the field act on this without contacting you again? If not, it is not finished.

When the RFI is a change order wearing a question's clothes

This is the one that costs money, and it is worth slowing down for.

Some RFIs are not requests for information. They are requests for a decision that carries cost or time, framed as a question so that the answer arrives as a free instruction.

"Please confirm the ceiling height in Room 214 is 9 feet 6 inches" is a question. "Please confirm we can substitute the specified fixture with the attached, as the specified one has a 22 week lead" is a change dressed as a confirmation.

The tell is usually that answering "yes" would alter scope, cost or schedule. When you see it, the response is not to refuse to engage — it is to name what is actually happening. Answer the informational part, and identify the rest as what it is: a proposed substitution, a proposed change, something that needs to run through the change process the contract actually specifies.

None of this is legal advice, and the contract governs — the AIA and EJCDC families handle this differently, and your project may be modified from either. But the practice is consistent: do not let a change enter the project through the RFI log. Once it is in there as an answered question, it is very hard to argue later that it was never authorised.

Response time is being measured

Every RFI has a submitted date and a returned date, and the difference is a number that appears in schedule claims.

Two things follow. First, an incomplete answer that closes the RFI and generates a new one does not actually save time — it produces two log entries and looks worse, not better. Second, if the delay is genuinely on the consultant side, the record should say so at the time, not in a letter six months later.

The practical version: when an RFI needs a consultant's input, log that you routed it and when. A gap in a record is read as your gap by default.

Write it for the reader who was not there

Assume the reader is a person two years from now who has never seen the building, does not have the email thread, and is trying to work out what was decided and on what basis.

That reader wants: what was asked, what was answered, which documents governed, what the answer changed, and when. If your response supplies those five things, it will survive. If it says "as discussed," it will not — because nobody has any idea what was discussed.

Pin the answer to the sheet version it was asked against

This is the part almost nothing handles well, and it is where responses quietly rot.

An RFI is asked against the drawings as they existed that day. Two revisions later, the sheet has changed. If the RFI simply points at "A-501," anyone opening it now sees the current sheet — which may no longer show the condition that was asked about. The answer becomes unintelligible, or worse, appears wrong.

The record needs to hold both: the answer, and the version of the document it was answering. Superseded sheets should not disappear. They should be marked superseded and stay reachable, so an RFI opened in year three still shows the field what the field was actually looking at in year one.

A short checklist

Before you return an RFI response, read it once and ask:

1. Does it answer the question that was asked, and only that question?
2. Does it cite a sheet and revision, and a spec section where relevant?
3. Could someone act on it without calling you?
4. If answering it changes scope, cost or time, have you said so?
5. Will it make sense to someone who was not there, two years from now?
6. Does the record show which version of the drawing it was asked against?

That last one is the one people discover they cannot answer, usually at the worst possible moment.

BuildCycle keeps each RFI pinned to the sheet version it was asked against, so the record still shows what the field was looking at — and reads the pattern back to you, so the detail that drew six questions this project does not draw six more on the next one.