Ask your projects data anything. Get answers in seconds. Plexa MCP Connector is live. See it in action
FREE TOOL
RFI generator and response deadline calculator
Produce a structured request for information with drawing references, cost and time impact flags and a required-by date, and work out when the response is due under your contract.
An RFI asks a question. It seeks information you need to build, a clarification, a resolution of a conflict between documents, a decision that is not yours to make.
A variation claim asks for money. If the answer to your RFI changes the scope, that is a variation, and it needs to be claimed as one under the contract mechanism.
An EOT notice preserves time. If waiting for the answer delays practical completion, the notice period is running from when you became aware, not from when the answer eventually arrives. People lose entitlements by assuming the RFI covered it.
What an RFI is really doing
On the surface an RFI asks a question about the documents. Underneath, it is doing two other jobs that matter more: it puts the other side on notice that something is unresolved, and it creates a dated record of when you asked.
That second function is why RFIs turn up in delay claims. The gap between when a question was asked and when it was answered is evidence, and it is only evidence if the question was asked in writing with a date on it.
An RFI raised late, or raised verbally and confirmed never, gives away that evidence entirely.
Why the cost and time impact flags matter
Most RFIs are neutral. Some are not, and the difference should be visible on the face of the document rather than discovered when the answer arrives.
Flagging that a question has cost or time consequences changes how it is treated at the other end. It moves the RFI from a queue to a decision, and it makes it much harder for the answer to arrive three weeks later accompanied by surprise that anything was affected.
It also starts the paper trail properly. If the answer does cause delay or additional cost, the RFI that said so up front is a far stronger starting point than one that asked a neutral-sounding question about a detail.
The required-by date is not a courtesy
An RFI without a required-by date is a question with no deadline, and questions with no deadline get answered last.
The date should be derived from the programme (when does the answer have to be in hand for the work to proceed without disruption), and it should account for the lead time on whatever the answer triggers. An answer that arrives the day before a pour is useless if the reinforcement needs a week.
Where the contract specifies a response period, the calculator works it out on the correct day-counting basis. Where it does not, the required-by date is your assertion, and asserting it clearly is still much better than leaving it out.
Keep the register, not just the RFIs
Individual RFIs are useful. The register is what wins arguments, because it shows the pattern: how many questions were raised, how long answers took on average, and which ones are still open.
A consultant averaging three weeks against a contractual seven days is a documented problem. The same fact spread across forty separate emails is an impression.
Number them sequentially, keep the closed ones, and record the date the answer arrived rather than the date it was filed. The gap between those two is not evidence of anything except your own admin.
The AI Construction Operating System
One platform, one data model, every project. Built in Australia, for the world.
YOUR DATA, PROTECTED
Hosted on AWS Sydney with Australian data residency.
GET THE MOBILE APP
Platform
Solutions
© 2026 Plexa Pro Pty Ltd. ABN 63 668 433 136