Construction RFI Template: 15 Fields and a Filled Clarification Example

A construction RFI template gives a project team a clear way to request missing or conflicting information. RFI means request for information. A useful form identifies the exact question, the document it concerns, and the date when the answer matters to the work.

This guide provides a blank field structure, a filled construction RFI example, and a practical review workflow. It also explains how to write a focused question, track replies, and keep clarification separate from changes to scope, price, or schedule.

When should you use a construction RFI?

Use an RFI when the team needs a formal answer to a project question. For example, two current drawings may show different details for the same location. A missing specification can also leave the crew unable to order the right item.

Procore’s construction RFI resources describe requests that clarify drawings, specifications, and other project details. They also offer downloadable forms. However, use your project’s required form and routing process when one already exists.

Before raising a request, check the current document set and earlier answers. The question may already have a clear response. If so, link the crew to that record rather than opening a duplicate request that creates another version of the same answer.

An RFI is not a general note for every site event. Keep routine progress records, product submissions, and change requests in their own processes. The RFI should lead the recipient to a specific information gap they can resolve.

A copyable construction RFI template

The structure below works as a starting point for a Word document, shared form, or spreadsheet-backed workflow. Copy the labels and leave space for the actual question and response. Then adapt the routing and approval fields to the project.

Keep the official response field separate from comments. Several people may add background before the responsible party gives the answer. A busy crew should not have to guess which comment controls the work.

Also, retain the attachments with the request. A link to a file that later changes can remove the context behind the question. Use the project document system’s version rules to keep the referenced record.

Write a question that someone can answer

Start with the observed conflict or missing detail. Name both references when they disagree. Then ask for the specific information that will resolve the issue. Avoid a long account of the whole project before the reader reaches the question.

A vague request might say, “Please confirm the ceiling.” A focused request could say, “Drawing A-210 revision 3 shows a 2,700 mm ceiling in Room 204. Detail 7 on A-510 revision 2 shows 2,600 mm. Please confirm the required finished ceiling height for this room.”

The second request names a location, two current references, and the answer needed. It does not assume which drawing is correct. Therefore, the recipient can review the conflict without asking the sender to restate the basic facts.

If a sketch helps, mark the relevant area and label what it shows. Keep proposed work distinct from existing design information. A markup that blends those two things can make the request harder to assess.

A filled construction RFI example

Consider a fictional office fit-out. The ceiling crew plans to start Room 204 after the next coordination review. The project team finds the height conflict described above and prepares RFI-018.

• Subject: Room 204 finished ceiling height.
• Location: Level 2, Room 204, grid C4.
• References: A-210 revision 3 and A-510 revision 2.
• Question: Confirm the required height where the current documents differ.
• Needed by: Before the planned ceiling layout release.
• Attachments: Two marked extracts showing the conflicting heights.
• Potential impact: Layout may need revision; cost and time effect not yet assessed.
• Proposed option: None until the design team confirms the requirement.

Next, the routing owner assigns the request to the right reviewer. The answer confirms a height and names the supporting drawing revision. The project team distributes that answer to the ceiling crew and affected trades through the approved route.

In this example, the RFI log also records whether the answer requires a revised layout or a separate change process. The team does not mark the request complete merely because someone replied. It checks that the response resolves the original question.

Set a useful response-needed date

An answer-needed date should connect to an actual decision or work activity. Explain whether it affects ordering, layout, access, or another dependency. A date with a reason helps the reviewer understand the priority.

First, allow time for internal checking and distribution after the answer arrives. The date the crew needs to act may not be the same as the date the reviewer should reply. A last-minute answer can still leave the team without time to update the work package.

Our article on construction scheduling programs covers links between tasks and constraints. Tie important RFI dates to those constraints so the schedule review can see what remains unresolved.

When the planned date changes, keep the original date in the history. Add the revised date and its reason. Otherwise, a report can make a late request look timely just because someone moved its due date.

Use a simple RFI register

The form holds the detail. The register shows the work still open across the project. Keep one row per RFI, with a stable ID that links to the full question, attachments, and response.

Useful register columns include subject, location, submitted date, needed-by date, response owner, status, and next action. Add the official response date and closure date separately. Also, identify any linked change or revised document.

Do not put the entire communication thread in a spreadsheet cell. Use a short summary and a link to the controlled record. This makes the register easier to scan while keeping the information needed for a deeper review.

Procore’s RFI workflow documentation illustrates a draft-to-review process with an assigned manager and response roles. Your own workflow can use different labels. The important point is that each open request has a clear next owner.

Keep an RFI separate from a change order

An answer may reveal a change, but clarification and change approval serve different roles. Do not treat every response as permission to charge more, extend time, or proceed with revised scope. Follow the contract’s required route for those decisions.

For example, the height answer in RFI-018 may affect work already installed. The team should record that consequence and route any resulting claim or change request for review. It should not edit the RFI question to make the added work look like the original scope.

Keep proposed cost and time effects separate from agreed effects. Use labels such as “not yet assessed,” “submitted for review,” or “approved reference attached” where they fit the project process. A blank impact field should not silently mean zero impact.

The construction management workflow needs these links between records. Each form should retain its purpose while pointing to the related decision.

Check the response before closing the request

Read the answer against the original question. Does it name the affected location and resolve the conflict? Does it reference a document the crew can access? If part of the question remains open, ask for the missing clarification through the project route.

Next, check whether the answer affects other trades or locations. A ceiling-height decision may also matter to lights, ducts, or partitions. Record the distribution list so the project can see who received the information.

Finally, separate “answer received” from “field action complete.” Some teams close the information request once the official answer exists and track execution elsewhere. Others use an extra state. Whichever method you choose, do not lose the remaining action.

Six mistakes that slow down RFI answers

1. Combining several unrelated questions in one request.
2. Referencing a drawing without its revision.
3. Asking a question that an earlier official answer already resolves.
4. Setting a due date without explaining the affected task.
5. Presenting a proposed solution as though someone has approved it.
6. Closing the request without sending the answer to the people who need it.

Review a few recent requests to find the most common cause of rework. Then adjust one part of the form or routing process. A clearer question often helps more than adding another required field to every request.

Moving the template into a shared system

A document works well when one owner manages a small volume. As the project grows, a shared system can help track versions, due dates, and distribution. Start with those needs rather than a long list of optional features.

A reporting layer can show overdue requests and open constraints across projects. Our guide to custom reporting software explains that approach. Keep each summary linked to the actual RFI so managers can check the underlying question.

If you need a customer or project coordination layer, custom crm development may support the handoffs. Define who owns the official record before connecting systems. A copied answer should never drift away from its source version.

Handle an answer that creates another question

Sometimes a reply resolves only part of the issue. First, compare it with the exact question rather than relying on the email subject. Name the missing detail and return it through the project route.

For example, a response may confirm the ceiling height but leave the affected drawing revision unclear. The crew still needs to know which current record supports the instruction. Ask for that reference rather than choosing one informally.

Next, keep the reply and further request in the history. If the project process calls for a new linked RFI, create it with a reference to the first one. Otherwise, use the existing record’s controlled follow-up route.

Also, review the work constraint while the answer remains incomplete. A response date alone can make a report look complete even though the crew still lacks the needed detail. Keep the next owner and required decision visible.

Finally, check that the final answer reaches everyone who saw the earlier partial reply. The latest response must not stay with one office user while the field crew acts on the previous one. Record the distribution and link the current document.

Test the template with one real question

Use this construction RFI template on a current information gap. Check that the recipient can find the location, documents, and exact answer needed. Then track the response through review, distribution, and any remaining action.