Request for Information Log

Projects often uncover gaps in drawings, specifications or instructions, and a request for information, or RFI, asks the appropriate party to clarify. The log makes sure the question does not vanish in a long email chain.

A fictional contractor sees two drawings showing different door sizes, raises an RFI with both references and a specific question, and the register records who must answer. Assign a unique number and project reference, and include the submitter, date, subject, drawing or specification section and precise issue, because vague entries are hard to answer.

A fictional RFI says only "door problem", so the project manager asks for the floor, drawing revision and exact conflict before routing it. Record the answer owner and any reviewers, since a designer may need input from an engineer or owner but someone should own the final response, and a queue without ownership ages quickly.

Dates matter: submitted, required, responded and closed, and a deadline can be based on project needs and contract rules, not an arbitrary template. Escalate questions on the critical path; a fictional steel order is due Friday, so a connection detail unresolved by Wednesday threatens fabrication and the team raises its priority.

Procore's RFI workflow describes an assignee replying and the RFI manager reviewing that answer, and it also allows an "official response" when multiple people have commented, which are product-specific mechanics that illustrate a general need for decision clarity. A fictional thread contains three opinions about a pipe route, so the coordinator waits for the authorised design response before telling the installer to build.

Include answer text or a reliable link to it, because a summary alone can omit conditions and caveats, and keep attachments, sketches and revised drawings with their version identifiers. A fictional engineer approves a route only if clearance is maintained, so the log links to the full answer and the condition is not lost.

A response may raise another question, so mark it answered only when the specific clarification is usable and close it when the project's closeout rule is met, never treating silence as agreement (a fictional designer who asks for a site dimension before finalising the detail keeps the RFI open with the measurement action assigned). Changes in scope, time or cost should be tracked, but an RFI answer is not necessarily a change order, so use the contract's change process for commercial approval; a fictional answer calls for a more expensive finish, and procurement records the technical direction and requests the required cost authorisation separately.

Keep the issue concise and neutral, because an RFI is not a place to hide a claim or accuse another party, and clear questions produce faster, more useful answers. Review open and overdue questions regularly, remembering that ageing alone is not priority, since a safety-critical answer may be urgent on day one, and report dependencies and impact honestly.

Avoid duplicate RFIs by searching the log first, link a new request to any superseded response and explain why the old answer no longer applies, use status labels consistently (open, under review, answered, closed or cancelled, as defined by the project), and distribute each answer to affected trades, planners and document control, not only the person who asked. Preserve revisions so people can see what was known at each stage, as when a fictional RFI response changes after a field survey and the log marks the first answer superseded and links the replacement, and measure response time, open backlog and recurring causes, since repeated questions about one drawing may reveal a document problem, not lazy contractors, and a simple controlled spreadsheet or a project platform is only a tool that does not replace an agreed decision process.