RFI Log Template and How to Run One
A request for information is a question the field cannot answer on its own: a drawing that contradicts the spec, a condition nobody expected behind a wall, a detail that was never drawn. The RFI log is the record of every one of those questions — who asked it, what it referenced, who owes the answer, and what the answer was. On a well-run project the log is boring. On a badly run one, it is where the delay claims come from.
This guide covers what a good RFI contains, how to write a question that gets answered instead of returned, and how to run the log so nothing sits open unnoticed. The template at the end follows the same structure.
What an RFI log is for
An RFI log does three jobs, and the third is the one people forget until they need it:
- A queue. Every open question, in one place, with a date it was raised and a date it is needed. Without the log, questions live in email threads and get answered in the order someone happens to read them.
- A record of decisions. The response to an RFI is often a design decision. Six months later, when someone asks why the conduit runs where it runs, the answer is in the log.
- The evidence in a delay dispute. If a question sat unanswered for three weeks and the work behind it stalled, the log shows the dates. If the question was vague and had to be asked twice, the log shows that too.
An RFI is not a change request, a submittal, or a complaint. It asks for information the contract documents should have provided. If the answer changes scope, cost, or schedule, that is a change — the RFI just uncovered it.
What belongs in every RFI
The template carries eleven columns. The first five come from the field; the rest are the log-keeper's and get filled in as the RFI moves.
- RFI # — sequential, never reused. The number is how everyone refers to it from then on.
- Date raised — the day the question was asked, not the day it was typed up.
- Context / reference — the drawing, sheet, detail, spec section, or location the question is about. "Sheet E-401, Detail 3, Panel LP-2" lets the engineer open the right page in ten seconds. "The electrical drawings" does not.
- Question — one question, asked so it can be answered in a sentence or a sketch.
- Impact if unanswered — what happens to the work if no answer comes by the date needed. State it only if you know it. "Slab pour on Grid 4 cannot proceed" is an impact. Guessing at cost or days is not; that belongs in a change request once the answer is in.
- Raised by — the person, so the engineer knows who to call for clarification.
- Responsible party — who owes the answer: architect, engineer of record, owner, vendor.
- Date needed — the honest date, not "ASAP." A needed-by date is what turns a question into a commitment.
- Date answered and Response summary — filled in by the log keeper when the answer arrives; the full response is attached, the summary is what the log shows.
- Status — Open, Answered, or Closed. Answered means a response came in; Closed means the response was reviewed and the field can act on it. They are not the same thing.
How to write a question that gets answered
Most RFIs that come back "please clarify" were never questions. They were observations with a question mark.
One question per RFI. "Confirm panel schedule for LP-2, and also is the feeder size correct, and what about the grounding?" is three RFIs. Written as one, it gets a partial answer and stays open.
Say what you found, then what you need. Context: "Sheet E-401 shows LP-2 as 42-circuit; the panel delivered is 30-circuit." Question: "Which is correct, and if 42, who supplies the replacement?" The engineer can answer that without a site visit.
Reference something the responder can open. A sheet number, a spec section, a photo. A question with no reference sends the engineer looking for the problem before they can think about the answer.
Offer a proposed answer when you have one. "We propose to route the conduit above the duct at Grid C-5 with 12 in. clearance — please confirm." A yes/no closes faster than an open question, and it shows the field did its homework.
State the impact only when it is real. "Impact if unanswered: none this week" is a legitimate entry and tells the responder how to prioritize. Inflating every RFI to "critical path" trains people to ignore the word.
Weak: "Ceiling height in Room 204 — please advise."
Better: "Context: Sheet A-201 shows Room 204 ceiling at 9'-0"; Sheet M-301 shows a 24 in. duct at 8'-6" AFF in the same room. Question: Which governs — is the ceiling dropped to 8'-0" or is the duct rerouted? Impact if unanswered: ceiling grid layout on hold from 10/6."
Running the log
Number on entry, not on send. The log keeper assigns the number the moment the question is written, even if it goes out the next morning. Two people numbering from their own lists is how RFI-14 exists twice.
One keeper. Usually the project manager or the owner's representative. Anyone can raise an RFI; one person owns the log.
Set a turnaround and track against it. Most contracts name a response period — commonly five to ten working days. The log makes the clock visible: a column of dates needed against dates answered is a report nobody has to write.
Chase from the log, not from memory. Once a week, sort by status and date needed. Every open item past its date gets a call, and the call gets noted. "Called EOR 10/3, response promised 10/5" is the kind of line that matters later.
Close it on the field's terms. The log keeper marks an RFI Answered when the response lands and Closed when the person who asked confirms it answers the question. If it does not, it goes back Open with the reason, under the same number.
Distribute the current log, not a marked-up copy. Everyone works from the same version. Old versions go in the project file.
Route what changes scope. If an answer adds work, changes materials, or moves dates, the RFI is closed and a change request opens, referencing it. Keeping the two separate is what keeps the RFI log credible as a record of questions rather than a negotiating file.
Common mistakes
- Questions without references. The single biggest cause of the "please clarify" round trip.
- Multi-part RFIs. Partial answers, permanent Open status.
- "ASAP" as a needed-by date. It means nothing and gets treated that way.
- Estimating impacts you cannot support. Every inflated impact makes the real ones less believable.
- Answered and Closed treated as one state. A response that does not answer the question is not closure.
- Chasing by email thread. The log is the chase list. If a follow-up is not on the log, it did not happen.
- Letting the RFI carry the change. Scope changes go through the change process, with the RFI as the reference.
Download the template
The template follows the structure above: a project header, then a numbered log with date raised, context and reference, question, impact if unanswered, raised by, responsible party, date needed, date answered, response summary, and status. Landscape, prints in black and white, works in Word or as a PDF you fill by hand.
How FieldBinder AI produces an RFI list
In the field, an RFI is one capture: the question, typed or dictated, tagged RFI, with the project it belongs to. Photos taken in the same project sit beside it in the feed. Each RFI carries an open/done checkbox you tick when the question is resolved.
When you generate an RFI List, the app reads the project's captures and drafts a numbered list of the questions that were explicitly asked — it will not invent a question from something that merely looked unclear. Each item carries the context as you stated it, the question, and the impact if unanswered, only where a capture stated one; otherwise it says "Impact not specified." It never estimates schedule or cost. The list exports as a branded PDF with the project's site photos, or as plain text for an email to the design team.
The list is the field's half of the log — the questions, with their context, drafted before they are forgotten. The RFI numbers, the responsible party, the dates needed and answered, and the response summary are the log keeper's half, and the template is built to hold them. Every generated report is marked as AI-assisted, and you review it before it goes out.
AI report generation is part of the Pro plan; capture and organization by project are included on every plan. See pricing · How it works for engineering consultants
Frequently asked questions
What is the difference between an RFI and a change order request?
An RFI asks for information the contract documents should have provided. A change order request asks for a change in scope, cost, or time. An RFI's answer often reveals that a change is needed; when it does, the RFI is closed and the change request opens with the RFI as its reference.
Who can raise an RFI?
Anyone on the project who hits a question the documents do not answer — a superintendent, a foreman, an inspector, an owner's representative. One person keeps the log and assigns the numbers.
How long should an RFI response take?
Whatever the contract says; five to ten working days is common. The log's job is to make the actual turnaround visible against the promised one, so late answers are a fact on a page rather than a memory.
Should every field question become an RFI?
No. A question the superintendent can answer from the drawings is not an RFI. An RFI is for questions the documents cannot answer, or answer two different ways. Logging trivial questions buries the ones that matter.
Can an RFI log be used in a delay claim?
RFI logs are routinely part of the record in schedule disputes, which is the reason to keep the dates honest and the questions specific. This guide is not legal advice; ask your counsel how your project's records should be kept.
