You are standing over a drawing set and it does not work. The detail cannot physically be installed the way it is drawn, or two sheets are telling you different things. What you send at that moment is an RFI — a Request for Information.
The name makes it sound like a question. That framing is why a lot of people handle RFIs badly.
On a large project I worked on, we issued RFIs in the hundreds. Put the RFI log and the change order log side by side and a large share of them are the front and back end of the same event.
An RFI is not a question. It is the first record of money and time starting to move. This guide treats it that way.
An RFI Is a Record, Not a Question
An RFI does three things.
It records who asked what, and when. It records who answered, what they said, and when. And it becomes the evidence for deciding later whether that answer fell inside or outside the contract scope.
The third one is what matters. When someone asks after the fact why the work was built that way, or tells you there is no additional money for it, the RFI log is what you open. A verbal instruction carries nothing in that room. This is why “the coordinator told us to do it” does not survive. People rotate off projects and memories diverge, but a numbered record stays.
So writing a good RFI is not about asking a clever question. It is about producing a record that still explains itself when someone pulls it up a year later.
Most RFIs Come from the Gap Between Design and Construction
Does a high RFI count mean the design was bad? Not necessarily.
A designer draws what gets built. A builder looks at the sequence, the equipment, and the tolerances that get it built. Those two views overlap but are not the same. A detail that is complete on paper often fails on site purely because of installation order. Whether the wall or the duct goes first is not something the drawings say.
RFI volume swings enormously between projects depending on design maturity, delivery model, and schedule pressure. There is no “normal” number. What is fair to say is that projects with runaway RFI counts are usually projects that broke ground on an unfinished design.
Who Actually Issues RFIs — It Is Not Only the Trades
This is the most common misunderstanding.
The usual path is that a trade contractor raises a question during their own review. But in practice the GC issues plenty of RFIs directly. When the GC reviews the design for constructability, finds a problem, confirms it with the relevant trade, and then submits under its own name. Coordination clashes across multiple trades are invisible to any single trade — if the GC does not catch them, nobody does.
Hold on to this distinction. When the GC issues an RFI directly, the answer comes back to the GC, and the trade may never learn it exists. Rework starts there, and we will come back to it.
When a trade raises one, the GC’s PM or PC screens it first. Things get filtered at this stage: questions already answered in an earlier RFI, questions from someone who did not read the current drawing revision, questions already answered in the specification. If site conditions are involved, the superintendent confirms. Pushing unscreened RFIs upstream clogs the channel and pushes the answers you actually need further back in the queue.
Where the RFI Goes Depends on the Delivery Model
| Delivery model | Who receives the RFI |
|---|---|
| Design-Build | In-house design coordinator, or the contracted consultant |
| CM | The owner, or the owner’s consultant |
Under Design-Build the design liability sits on the contractor side, so the answer is produced internally. Under CM the design sits with the owner, so the question goes outside. The same RFI can take days or weeks depending on which side of that line it lands.
The contract structures behind this are covered in Types of Construction Contracts in Canada and What Is a General Contractor.
Why the Architect Answers Everything — BC’s Letters of Assurance
Here is something specific to British Columbia.
Raise an RFI about structural, mechanical, or electrical scope and the answer often still routes back through the architect. The first time you see it you wonder why an architect is answering an electrical question.
The BC Building Code requires a Coordinating Registered Professional (CRP) on the project, and the architect normally holds that role. The CRP signs Schedule A at permit stage while each discipline files its own Schedule B. When construction is finished and field reviews are complete, the CRP signs Schedule C-A confirming the building substantially complies with the code.
The CRP is the one whose name ends up on that document. So during construction it is the CRP — or the consultant firm the CRP works in — who should be collecting the discipline responses and issuing one coordinated answer. When disciplines answer separately you get answers that contradict each other, and the field absorbs the contradiction.
The permit and inspection framework is covered in BC Building Permit: Inspections and Occupancy.
Use the System, Not Email
You can run RFIs by email. Some sites do. I strongly prefer a system like Procore, for two reasons.
Email is not traceable. Threads fork, people drop off the cc line, and attachments end up in a message nobody can find. Six months later, answering “what did they actually say” starts with a search.
Email does not hand over. This is the bigger one. When someone new joins mid-project, they have no way to see the earlier RFIs — those live in somebody else’s inbox. In a system they log in and read the whole record from RFI 001. On projects with staff turnover, this difference decides how much history survives.
The mechanics of raising and tracking RFIs in Procore are in Procore on Site: Drawings, RFIs, Daily Log.
The Contract Does Not Set Your Turnaround — You Do
People assume the contract specifies an RFI response deadline. In my experience it usually does not.
So you set it at project start, normally inside the Communication Plan — the document defining who exchanges what, through which channel, by when. RFI turnaround belongs there. You can set it internally, or agree it with the owner and put it in writing. The second is far stronger.
Typical range is five to ten working days. Some teams split it: five days for a straightforward confirmation, ten when several disciplines are involved.
Without that agreement in writing before construction starts, you have no baseline to point at when responses run late. With no baseline, a two-month response gets explained away as “that one was always going to take a while.” To claim delay, you first need a standard to measure against. That is worth an hour of everyone’s time at kickoff.
What Makes an RFI Come Back Fast
Complexity drives response time more than anything else. Questions crossing several disciplines take longer, and that is fair.
But two RFIs of equal difficulty still diverge, and the variable is whether you explained why you are asking.
“Is this detail correct?” forces the reviewer to reopen the drawings and rebuild the situation from scratch. “The detail on A-501 conflicts with the duct above it — see photo and markup below” leaves the reviewer with nothing to do but decide.
RFIs that reduce the reviewer’s workload come back faster. That is mechanics, not goodwill.
Mark Up the Drawing
There is no fixed rule about attachments, but if a drawing exists, mark it up and attach it. That is the baseline.
Describing a location in words invites error. “Upper east wall” can put the reviewer in the wrong place entirely. One circle and one arrow removes the ambiguity — and that markup often becomes the sheet that goes back out to the field.
Site photos do the same work. If you are asserting that actual conditions differ from the drawings, showing the condition is the fastest way to make the point. One photo replaces three paragraphs.
Always Include a Proposed Solution
This is not optional practice. It is baseline practice.
Ask a bare question and the designer has to build a solution from nothing, which takes time. Attach “we think this would work — is it acceptable?” and the reviewer only has to make a call.
One of two things follows:
- Accepted — if it is reasonable from the owner’s position, it is approved and you build what you proposed.
- Rejected — a design revision comes down and you build to the revision.
A rejection is not a loss. The record shows you proposed an alternative, and it captures the designer’s reasoning for why it was not acceptable. When a cost dispute surfaces later, that record works for you. “We proposed a cheaper method and the owner declined” existing as a document is entirely different from existing as a memory.
One caution. Your proposal is a constructability proposal, not design. If you find yourself absorbing judgments about structural adequacy or code compliance, you have taken on someone else’s liability. More on that boundary below.
One Question per RFI — This Is How the Record Survives
The rule is simple: one RFI, one question. Close it completely and nobody gets confused reading it back.
For a follow-up on the same area, open a new RFI and reference the earlier one explicitly: “RFI #00 resolved this condition as follows; we are now requesting confirmation on the following, for these reasons.” Two independent records, connected.
How This Actually Breaks
People know the rule and still lose it, in one specific way: the conversation continues inside the response.
You ask question 1. The answer arrives. A follow-up question 2 and its answer then get exchanged inside the same RFI thread. Months later, people remember question 2’s content as RFI 1. You open the log and the subject line says one thing while the body contains two.
Why this matters: an RFI is a document that gets cited by number. When “we built it per RFI #47” no longer clearly identifies what #47 said, that record has lost its force as evidence.
Do Not Build Just Because an Answer Arrived — SI → Quote → CO → Build
This is the most important section in this guide.
The RFI response is in. Do you build it? No.
First check whether it carries cost or schedule impact. If it does not, proceed. If it does, the owner needs to know before any work happens.
In particular, if the response amounts to a scope change or a design change, it is a change order — every time. Performing extra work on the strength of a response letter destroys your basis for getting paid for it. A response is not a direction.
The Sequence
- Receive the SI (Site Instruction) from the owner or consultant
- Request pricing from the relevant trades
- Submit the quotation (CO request) to the client
- CO approval
- Build
Watch the terminology. The SI on site is a Site Instruction, and it is not the same thing as a Change Directive (CD) under CCDC. A CD instructs you to proceed before price is agreed, with cost settled afterward on actual expenditure — the owner’s tool when the schedule cannot wait for a negotiation.
Which document you received determines whether you can start today. Blur that distinction and you end up with cost committed while revenue is still unapproved. Where that gap turns into loss is covered in Cost Commits First, Revenue Comes Later.
Push GC-Issued RFIs Back Down to the Trades
Here is the rework problem promised earlier.
When the GC issues an RFI, the answer returns to the GC. The trade may not know the RFI existed. If they build before it reaches them, the answer is not incorporated — and it comes out and goes back in. That rework has no basis for a claim against the owner. The answer arrived on time.
So every response triggers three actions:
- Send it to the relevant trade
- Share it with the field team
- Mark it on the drawing — the marked-up sheet has to reach the site
And one more. A PM or PC reminding the crew before the work starts that “there was an RFI on this area” makes a measurable difference. Having transmitted something and having someone recall it at the moment of installation are not the same thing. Transmittal ends with an email; incorporation requires a person to remember.
When the Designer Keeps Asking You Back
Sometimes the designer, instead of answering, keeps returning the question. “Well, how would you suggest we handle it?” — repeatedly.
A contractor can offer an opinion. But it is not an obligation, and a contractor is not the designer. If the loop continues, responsibility for the answer quietly migrates. When something goes wrong later, who actually made the call becomes unclear — and on the record, liability that belongs to the professional who sealed the drawings can end up looking like the field’s.
This is how to close it:
This is a design matter, and the field cannot construct without a detail. We have proposed an approach; if that approach is not acceptable, please issue a detailed drawing.
Now the ask is binary: accept the proposal, or issue the drawing. No friction required. And it is on the record — if the design delay later affects the schedule, this RFI establishes when the clock started.
Turning RFI Delay into Schedule and Claim
An RFI delay by itself is nothing. It only has force once it is recorded.
I had a response take two months — the owner’s PM was on vacation and the channel simply sat empty. Here is the sequence we followed.
Step 1 — put the warning in the RFI itself. When you issue it, state that a response after a given date will affect the schedule. Asserting impact afterward and having written it up front carry very different weight.
Step 2 — add it to the schedule as an activity. We inserted the delay as its own activity: RFI ## response delay — 4 weeks. Now the delay is a visible fact on the schedule. The tool proves it, not an argument.
Step 3 — issue the Delay Notice, using the duration already reflected in the schedule as its basis.
Order matters. Skip the warning, skip the schedule entry, and send a notice two months later, and the reply you get is “why are we only hearing about this now?”
What You Eventually See
Handle enough RFIs and you arrive here.
RFIs are not a test of how well you ask questions. They are a test of how well you manage records. The questions generate themselves — the field produces them whether you are good at this or not. The difference is whether each one survives in traceable form, reaches the people who need it, and gets converted into cost and time when it should be.
Which is why the gap between a PC who handles RFIs well and one who does not only becomes visible near the end of the job. One of them has evidence. The other has recollections.
Next in this series: submittals and shop drawings. If an RFI is the record of asking, a submittal is the record of getting approved — and the way approval delay eats a schedule works differently from the way RFI delay does.
Related Reading
- Submittals in Canadian Construction — Approved vs Reviewed
- Procore on Site: Drawings, RFIs, Daily Log
- CMiC Is Not Another Procore — It Is the Ledger
- Cost Commits First, Revenue Comes Later
- Types of Construction Contracts in Canada
- BC Building Permit: Inspections and Occupancy
- How to Get a Job at a Canadian Construction Company