Project Management
How to Write an RFI That Gets Answered Fast
An RFI is supposed to unblock the field, but a badly written one does the opposite. It bounces back with a question, sits unanswered because nobody understands what you are asking, or gets a reply too late to matter. The difference between an RFI that stalls and one that moves is rarely the question itself. It is how completely you framed it and how clearly you signaled what you need and when. Here is how to write the kind that gets answered fast.
Published June 28, 2026 · 6 min read
Key takeaway
A strong RFI asks one specific question, cites the exact spec section or drawing, proposes your recommended answer, states the cost and schedule impact, and gives a realistic need-by date so the reviewer knows precisely what to decide and when.
Why vague RFIs stall
Most RFIs that languish do so because the reviewer cannot tell exactly what is being asked or cannot answer without doing the legwork themselves. An architect facing a stack of RFIs answers the clear ones first and sets the vague ones aside, where they age.
Every round trip of clarification costs days. If your RFI forces the reviewer to ask what you mean, hunt for the drawing, or guess at the impact, you have added a full cycle of delay before anyone has even tried to answer the real question. Front-load that work yourself and the answer comes back in one pass.
The anatomy of a good RFI
Treat the RFI as a complete package the reviewer can act on without leaving the document. Each element removes a reason to stall.
- •One specific question, not three loosely related ones bundled together
- •The exact reference: spec section, detail number, drawing sheet, and revision
- •A clear description of the conflict or gap, with a photo or markup if it helps
- •Your proposed solution, so the reviewer can approve rather than invent an answer
- •The cost and schedule impact, flagged honestly even if you do not yet have a number
- •A realistic need-by date tied to when the field actually needs the answer
Propose the answer, do not just ask
The single highest-leverage move in RFI writing is proposing a solution. When you write what you found, why it is a problem, and what you recommend, you turn an open question into a yes-or-no decision. Reviewers approve a clear recommendation far faster than they author one from scratch.
It also protects you. A documented proposed solution shows you flagged the issue and offered a fix, which matters if the answer comes back late or wrong and you need to show you did your part. Just make sure your proposal is reasonable and within scope, not a quiet attempt to push extra cost onto the owner.
Set a need-by date that means something
A need-by date is only useful if it reflects the real field sequence. Padding every RFI with an artificially urgent date trains reviewers to ignore your deadlines, the same way a foreman who cries emergency on routine work gets tuned out.
Tie the date to the look-ahead schedule: when does the crew actually reach this work? Give the reviewer enough lead time to respond, and when a date is genuinely critical because a pour or a delivery hinges on it, say so explicitly. A credible deadline backed by a real schedule reason gets respected.
Track ball-in-court and the link to change orders
An RFI log should always show whose court the ball is in and how long it has sat there. Ball-in-court tracking is what lets you say, with dates, that an answer is the reason the field is stalled, which is the foundation of any delay or impact claim later.
Many RFIs surface a condition that is not in your contract, which means the answer can trigger a change order. Linking the RFI to the potential change order from the moment you write it preserves the trail from question to cost. In Field PM, RFIs and change orders live in the same workflow, so an RFI that exposes extra work flows straight into a priced change order with the ball-in-court history attached, and nothing falls through the cracks between the question and the bill.
Frequently asked questions
Should I propose a solution in my RFI?+
Yes, whenever you reasonably can. Proposing a solution converts an open-ended question into a yes-or-no decision, which reviewers answer far faster. It also documents that you identified the issue and offered a fix, which protects you if the response comes back late or incorrect.
What does ball-in-court mean?+
Ball-in-court identifies who currently holds responsibility to act on an RFI: you, the GC, or the architect or engineer. Tracking it with dates shows exactly how long a request has sat with each party, which is essential evidence if you later need to demonstrate that a late answer delayed the work.
How do RFIs lead to change orders?+
Many RFIs uncover conditions that differ from the contract documents, such as a conflict between drawings or a missing detail. When the answer directs work that is outside your original scope, it becomes the basis for a change order. Linking the RFI to the change order from the start preserves the trail from question to added cost.
How long should I give for an RFI response?+
Tie the need-by date to your actual field schedule and give the reviewer reasonable lead time, often a week or more for non-urgent items, with the exact window often set by the contract. Reserve genuinely tight deadlines for work that truly hinges on the answer, and explain why, so your urgent flags keep their meaning.
Run the numbers in the field, not the spreadsheet
Field PM turns daily reports into live job costing, productivity, and billing — built for self-perform contractors. 30-day free trial · no credit card · unlimited foremen, QA/QC, safety & subs always free.
Start free trial →