A request for information (RFI) log is a shared tracking record for questions that need a documented response. A useful log helps project engineers, document controllers, and project managers see what was asked, who must act, when a response is expected, what documents it relates to, and whether follow-up work remains. This article provides general workflow guidance, not a contract procedure or a rule for every project.
Before using the workflow on a live project, check the contract, project correspondence procedure, document-control rules, approved communication channels, and any required forms. Those project documents govern response periods, authorised respondents, notice requirements, distribution, status definitions, and whether an RFI may be used for a particular purpose. Do not assume that an RFI changes the contract, approves a design, authorises a cost, or grants time.
1. Establish the project’s RFI rules
Start by confirming how the project defines an RFI and which questions belong in that process. The project may use separate processes for design clarification, technical submittals, nonconformance, change proposals, site instructions, or urgent safety concerns. Use the designated process and escalation route rather than forcing every issue into the RFI log.
Record the governing procedure and its current revision, the approved submission channel, the parties permitted to raise and answer requests, and any project-defined response period. If the documents do not specify a rule, mark it for project clarification instead of inventing a deadline or authority. The log should reflect the project’s approved conventions, not impose a universal workflow.
2. Register each request as a traceable record
When a request arrives, give it a unique identifier under the project’s numbering convention and enter it in the central construction log. Capture the received date, originator, recipient or responsible organisation, subject, location or work package, and a concise description of the information requested. Preserve the original request and attachments in the project’s approved document system.
Write the log summary so another team member can understand the issue without changing the meaning of the request. Keep the question distinct from assumptions, proposed solutions, and commentary. If the request is unclear, incomplete, duplicated, or outside the RFI process, record that condition and route it for clarification in accordance with project procedure. Do not silently rewrite the original submission.
Useful log fields
- RFI identifier and, where applicable, related or superseding identifiers.
- Subject, originator, recipient, responsible responder, and current action owner.
- Received date, project-defined due date, response date, and closure date.
- Location, work package, discipline, and concise description of the information request.
- Linked drawing, specification, submittal, correspondence, or other controlled document references, including revision where known.
- Status, next action, next-action owner, target date, and closure evidence.
- Potential schedule or cost implications, clearly marked as unassessed or pending where appropriate.
Adapt these fields to the project’s approved system. A spreadsheet, document-control platform, or other tool can support tracking, but the tool does not determine contractual effect or replace the controlled record.
3. Assign ownership and set a visible due date
Every open RFI needs an identifiable person or role responsible for the next action. Distinguish the person coordinating the log from the party responsible for preparing the technical response. If the request passes between disciplines or organisations, record the current owner and the next hand-off so it does not disappear between inboxes.
Enter a due date only according to the contract or project procedure. Where a date is not defined or cannot yet be confirmed, show that clearly and request direction from the appropriate project authority. Do not label a date contractual unless the governing documents support that treatment. A visible owner and date make delay easier to notice; they do not, by themselves, establish entitlement or liability.
For overdue items, follow the project’s escalation and communication route. Record the escalation date, recipient, and resulting action in the log or linked correspondence. Keep reminders factual: identify the RFI, its current status, the outstanding action, and the relevant project-defined date rather than asserting an unsupported consequence.
4. Track status through the response workflow
Use a small set of clear statuses that matches the project’s system. A typical general workflow might distinguish received, under review, awaiting input, responded, and closed, but these labels are examples—not required project statuses. Define what each label means, who may update it, and what record supports the change. Avoid ambiguous labels such as “done” when a response exists but follow-up action is still outstanding.
At each review, check open items for owner, due date, current action, and dependencies. Where more information is needed, record who must provide it and what is being requested. If an RFI is withdrawn, superseded, or redirected, retain the history and link the related record rather than deleting the entry. The log should preserve a traceable path from the initial request to its disposition.
5. Link the question and response to controlled information
Identify the drawing, specification, schedule, submittal, or other document that prompted the question, using the project’s reference and revision conventions. Link the response and its attachments to the same RFI record. If the answer points to a revised drawing or other controlled document, record that reference and check the document-control process for distribution and status.
Keep the original request, response, attachments, and relevant follow-up correspondence accessible through approved project records. A short log summary is an index, not a substitute for the complete record. If the response is unclear, incomplete, or inconsistent with another instruction, do not present it as resolved; seek clarification through the authorised process and preserve the related correspondence.
6. Assess response implications without overstating them
A response may require a drawing update, coordination with another discipline, a revised submittal, a field instruction, or further review. Record the resulting action, its owner, and how completion will be evidenced. If the response appears to affect planned work, sequencing, procurement, cost, or the programme, flag the potential impact for review by the responsible project team.
Do not treat a potential impact entered in the log as an approved change, a verified delay, or a cost determination. The relevant contract and project procedures govern notice, assessment, approval, and change control. Where an impact is uncertain, use wording such as “potential impact—assessment required” and link to the applicable project record once one exists.
If work cannot proceed safely or appropriately while information is unresolved, follow the project’s applicable safety, supervision, and escalation procedures. The RFI workflow alone does not authorise work, suspend it, or replace a competent project decision.
7. Confirm closure with evidence
Define closure according to the project procedure. As general workflow guidance, do not close an RFI merely because someone sent a response. Check that the response is recorded and distributed through the approved channel, the requested information is sufficiently clear for the intended decision, and any follow-up action assigned to the RFI has a recorded disposition. Whether those checks are enough depends on the project’s rules and the nature of the request.
Record who confirmed closure, when it occurred, and what evidence supports it. If implementation or a separate approval is still pending, keep that action visible or link it to the project’s designated tracking process. A response may answer a question while related design approval, change control, procurement, or site action remains open.
8. Review the log regularly and report exceptions
Set a review cadence that suits the project’s procedure and workload; this article does not prescribe an interval. During each review, scan for unassigned requests, missing or unconfirmed due dates, overdue responses, requests awaiting input, incomplete document references, unclear responses, and open downstream actions. Record the review’s actions in the approved system so that follow-up is not dependent on memory.
For each exception, record its identifier, description, owner, next action, target date where authorised, and closure evidence. If the team uses a dashboard or summary report, ensure it is generated from the current controlled log and that its status definitions are understood. Counts and status summaries are useful for visibility, but they do not establish the technical adequacy of a response or the contractual effect of an RFI.
Practical RFI response-tracking checklist
- Is the RFI registered with a unique identifier and linked to its original submission?
- Are the originator, responsible responder, current owner, and next action identifiable?
- Does the recorded due date follow the project’s governing procedure, or is its status clearly marked for confirmation?
- Are relevant drawings, specifications, revisions, responses, attachments, and correspondence linked?
- Does the status accurately distinguish a received response from completed follow-up?
- Are potential information, schedule, or cost effects flagged for assessment without presenting them as approved determinations?
- Is the disposition or closure supported by a traceable record and consistent with project procedure?
- Are overdue, unclear, superseded, or dependent items assigned an owner and a documented next step?
Related EngineersBlog reading
- Request for a Meeting with Higher Management to Discuss
- Construction Management Contracts. – Construction
- Fast Tracking in Project Management: A Detailed Guide
- Material Submittal Register Review: Practical Workflow
These pages provide related reading context; they do not establish requirements for a particular project’s RFI procedure.
Research and source context
- FHWA Construction Team – Construction – Federal Highway Administration
- Creating Helpful, Reliable, People-First Content | Google Search Central
The supplied research identifies these sources but does not provide a specific RFI standard or project procedure. Accordingly, the tracking sequence above is general workflow guidance. Confirm technical, contractual, and jurisdiction-specific requirements against the documents and authorities applicable to the project.
Conclusion
A dependable RFI log connects each request to an owner, a project-authorised due date, a traceable response, relevant controlled information, and any resulting action. Regular tracking helps teams see unanswered questions and incomplete follow-up, while clear qualifications prevent the log from being mistaken for contract approval or a technical instruction. Use the project’s governing procedure, preserve the full record, and close items only in the manner the project authorises.
