An RFI is not just a message. It is a project question with an owner, a deadline, a response and often a cost or schedule consequence.
When that history is split between email threads, spreadsheets and drawing notes, the question may still get answered — but the project can lose the record of who was holding it, when the answer was due and what changed because of it.
Treat every RFI as a controlled record
A useful RFI log should let someone understand the item without reopening the original inbox thread.
- RFI number and short title;
- the question being asked;
- drawing, specification or location reference;
- who raised it;
- who owns the response;
- date submitted;
- response due date;
- current status;
- date answered;
- cost or schedule impact when one exists;
- linked response, attachment or decision.
The point is not to build the biggest register possible. It is to keep enough context to know what is open, who has the ball and what the answer changed.
One RFI should contain one clear question
Combining unrelated issues into one RFI makes ownership, response dates and downstream impact harder to follow. Keep each meaningful question separate when it could receive a different answer or affect a different part of the project.
Make ownership visible
A status such as Open is not enough if nobody can see who is expected to act next.
For each open RFI, make the next responsible party obvious. If ownership changes, update the record rather than relying on the latest forwarded email to explain the handoff.
Track the dates that explain delay
The useful dates are not only when the RFI was created. Keep the submitted date, required response date and actual response date together. That makes overdue items visible and gives the project a defensible history if a late answer affects later work.
Keep the answer connected to the question
Do not close an RFI simply because someone replied. Preserve the final written answer and connect it to the exact question, drawing or condition it resolves.
If the response creates a design change, cost impact, schedule impact or follow-up action, record that consequence while the context is still fresh.
Review the log as an active control surface
An RFI log is most useful before something goes wrong. Review open items regularly and focus on what is overdue, what is approaching its response date and what is blocking downstream work.
The rule worth keeping
Do not let the inbox become the project record.
Keep the question, owner, dates, answer and impact together so the project can see what is still unresolved and reconstruct what happened later.