An RFI is not administrative correspondence — it is a piece of work paused pending a decision. Every day without a response is a day a scheduled activity makes no progress while site costs run unchanged. Yet most firms treat RFIs like outbound mail: send, then wait. This guide is about treating them as a contractual obligation with a defined deadline, and about what you do when that deadline passes.
Key takeaways
- A badly written request is the number-one cause of slow response — an open question invites a meeting, a specific one invites a signature.
- The contractual response deadline should be computed and displayed on every request, not remembered.
- A request linked to a BOQ item or a schedule activity makes the cost of the delay expressible as a number.
- Submittals need an internal review cycle before they go out — most rejections are internal omissions, not technical disagreements.
- A complete log of overdue items is the strongest document you hold when extension of time is discussed.
What an RFI actually is
A Request for Information is a formal question from the contractor to the consultant or employer about an ambiguity, a conflict or a gap in the contract documents. Its usual cause is not ignorance of how to build something — it is drawings conflicting with specifications, a detail that does not exist, or a site condition the design did not anticipate.
The substantive difference between an RFI and any other letter is that it halts work. When you raise an RFI about reinforcement detailing at a beam intersection, the crew cannot pour that zone until the answer arrives. That is why RFIs are measured by response time, not by count.
Writing the request: the main cause of a long wait
A consultant receiving thirty RFIs a week answers first the ones they can answer immediately. The one that requires opening three files and consulting another discipline moves to the bottom of the pile — not out of obstruction, but as a natural ordering of effort.
| Phrasing that slows the response | Phrasing that speeds it up |
|---|---|
| There is a conflict in the rebar details, please advise | Drawing S-204 shows top reinforcement Ø16@150 at grid C/4, while specification 03-2100 requires Ø16@100 for perimeter beams. Which governs? |
| What type of roof waterproofing is required? | The specification states “SBS membrane to spec” without a thickness. We propose 4 mm in two layers — please confirm or nominate the alternative. |
| We need clarification on the facade | Detail A-501/3 does not show the junction treatment where cladding meets stone at level +12.40. Our proposed treatment is attached — please approve or amend. |
- Cite drawing number, revision, and grid or level — not “on the second floor”.
- Propose an answer. A request carrying a proposal becomes a one-minute “approved”.
- Link the request to the affected schedule activity and state the date you need the response by.
- Attach the site photo or the drawing clip — do not make the reader go find it.
- One question per request. A request carrying four questions gets two answered and the rest forgotten.
Tracking the clock: from remembering to measuring
Most contracts set a response period for RFIs — seven days, fourteen days, or “a reasonable time”. The problem is that this period lives in the document controller’s head, and when they get busy or leave the company it goes with them.
Compute the due date automatically on issue
Issue date + contractual period = due date, computed and shown on the request itself. Do not rely on manual follow-up.
Use exactly three time states
Within period, approaching due, overdue. Any finer classification goes unused in practice.
Review overdue items in a fixed weekly meeting
One list, sorted by days overdue descending. The meeting does not debate technical content — it asks who is chasing and by when.
Escalate formally once the period lapses
A documented reminder citing the request number, issue date, contractual period and affected activity. Early, courteous escalation beats a late claim by a wide margin.
Submittals: a different cycle, a different problem
A submittal is not a question but a proposal for approval: a material sample, a shop drawing, a product data sheet. The substantive difference is that an RFI waits for information whereas a submittal waits for an accept/reject decision — and the reject is usually caused internally.
Look at your last ten rejected submittals and most will have failed not on technical disagreement but on omission: a catalogue with no compliance certificate, a shop drawing at a superseded revision, a sample without test data.
An internal review cycle before issue
- Check attachment completeness against the specification’s list — not against memory.
- Match the revision against the latest issued drawing, not the copy sitting in the site folder.
- Internal technical review by the discipline engineer before the document leaves the company.
- Set the real need-by date from procurement lead time, not from the installation date.
That last point is the most neglected. A submittal for a material with a twelve-week lead time has to go out three months before its installation date in the programme — not two weeks before. The submittal register should be built by counting backwards from installation dates.
| Stage | Typical duration |
|---|---|
| Installation date in the programme | The reference point |
| − Procurement and shipping lead time | 4 – 12 weeks |
| − Fabrication after approval | 2 – 6 weeks |
| − Consultant review period | 1 – 3 weeks |
| − Allowance for one resubmission cycle | 1 – 2 weeks |
| = Latest date to issue the submittal | Sum the above and subtract |
From delay to evidence
When a project reaches an extension-of-time discussion, the RFI and submittal registers stop being operational tools and become contractual documents. A firm with a complete log enters that discussion with numbers; a firm relying on email enters it with recollection.
- Issue date and response date per item — timestamped in a way that cannot be edited retroactively.
- Contractual period vs actual elapsed time, per item and averaged across the project.
- The affected activity and how long it was held, tied to the approved programme.
- The full correspondence chain including reminders — not a selected extract.
The difference between an accepted claim and a rejected one is rarely the strength of the argument. It is usually the completeness of the record behind it.
What this looks like in muqawil
The RFI and submittal modules in muqawil follow the model above: every request carries its issue date, its computed due date and its state, and every submittal passes an internal review cycle before it is issued.
- Automatic sequential numbering per project for both RFIs and submittals.
- Responses are recorded inside the request itself, keeping the whole thread in one place.
- Attachments (site photos, drawing clips) are stored with the request, not in a separate mailbox.
- Every state change is written to the append-only audit log.
- A bilingual interface, so correspondence with an English-working consultant and an Arabic-working site team runs on the same record.
Frequently asked questions
What is the difference between an RFI and a submittal?
An RFI is a question about an ambiguity or conflict in the contract documents; its output is information or a design decision. A submittal offers a material, shop drawing or sample for approval before procurement or installation; its output is approved, rejected, or approved-as-noted.
How many RFIs are normal on a project?
There is no benchmark number, because it depends on design completeness far more than on the contractor. A high count against an incomplete design is expected and healthy. What matters more than the count is the average response time and the proportion of items exceeding the contractual period.
What do we do if the consultant consistently exceeds the response period?
Document it in numbers first: how many items are overdue, the average overrun in days, and the activities affected. Then escalate in writing, citing the contractual period and requesting a response schedule. Escalation backed by a documented register usually resolves the problem well before it becomes a formal claim.
Should we raise an RFI for every small ambiguity?
No. An ambiguity you can settle with an internal technical decision within your own scope of responsibility does not need one. RFIs are for what falls outside your design responsibility or what could be disputed later. The practical test: if the outcome went wrong and you were asked “why did you build it that way?”, do you have a documented answer?
How do we start if we only use email today?
Start with sequential numbering and a single register holding: number, subject, issue date, due date, state, affected activity. That register alone — even in a spreadsheet — gives you the ability to escalate with numbers, which is the largest single gain in the transition.
Close the loop in one place
Run RFIs and submittals in muqawil: automatic numbering, computed due dates, and a complete audit trail in Arabic and English.