An effective construction RFI follow-up workflow prevents unanswered design questions from disappearing into email while the affected trade waits for direction. The key is to track the formal request for information (RFI), the person authorised to respond, the next construction activity at risk and the earliest date that an answer becomes critical. A scheduled status call can gather facts and surface overdue decisions. It cannot issue a design instruction or stand in for the approved RFI process.

In construction, an RFI is a controlled request to clarify documents, specifications or site conditions. The formal answer belongs in the project’s designated document-control process. Autodesk’s RFI workflow guidance describes submission, review, response and closure as distinct steps. The practical problem is often the time between those steps: the coordinator knows the question was submitted, but the foreman does not know whether tomorrow’s work can proceed.

Three separate RFI statuses: submitted, in review and response issued, with a formal response required before the trade proceeds

Begin with the trade dependency, not the unanswered email

A report saying “RFI outstanding” is incomplete. Ask what work depends on it. A mechanical subcontractor may need a confirmed ceiling detail before setting supports; an electrical contractor may need the approved equipment location before pulling cables. Record the activity, the planned start, the latest useful answer date and the party who is allowed to make the decision. This converts an administrative queue into a schedule-risk view.

Distinguish four dates: when the RFI was submitted, when the contractual response is due, when the dependent trade needs the answer and when the affected work is scheduled. These dates are not automatically identical. The project manager should agree the response timeline and priority with the contractual parties rather than changing promised dates based on an AI-generated summary.

For a practical starting point, group RFIs as informational, near-term dependency or stop-work dependency. This is a suggested operating classification, not an official RFI status system. Escalation should depend on actual impact and contractual obligations, rather than sending the same reminder to every recipient.

Identify who can answer, coordinate and act

A subcontractor can describe the problem. A general contractor’s coordinator can confirm whether it is complete and assigned. An architect, engineer or other contractually designated reviewer may be responsible for the technical response. The owner or contractor may need to authorise commercial or programme consequences. Each role should have a separate field so that a call to the submitter is never treated as permission to change the design.

The RFI’s official record should contain the controlling drawing or specification reference, the exact question, attachments, reviewer, status, answer and issue date. Keep that record authoritative. A monday.com follow-up board can be used as an operational layer, but it should link back to the RFI’s controlled reference rather than create a second competing design answer.

If a reviewer says the answer is being prepared, log reported in preparation and the expected next review date. If the reviewer says another discipline must comment, record the missing reviewer and route the item accordingly. A phone conversation is evidence of a communication, not a substitute for the issued response.

Recommended monday.com board structure

The following is a suggested configuration for a project using monday.com, not a claim that these columns are an installed Autoza default:

  • RFI reference / source link: A unique identifier that opens the controlled RFI record.
  • Affected activity / trade: The task that cannot start or finish without clarification.
  • Responsible reviewer: The person or organisation authorised to issue the next response.
  • Needed-by date: When the field team needs reliable written direction.
  • Reported progress: Awaiting review, review underway, clarification needed or response issued, with reporting source.
  • Evidence / response link: The actual issued document, not a paraphrase of a call.
  • Escalation owner: The project lead who decides whether to resequence work.

For connected schedule tasks, monday.com’s dependency functionality can represent predecessor relationships where available on the account’s plan. Do not assume a date will move just because a caller reports a delay: scheduling mode, contract notices and programme changes require explicit review.

Ask status questions that do not become design questions

A short, well-scoped call could ask: “I’m following up on RFI 248 relating to the east-wing ceiling detail. Are you the current response coordinator?” Then: “Has the request been accepted for review?”, “Is any drawing or site photograph missing?”, “Who is the next named reviewer?”, “When can the team expect a formal written response?”, and “Should the construction manager be alerted about an affected start date?”

Avoid asking the AI caller to choose between technical solutions, approve an alternative material or tell a crew it is safe to proceed. If the recipient gives a possible technical answer verbally, store it as unverified reported information and refer it to the authorised reviewer. The model script should introduce the caller appropriately and follow the organisation’s consent, disclosure and calling-hour rules.

Set a meaningful call cadence rather than a fixed “daily chase”. A routine clarification with no upcoming activity might receive a scheduled check near its expected review date. An RFI affecting tomorrow’s work may require direct human coordination today; an automated call cannot replace that escalation.

Handle exceptions with an explicit human route

The most important rules address uncertainty. A non-answer should remain “not reached”; a voicemail must not become “reviewer agreed”; and “we should have it tomorrow” must not become “approved”. An ambiguous response should be reviewed rather than written to a formal approval field. If an updated drawing is claimed, ask for its reference and leave the item awaiting documentary evidence until checked.

A useful exception path is: call attempt → reported status → document check → named decision owner → authorised action. The project manager can decide whether to resequence an unaffected area, request an urgent design coordination meeting or initiate the contract’s notice process. Only the responsible professional issues the answer within the formal RFI channel.

The construction check-in milestone questions guide explains how to connect status questions to field readiness. When building that process, keep site-safety decisions and formal approvals separate from task follow-up.

Measure whether follow-up reduces actual waiting

Track median time from submission to formally issued answer, RFIs whose needed-by date passed, percentage with a named reviewer, and affected activities where an accepted workaround was documented. Also track calls that added useful information versus those that repeated the same status. These measures help change the workflow rather than simply increase contact volume.

For a pilot, select a small set of active RFIs with clear reviewers and site dependencies. Record outcomes for two reporting cycles, refine the questions and let the site team reject unhelpful calls. Autoza’s monday.com check-in product information is a starting point for discussing scheduled follow-up; confirm actual field mappings, available calling controls and integration permissions during a product walkthrough.

Frequently asked questions

When should a construction RFI trigger a status call?

When the next approved response date is close, a required attachment is missing or an upcoming trade activity depends on the answer. Prioritise by impact on work rather than automatically calling every RFI every morning. Time-critical safety or stop-work concerns should go straight to the authorised human lead.

Who is authorised to answer an RFI?

The person or organisation designated in the project contract and RFI procedure, often an architect, engineer or appointed reviewer. A coordinator may report that the answer is pending, but that is not the same as issuing binding design clarification or approving a contractual change.

How do you flag a trade dependency without changing the design?

Link the RFI reference to the affected scheduled task and record the need-by date, current reported status and decision owner. Mark the task as awaiting an authorised response and escalate the schedule exposure. Do not populate an approval field from an unverified conversation.

Can an AI caller close an RFI after a verbal reply?

It should not close the formal RFI solely because someone says the question is resolved. Closure should follow the agreed document-control process and the issued response should be available to the relevant team. A call may help locate that response and prompt verification.

How can teams reduce unnecessary RFI follow-up calls?

Separate routine requests from imminent trade blockers, use an agreed next-contact date, avoid calling recipients who cannot act, and pause routine reminders once the final issued response is linked. Review call outcomes with the project team so the cadence stays useful.

Related reading