Overdue RFIs: track the decision, required-by date and field blocker

Name the missing decision before chasing the date

A list sorted by oldest RFI can create urgency without showing what anyone should do next. The unanswered item may need a design response, an internal review of a posted answer or confirmation that the current response reached the field. Those are different handoffs. Identify the missing decision and the person able to make it before sending another broad reminder.

Start with a stable RFI reference, current version, question and location. Link the source record and describe the specific unresolved point in plain language. “RFI overdue” is a summary; “review whether the uploaded sketch answers the west-corridor clearance question” gives the recipient a recognizable task. Keep any interpretation with the person authorized by the project process.

Download the free RFI decision-log CSV near the top of this page. It provides a blank starting structure without signup. The examples below are invented to demonstrate prioritization and handoffs. They do not supply a design answer, authorize changed work or prove a project's schedule impact.

Keep three dates and clocks distinguishable

Submission age describes elapsed time since the documented submission under your chosen reporting convention. The response due date identifies when a response is expected under the project process. The field required-by date identifies when the responsible team says a decision is needed for a particular activity. Preserve each meaning instead of using one date to answer every question.

Record the source and review basis for the due and required-by dates. A tool's default response interval may help administer a queue, but it does not independently establish the field dependency. Likewise, a foreperson's requested date may need confirmation against the current plan. Keep an unconfirmed request visibly different from a reviewed project commitment.

Publish the snapshot date and age convention beside the report. This guide's example uses calendar days from first submission to October 29, 2026. It does not calculate contractual notice periods or working-day response rules. Your actual project process determines how its own dates are established and reviewed.

Compare a 30-day item with a five-day field dependency

Fictional RFI-14 was submitted September 29, so it is 30 calendar days old at the October 29 snapshot. Its recorded response due date is October 13. The current project review says the finish-identification question is not needed for the relevant activity before November 20. It remains overdue, but the example does not show a current field blocker.

Fictional RFI-31 was submitted October 24, making it five days old. Its recorded response due date is October 28. The superintendent has confirmed that the west-corridor activity needs the unresolved clearance decision before October 30. That documented dependency gives the team a reason to prioritize the younger item without pretending age alone measures schedule risk.

All dates, references and conditions are teaching data. The comparison is not a rule to ignore older RFIs or a claim that RFI-31 lies on a verified critical path. The appropriate project team still needs to assess the actual activity, available alternatives and authorized next step. Use the log to expose that decision and its source.

Find the person who owns the current handoff

Separate the RFI's overall manager from its current next-action owner. An assignee may need to provide a response; afterward, the manager may need to review it or request another person's input. Keep the current responsibility with its source so a reminder does not continue targeting someone who already completed their part.

Procore's published response workflow provides one concrete software example: an assigned response can be submitted through supported channels, and its documented ball-in-court responsibility then shifts to the RFI manager. That describes a particular product workflow. Confirm your project's actual roles and configuration rather than copy its labels as a universal responsibility model.

Include role changes and forwarded questions in the review. A distribution list can retain an old contact after the person has left the project. Ask the manager to confirm the current responsible role and receiving address. Preserve prior responses, but give the next request to someone who can act on the actual remaining question.

Sources: Procore official support: respond to an RFI

Link the question to the work it affects

For every claimed field blocker, identify the area, activity, decision required and source of the dependency. In RFI-31, the record points to the superintendent's confirmed lookahead requirement for the west corridor. That is more useful than a generic red status because another team member can inspect the basis and ask a focused question.

Distinguish a reported impact from a reviewed schedule conclusion. An unanswered question can affect preparation, procurement, access or installation without proving the same consequence in every case. Ask the responsible team to establish what is actually constrained and which decision is needed. Keep unknown consequences visible rather than assigning an invented duration or cost.

If an alternate sequence or temporary arrangement is proposed, route it through the appropriate project review. The tracker can preserve the proposal and resulting decision. It should not make a technical selection or authorize the field to proceed merely to remove an overdue flag. The useful output is a clear, sourced next action under the project's actual authority.

Treat a reported response as evidence to inspect

A reply saying “revised sketch uploaded” can be valuable without resolving the whole RFI. Ask for the current response and attachment reference, then have the designated reviewer assess whether it answers the actual question. Keep the source message connected to the record rather than converting a broad statement into verified acceptance.

Continue RFI-31 with an uploaded sketch that addresses one point but leaves the named clearance question open. The log should record the response received, the outstanding review issue and the person responsible for resolving it. It should not keep calling the entire item unanswered, but it should not mark the decision complete either.

Preserve response and attachment versions. A later revision may change what the reviewer must assess or what the field should receive. Keep the earlier record available under the agreed process and identify which version is current. A clean summary helps only when it points to the actual response the team is expected to use.

Escalate the missing decision with enough context

A useful escalation names the RFI, current question, field required-by date, confirmed dependency and requested action. For the fictional younger item, it might ask the RFI manager to resolve the remaining clearance question before the reviewed October 30 need. Link the current response and the specific review comment so the recipient does not have to reconstruct the packet.

Use the project's agreed escalation path and communication requirements. Keep the requested response date separate from a confirmed commitment by the recipient. If the person proposes another date, record it with the source and ask the responsible project team to assess the effect. A changed date is information to review, not an automatic schedule decision.

Avoid measuring success by reminder count. A successful follow-up should obtain an identifiable response, establish current ownership, supply missing context or document an explicit decision. If repeated reminders produce no change, revisit whether the request is reaching the correct person and whether the underlying question is specific enough to answer.

Verify review and distribution before closing the handoff

When the designated process accepts a response, identify what was accepted, by whom, when and against which version. Then confirm the intended distribution. A reviewed answer still needs to reach the people responsible for the affected work. Keep the receiving or publication reference appropriate to your project system.

Separate the RFI's document status from the field action that follows it. A closed RFI can leave a procurement check, drawing update or work-planning task outstanding. Give those actions their own owners rather than leave them hidden inside a completed RFI row. This also lets the team distinguish response administration from implementation.

Record later corrections openly. If the answer changes after distribution, identify the revised response and who must be informed. Do not quietly replace a file and assume everyone has seen it. The tracker should help the project team find the current instruction and preserve the history needed to understand the handoff.

Use the blank log for a decision-focused review

The blank CSV includes project and RFI identity, the question and location, submission date, response due date, field required-by date and dependency source. It then separates the current owner and blocker from the response reference, review state and field distribution. The final fields identify the next action and last verification.

Keep the source links usable by the authorized people reviewing the item. Add a dated event history or retain snapshots when your process needs to show changes in ownership, dates or response versions. Do not fill an unknown field with a guessed value merely to make the export complete. Give the missing input a person and a requested response.

At a regular review, ask what changed, what decision remains and what the next person can do. Use the 30-day versus five-day example as a prompt to inspect dependencies, not as a permanent scoring formula. A practical queue helps the team identify actionable work without claiming more schedule certainty than its sources support.

Test the follow-up path on one unresolved RFI

Choose a redacted item with a clear source record and a genuine unresolved handoff. Capture the starting dates, current owner, question and dependency before introducing a workflow. This establishes a baseline for judging whether coordination improved rather than confusing an initial data cleanup with a product result.

Buildalytic's custom-workflows offering provides a starting point for discussing reminders, source collection and approval steps around existing project tools. Ask the demo to show the actual missing response or review task reaching the right person. Confirm any proposed system connection and write action explicitly; a follow-up workflow is not automatically an official RFI authoring or design-approval capability.

Bring the source question, current response and field required-by evidence to the demo. Map the path from the observed issue to assigned ownership, reviewed response and verified distribution. Identify the decisions your project team retains, then confirm the implementation scope before using the workflow on additional RFIs.

Sources: Buildalytic custom workflows