RFI Log Template: What to Include and How to Keep It Organized

If every RFI lives as a separate email thread, answering "which questions are still open" means scrolling back through weeks of email trying to remember which ones got a reply. A log fixes that by putting every request in one place, with the same fields filled in every time, so status is visible without reconstructing it from memory or searching an inbox.

Each of these earns its place because it answers a specific question someone will eventually ask about that RFI.

• RFI number: a unique, sequential reference so the request can be cited consistently in emails, meeting notes, and change orders
• Date submitted: when the question was actually sent, not when it was first discussed informally
• Submitted by: who raised the question, since the person who needs to follow up is often the person who originally asked
• Question: the specific question itself, written clearly enough that someone reading only this field understands exactly what's being asked
• Reference: the drawing sheet, detail number, or spec section the question relates to, if there is one
• Assigned to: who is responsible for answering, a specific person, not just "the architect's office"
• Date due: when the answer is needed, based on when the work is actually scheduled to happen
• Date answered: when the response actually came back, which is what lets you see how long requests are really taking
• Answer: the actual response, recorded in the log itself rather than only left in an email that could get buried
• Cost/schedule impact: a simple flag for whether the answer is likely to require a change order or push the schedule, so those items get separate attention
• Status: open, answered, or closed, where closed usually means the answer has also been incorporated into the work, not just received

An RFI without a due date tends to get answered whenever it's convenient for the person on the other end, which is rarely before the work it affects is actually scheduled to start. Setting the due date based on when the field crew needs the answer, and not an arbitrary number of days after submission, is what turns the log into a tool for protecting the schedule instead of just a record of questions that were eventually answered, sometimes too late to matter.

Not every RFI costs money or time. A question that confirms the obvious interpretation was correct usually doesn't. But some answers come back requiring a different material, additional work, or a sequence change, and those need to be flagged the moment that becomes clear, not discovered weeks later when someone's trying to reconcile a change order against the original contract. A simple yes/no or high/medium/low flag in the log is enough to make sure those items get pulled out and addressed separately instead of sitting quietly in a "closed" row.

A log that only gets opened when someone remembers to check it isn't doing its job. Reviewing open RFIs on a set schedule, weekly on most projects, makes it obvious which ones are approaching their due date and which have already slipped past it, so follow-up happens before a crew is standing around waiting on an answer instead of after.

A log works best when one person is responsible for keeping it current, even if many different people submit questions into it. On most projects that's the project manager or a project engineer, not the superintendent who's busy running the field and not the architect who's on the other end answering. The owner of the log doesn't need to answer every question themselves; they need to make sure every question that gets asked verbally or informally actually gets written into the log the same day, before it's forgotten, and that answers coming back by email or phone get recorded rather than left to live only in someone's memory of a conversation.

A log that stops getting updated is worse in some ways than no log at all, because it creates false confidence. Someone glances at it, sees a handful of open items, and assumes that's the full picture, when in reality half a dozen more recent questions were asked by text message and never made it in. The habit that actually protects a schedule isn't the log's format, it's the discipline of entering a question the moment it's asked and the answer the moment it comes back, rather than batching that work for whenever there's a free afternoon.

If your project requires a formal numbered log, the spreadsheet above, or whatever document control system your contract specifies, is the right tool for it. For contractors who don't need formal numbering but still want each request assigned, tracked, and tied to communication with the person answering it, a task in ConstruDo with the question in the description, a due date, and an assignee covers the same core fields informally, and can carry the follow-up email thread with it if the person answering isn't someone who uses the app day to day.

Copy these columns into a spreadsheet, or use them as the structure for a log in whatever system you already track project documents in. Download the blank template as a CSV file, which opens directly in Excel, Google Sheets, or Numbers.

The project, people, and companies below are fictional and for illustration only. They do not describe a real ConstruDo customer or project.