The RFI — Request for Information — is the workflow that determines whether questions raised in the field get clean answers in time to keep work moving, or whether they pile up in email inboxes until the schedule slips. RFI cycle time and resolution rate are two of the most consequential metrics on every commercial project, and most of the time they're not measured because nobody owns the log. This is a working guide for mid-market subs and GCs on RFI management — the lifecycle, the SLA mechanics, the recurring failure modes, the RFI-to-CO promotion path, and how AOS handles RFIs cross-tenant.
If you've ever sent the same RFI three times because the architect "didn't see it," or had a CO dispute over scope that should have been clarified by a never-answered RFI from week 4, you know the cost of bad RFI management. This post is for the sub PMs and GC PMs who live in the RFI log and want it to actually work.
What an RFI actually is
An RFI is a formal written request from a contractor (typically the sub or the GC) to the architect, engineer, or owner asking for clarification, interpretation, or additional information about the contract documents. The architect's response becomes part of the project record and can have contract-level implications — an RFI that requires extra work the contractor wasn't expecting can trigger a change order (more on the RFI-to-CO promotion path below).
RFIs are distinct from submittals (which propose specific products for approval — covered in our submittal management guide) and from change orders (which formally modify the contract — covered in our change-order patterns post). The RFI asks "what does this mean"; the submittal says "here's what I propose to install"; the CO says "here's a formal change to the contract."
The RFI lifecycle
Every RFI goes through roughly this lifecycle:
- Field identifies a question. A foreman, sub PM, or GC PM encounters something on the drawings, specs, or in the field that needs clarification.
- Originator drafts the RFI. The sub PM or GC PM writes up the question with reference to the relevant drawing, spec section, or RFI from another trade. Good RFIs include a proposed answer ("we propose to install per Detail 4/A-301, please confirm") — better RFIs prompt faster responses.
- Routing. If the sub originates the RFI, it routes to the GC's PM first, who reviews, sometimes annotates, and forwards to the architect or engineer. If the GC originates, it goes directly to the architect.
- Architect review. Architect interprets the documents and responds. For engineering questions, the architect may forward to the relevant engineer-of-record (structural, MEP, civil). Standard SLA is 5-10 working days per contract; design-build contracts often have tighter SLAs.
- Response routes back. Architect's response goes to the GC, who forwards to the originating sub (if applicable).
- Cost / schedule impact assessment. The originating contractor reviews the response. If the response requires work outside the original contract scope, the contractor flags it as a potential CO trigger.
- Closure. RFI is marked closed. The response becomes part of the project record and is referenced going forward.
That's a 7-step lifecycle. The most consequential metric is total cycle time from "Field identifies a question" to "Closure" — on most commercial projects this should average 7-12 working days. Anything beyond 14 days starts to materially affect schedule.
The recurring RFI failure modes
1. RFI buried in email instead of logged formally. The sub PM emails the GC PM with a question. The GC PM forwards to the architect. The architect responds via email. Nothing gets logged in any formal system. Six months later, when a CO dispute arises citing the unresolved question, nobody can prove it was asked.
2. No SLA tracking, no breach alerts. The architect has 10 working days per contract. They take 25. By the time the GC's PM notices, the schedule has slipped a week. With no breach tracking, there's no documented basis to attribute the slip to architect delay.
3. RFI marked closed before the response is actually applied. Architect responds; GC marks the RFI closed; the sub never received the response or didn't read it carefully. Six weeks later, the work is built per the original (now-superseded) interpretation, and rework is required.
4. Cost and schedule impact deferred. The architect's response expands scope. The contractor performs the additional work without flagging it as a CO trigger. At closeout, the contractor tries to bill the additional work as a CO; the GC and owner push back; the contractor absorbs the cost. (This is the most common silent margin loss in commercial construction.)
5. RFI volume that nobody manages. A typical mid-sized commercial project generates 100-300 RFIs over its life. Without an active triage process, the architect prioritizes whatever is loudest. Critical-path RFIs sit while non-critical ones get answered first. The PM who isn't tracking criticality has no leverage to push.
6. Duplicate or near-duplicate RFIs. Two subs ask the same question independently because neither knows the other's RFI exists. The architect answers twice, sometimes with subtle differences that create their own disputes.
7. RFI responses that don't reference the original RFI. The architect responds to RFI #047 with "see Sketch SK-12" but doesn't reference RFI #047 in the SK-12 distribution. Recipients have to manually link the response back to the question. Easy to lose.
What good RFI management looks like
The principles:
One central RFI log per project, shared across the sub, the GC, and the architect. Every RFI is a record with a state: drafted, submitted, in GC review, with architect, returned, closed. All three parties see the same log; the SLA clock is visible to everyone.
SLA tracking with active breach alerts. Each RFI carries its review SLA per the contract (typically 5-10 working days). The platform tracks days-in-review per party and alerts before SLA breach, not after.
Criticality tracking. The originator (with GC PM agreement) flags critical-path RFIs distinctly from non-critical ones. The architect's response queue should surface critical RFIs first; SLA breach alerts on critical RFIs escalate to project leadership, not just the PM.
Cost and schedule impact captured at response time. When the response arrives, the contractor reviews and flags any cost or schedule impact within a configured window (typically 5-7 days). Flagged impacts trigger the CO conversation while the work is still being planned, not after.
Duplicate-RFI detection. Before a new RFI is submitted, the platform should surface similar RFIs already in the log so the originator can either reference the existing one or sharpen the new question.
Response-to-question linking. Architect's response is permanently linked to the originating RFI record. Distribution of the response automatically references the RFI number; no email reconciliation needed.
RFI-to-CO promotion is one click. When a response expands scope, the contractor can promote the RFI to a CO record with one action. The CO inherits the scope description, the response text, and the related drawings; no retyping.
The RFI-to-CO promotion path
The most consequential workflow connected to RFI management is the RFI-to-CO promotion. This is where silent margin erosion happens at scale.
The pattern: a sub raises an RFI about a field condition or a design ambiguity. The architect's response provides clarification that expands the sub's scope. The sub does the additional work because the schedule can't wait. Months later, the sub bills the work as a CO. The GC pushes back: "we don't have a CO log entry for this." The owner pushes back: "we never approved this scope addition." The sub eats the cost.
The fix is to promote the RFI to a CO record at the moment the scope-expanding response arrives. The CO enters its lifecycle (notice → quantification → submission → negotiation → approval) immediately, with the RFI as the originating reference. The sub does the additional work with a CO in flight; the GC and owner are in the loop; the margin doesn't quietly disappear.
For more on the CO side of this, see our change-order patterns post — the "design clarification" pattern is the most disputed CO type, and almost all design-clarification COs trace back to an RFI that should have been promoted at response time.
How AOS handles RFI management cross-tenant
In AOS, the RFI log is a first-class object with state, SLA tracking, and cross-tenant visibility across the sub, GC, and architect. Specifically:
- One RFI log per project, shared across all parties. The sub creates an RFI; the GC PM reviews and routes; the architect (if on AOS) sees it in their queue; everyone sees the same state and SLA clock.
- SLA tracking with breach alerts. Each RFI carries its contractual SLA; breach alerts fire at 50%, 80%, and at the breach threshold.
- Criticality flagging. Originator marks critical-path RFIs; the architect's queue surfaces critical ones first; breach on a critical RFI escalates to project leadership.
- Cost / schedule impact prompt at response time. When the response arrives, the originating party is prompted to flag cost or schedule impact within a configured window.
- Duplicate detection. When drafting a new RFI, the platform surfaces similar open or recently-closed RFIs on the project.
- Response permanently linked. Architect's response attaches to the RFI record. Any subsequent reference to the response (in submittals, COs, drawings) carries the RFI number.
- One-click RFI-to-CO promotion. When a response expands scope, the contractor promotes the RFI to a CO with one action. The new CO inherits scope description, response text, related drawings, and an audit-trail link back to the originating RFI.
- Cross-tenant when both sides are on AOS. The sub's RFI lands directly in the GC's RFI queue (no document upload); the architect (if on AOS) sees it routed to them; status updates flow back to the sub in real time.
The sub PM role page covers the sub-side workflow; the GC PM role page covers the routing side; the A/E contract admin role page covers the architect-side response workflow. For the broader strategic story on what changes when all three parties share a record, see the both-sides-on-one-record post.
The RFI management readiness checklist
- Is there one RFI log per project shared across the sub, GC, and architect, or does each party maintain their own?
- Are SLA breach alerts firing before breaches happen, or only after?
- Is criticality tracked, with critical RFIs surfaced ahead of non-critical ones in the architect's queue?
- When a response expands scope, does someone flag it as a CO trigger within a few days, or does it sit until closeout?
- Is duplicate-RFI detection happening, or do you find out at closeout that the same question was answered three times?
- Can you produce, in seconds, the full audit trail of any RFI — including all routing steps, all responses, and any CO promotion?
If most answers are "informally, with workarounds," that's the workflow a connected platform closes.
If you'd like to see it
We're in private-beta design-partner mode for commercial subs and GCs. If you'd like to walk through how AOS handles the RFI log on a real project — particularly one with substantial RFI volume or active SLA pressure — apply to the beta. The subcontractor overview and GC overview walk through the platform broadly.