Construction RFI software: how to submit, track, and close RFIs without the email chain

A mechanical foreman is standing under a ceiling grid on the third floor with a tape measure in hand. A 24-inch supply duct is about to run straight through the bottom flange of a steel beam. Construction RFI software is built for this moment, but many teams still reach for email, even though it separates the question from the record. The drawings conflict: the architectural reflected ceiling plan shows enough clearance, but the structural sheet doesn't. His crew is scheduled to hang that duct tomorrow morning, and right now they can't.

The fix is the same regardless of trade or clash type: capture the question where the drawing lives, route it to a named owner, and track it to a documented answer. That's what keeps a question from sitting unrouted for days before it even reaches the architect, and it's what gives the team a record it can stand behind if the fix ends up triggering a change order.

The duct clash moves through the same steps every RFI should follow: field capture, routing, tracking, response, closeout, and change order backup. You should be able to submit, track, and resolve the question without losing it in an inbox.

What this article covers:

• A construction RFI turns an ambiguous drawing, spec, or field condition into a documented question the design team is obligated to answer.
• An RFI is a financial record before it's a communication tool: its answer becomes the documented basis for any cost or schedule impact that follows.
• RFIs clarify construction questions, while RFPs and RFQs belong to procurement or pricing workflows.
• The right RFI path runs from the field through the general contractor to the architect or engineer of record.
• Submit an RFI when a design, spec, site, or contract question needs a formal answer before that element can proceed.
• Email splits the RFI from the drawing it references; submit where the plan lives instead.
• A clear status and a plan-anchored view keep every open RFI visible until it's actually resolved.
• The RFI documents the question; a signed change order is what actually authorizes the cost or schedule change.
• Construction RFI software should tie questions to drawings, support mobile crews, and preserve the closeout record.

What is a construction RFI

A construction RFI is a formal request to clarify something ambiguous or missing in the drawings, specs, or field conditions before work can proceed. For our mechanical foreman, that means the duct clash stops being a hallway conversation between crews and becomes a record the design team is on the hook to answer.

That documentation matters. RFIs resolve information gaps by capturing and sharing specific decisions made during a project. So an RFI is both a way to get an answer and a contractual record of the question you raised. Keep the scope tight.

Why RFIs matter (and what a mismanaged one costs you)

Mismanage an RFI and the cost doesn't disappear, it just shows up later, as a change order nobody can substantiate or a rework bill nobody planned for. A documented duct clash resolution protects you when that change order comes due; an undocumented one leaves you exposed. Poor communication contributes to more than $31 billion in avoidable rework costs annually in construction, and an unresolved RFI feeds directly into that pile.

The longer our foreman's duct RFI sits open, the more difficult and costly the correction gets, and the delay becomes something you'll have to prove with documentation.

RFI vs. RFP vs. RFQ: what's the difference

These three are easy to mix up because all three ask someone else for information, but they run on different phases of a job and produce different documents entirely.

RFI (Request for Information): clarifies details that are ambiguous or missing in the drawings and specs. It is used during construction and flows upstream from the field to the design team. The duct clash is a textbook RFI.

RFP (Request for Proposal): a document owners use to solicit detailed proposals from contractors. Those proposals cover approach, pricing, schedule, and qualifications. Used in preconstruction and procurement.

RFQ (Request for Quote or Qualifications): dual meaning. As a request for quote, it's used to get pricing for changes to original scope or unanticipated site conditions, part of the change management process. As a request for qualifications, it's a prequalification step before an RFP.

Who submits RFIs, and who answers them

Getting our duct RFI to the right person on the first try is what keeps it from sitting unrouted for days before the architect ever sees it. In the duct-clash workflow, the RFI starts in the field, gets gated by the general contractor, and is answered by the architect or engineer of record.

General contractors and construction managers

The GC is the central coordinator, and the first job is screening: confirm the answer isn't already in the plans, then review, approve, or reject subcontractor RFIs before anything moves further. If the GC has the answer, they provide it directly; if not, they route it to the design team.

Subcontractors and specialty trades

Subcontractors often originate field-level RFIs, and they submit to the general contractor, not directly to the architect or engineer. Our mechanical foreman doesn't email the structural engineer; he raises the duct clash to his own PM, who routes it to the GC.

Architects and engineers of record

The design team carries the response obligation once an RFI reaches them, and that obligation is timed: the architect's response to RFIs must be made in writing within any agreed time limits, or otherwise with reasonable promptness. For our duct clash, the structural engineer's answer has to confirm the fix doesn't break something else in that ceiling space.

When you need to submit an RFI

Three triggers cover most RFIs: conflicting drawings, missing specs, and site conditions that don't match the plans. Conflicting drawings are a common trigger, like our duct-versus-beam clash or an architectural ceiling plan showing one clearance against a mechanical sheet showing another for the same space. Missing specs are another: a plan shows a wall but doesn't specify the material, wood framing or metal stud. And site conditions often don't match the drawings: excavation turns up a utility nobody mapped, or existing grades and conditions have shifted since the plans were drawn.

How to submit an RFI without starting an email chain

Once you drop the duct clash into an email, the record starts to split. Here's why: one RFI in an email quickly turns into multiple conversations across forwarded threads, attachments get duplicated, and before long nobody's sure which version is official. The RFI also gets separated from the drawing to which it refers, so the office team answering it lacks the field team's visual context. That can produce an answer that reads "see architectural drawings," which is explicitly inadequate.

For a COO running a portfolio of jobs, email and spreadsheets often persist because the team already knows how to survive them. A documented, plan-anchored process pays off once the switch is made.

Capture the question at the source

Log the RFI the moment the foreman spots the clash, right there under the ceiling grid, not back at the trailer that evening. A mobile-first app lets the foreman log the RFI under the ceiling grid. Fieldwire is a mobile-first jobsite management platform built for the people doing the actual work, and its RFI creation and full audit trail let a foreman turn a field task into an RFI with a few clicks and choose to include the photos the crew already captured.

That task-to-RFI conversion is the mechanism that replaces the email chain: the question starts inside the system instead of inside somebody's inbox.

Attach photos, markups, and the plan location

Including a photo of the duct against the beam and markups on the plan to show the exact conflict point provide more context than a paragraph of description. Attaching photos, drawings, or a sketched diagram eliminates confusion about what's actually being asked. In Fieldwire, you pin the RFI to the precise spot on the drawing and add markups, photos, and location-specific notes. When the answer comes back, it comes back anchored to that same pinpoint on the plans.

Assign an owner and a due date

Every RFI needs an assignee and a firm response-needed-by date. Route design and technical questions to the architect or engineer of record on the first try, and set the due date with enough margin that the work isn't already blocked by the time the answer comes back. Keep priority levels honest, too: if everything is marked urgent, nothing actually is.

How to track RFIs from submission to response

Tracking is what turns a submitted RFI into a resolved one instead of a forgotten one. Email has no structural way to do that; a plan-anchored system does.

Check the RFI status: open, pending, answered, closed

A well-defined status tells everyone on the project where the RFI stands at a glance. Some teams call the response step "answered"; in Fieldwire, that answer moves the RFI into Pending until the creator accepts or rejects it. Fieldwire uses a straightforward workflow: "Open" while it is with the assignee, “Pending” once an answer is provided and it's reassigned to the creator to accept or reject, “Closed” when the submitter confirms a sufficient answer, and “Void” if it's no longer applicable.

Don't close an RFI on an incomplete answer. Flag it pending instead, and name exactly what's still unresolved, because closing it creates a paper trail that looks resolved when it isn't, a gap that has a way of resurfacing during a claims review.

Filter and monitor with dashboards

When you're running eight jobsites with hundreds of open RFIs, you need to see which ones are blocking work right now. Fieldwire's RFI list view shows Assignee and Last updated columns, and RFI dashboards use color-coded statuses so you can spot overdue items quickly. For a PM protecting accountability, filtering by assignee and last-updated is how you answer "who's sitting on what" without chasing anyone down. This visibility keeps the duct RFI tied to the third floor, not floating in a spreadsheet row.

Set reminders before responses go overdue

Overdue reminders keep responses visible after the due date. In Fieldwire, every team member is notified when they're tagged in an RFI, which cuts the follow-up chasing and removes the human error of forgetting who owes what. Keep RFIs, submittals, and change orders connected so the documentation trail stays intact when this RFI moves toward a change.

Closing an RFI and connecting it to a change order

Closing the duct RFI is where its answer formally becomes the basis for a cost adjustment, if the fix changes scope. The structural engineer responds: drop the ceiling two inches in that bay and reroute the duct below the beam. That answer makes the fix buildable, but it doesn't yet authorize anyone to bill or schedule against it.

Teams often confuse an RFI response with work authorization. Submit the RFI, receive the answer, then submit and obtain a signed change order if scope changes before proceeding. Wait for the signed change order before performing extra work. The RFI documents the question; the change order authorizes the money.

Use the RFI as evidence that you identified the problem and sought direction before proceeding, and as the starting point for the change order. When an RFI response modifies contract scope, the contractor uses it as the basis for a change order request. When the formal change order gets prepared, it lists its supporting attachments, which include the originating RFI and its response, the plan location, photos, markups, submitted date, due date, answer date, and the resulting cost or schedule impact. Poorly documented change orders with weak backup can make costs hard to justify and lead to payment issues.

Keep RFIs, submittals, and change orders in one connected system. In Fieldwire, tasks link directly to change orders, so the full scope of the change traces back to the exact field condition that started it.

When you can show exactly when you submitted the RFI, when it was due, and when the answer landed, you have the documentation to back a change order request instead of arguing over it.

What to look for in construction RFI software

Five criteria separate software that actually gets used from a system crews route around: plan linking, offline access, audit trails, a connection to submittals and change orders, and evidence that field crews will actually open it.

• Plan and drawing linking: pins RFIs to the exact spot on the drawing.
• Mobile and offline access: Fieldwire's core features work offline and sync automatically on reconnect.
• Audit trails: timestamped and producible in a dispute.
• Connection to submittals and change orders: the RFI's documentation carries forward into the change order it triggers.
• Field crew adoption: Fieldwire is built for the field, with teams typically productive within days rather than weeks.

Fieldwire keeps RFIs, submittals, and change orders anchored to the plan and the field crew that raised them, rather than living only in a back-office system the crew never opens.

Get those pieces right and the duct clash stays a documented, defensible record from the field to the change order, instead of a disconnected email thread.