The RFI Your Model Could Have Answered

Your Superintendent Spent Tuesday Morning Measuring Something the Model Already Answered

The question went out Monday at 4:40 PM. A ceiling height at grid line C4 didn't match the reflected plan. By Tuesday at 7:15 AM your superintendent was on a lift with a tape measure, an architect was checking a detail sheet, and a coordinator was digging for the model revision that should have settled it. The answer was sitting in the Revit model the whole time, waiting for somebody to look at the right version.

That is the shape of most RFIs. They are not hard questions. They are questions where the model, the sheet, and the spec disagree, and nobody can say which one wins fast enough to keep working. So the field waits, the office digs, and the clock runs on labor you already committed to.

Run the math on one RFI. A superintendent's morning. An hour of PM coordination. The architect's review. A coordinator reconciling versions so the answer holds. Then the part nobody logs: if the answer comes back Thursday and two crews sat Wednesday, you are in idle-labour territory, and an unresolved conflict behind a crew can burn $15K to $50K a week.

Now count RFIs on a mid-size commercial job. Fifty is a light project. A hundred and fifty happens. If a good share of them are questions the model already answers, you are spending days on measuring things you already drew, plus the idle time that never makes it into the RFI log.

The fix is not fewer RFIs. The fix is not answering faster. The fix is never sending the RFI, because the conflict was caught in the model, before the field ever found it.

Why Most RFIs Are Model Questions Wearing a Paper Costume

Traditional coordination runs on documents. A PDF set gets issued, someone marks it up, notes get typed into a log, and the log gets attached to an email. The model exists, but it lives in a separate lane owned by the BIM team. Nobody coordinating off it, nobody fielding off it, and nobody checking whether the sheet the superintendent is holding matches the geometry in the file.

That split is where RFIs come from. The architect's detail shows a 9-foot ceiling. The model says 9 feet 6 inches because the duct main demanded the extra 6. Neither is wrong. They disagree, and the disagreement costs money until somebody reconciles them. With a paper workflow, the reconciliation is an RFI. With a live model, it is a change you catch before the question ever gets typed.

BIM versus traditional coordination is not really about software. It is about where the truth lives. In a traditional workflow, truth lives in the issued set, and the set goes stale the moment the architect touches anything. In a model-driven workflow, truth lives in one record that updates. Every publish is a versioned snapshot, so a disagreement between sheet and model is a quick check against a known revision, not a three-day exchange.

Here is the practical version. When you work from a versioned record, every wall, door, and duct in an issue is traceable to a real element, and the issue carries the sheet and the revision that raised it. When someone asks why the log says the door count changed, you open the comparison between two revisions and answer. When the count moves again, the next comparison shows it. The question never becomes an RFI because the answer is already a click deep in the model.

That traceability is the whole point. It changes what an RFI is. Most of them stop existing.

What One Late RFI Costs the Job

Take a real shape. A mechanical RFI on a large office job. The question: does the VAV box at level 3 north serve one zone or two. The coordination set was built off a schematic that showed one. The mechanical drawings show two. The model shows one because it was modeled from the schematic.

The write-up takes the better part of a morning. A couple of phone calls and one email chain take another chunk. The architect confirms two, changes the schematic, and issues a response in two days. The mechanical coordinator reworks the layout, which touches the ceiling space of three other trades. The PM adjusts the schedule. The field, meanwhile, has been told to hold on that section and shifted a few people to a different floor for a day and a half.

Add it up. Superintendent time, PM time, coordinator time, architect time, two days of design delay on one system, and the rework. You are paying for one question many times over. And that does not include the schedule pressure, or the fact that three trades now have to redraw against a revision they did not know was coming.

Now the alternative. The duct main in the model conflicts with the ceiling height. In a live record, that conflict shows up in the comparison between revisions before it becomes an RFI. You pin it to the element, tag the owner, and attach a screenshot. The owner sees it in the 6am digest. No write-up, no lift time, no delay on the system. The change is handled in the model, which is where a clash costs about $50, against $5,000 to $50,000 once the field finds it.

What a Live Model Actually Changes About the Question

BidLight keeps one live record of the project inside Revit and Navisworks. That sounds like a small claim. It is the whole game. When the model is the record, the answer to "what does the drawing show" and "what does the model say" is the same answer. You publish from the model and every publish becomes a snapshot with its own files, author, and milestone. Change a wall in the model, publish, and the difference is listed element by element.

That matters for RFIs because most RFI questions are about location, count, or which version governs. Two VAV boxes, not one. A duct run lower than the ceiling it was drawn under. A door type that changed between the last two revisions. The comparison groups changes by category, structural, MEP, envelope, interior, so the person who owns the question sees it first.

The honest limit is worth saying plainly. BidLight does not run automated clash detection, and it does not read the architect's mind. A person still reviews what changed. But reviewing a short, grouped list in about 15 minutes beats a 90-minute meeting where everyone brings a different version. And the item you review is already tied to the element, the sheet, and the revision.

The real change is speed. When an RFI question comes in, the coordinator does not have to rebuild the history from email to see whether it matters. They open the model, find the element, and see which revision touched it. That is the difference between a two-day RFI cycle and a ten-minute answer.

The second-order effect is that you stop hiding behind RFIs. When the model can answer, the conversation shifts to decisions instead of document archaeology.

The Money You Stop Losing on Questions You Already Answered

Start counting what goes away. Field labor stops waiting on answers that were already in the model. Superintendents stop measuring ceilings that are modeled to the inch. PMs stop chasing three parties for a two-paragraph answer. Coordinators stop rebuilding the story to reflect changes that happened three days ago in a model nobody was checking.

On the hyperscale programme, the case study shows 18,000+ hours saved and 8,900+ issues resolved, with $12.3M in cost saved. That is the aggregate version of Tuesday morning, repeated across a programme that stopped sending questions it could answer by opening a file. It is not a productivity slogan. It is superintendent time, coordinator time, and PM time that came back to the job when the record went live.

The schedule number matters too. A clash that sits 47 days can burn $28,000 in idle field labour. Teams that see the change on the day it is made do not give it 47 days. Catch it in the model, close it with proof, and the same issue does not come back on site.

That is also the case against another folder, another portal, another spreadsheet. Tools that live in their own world create their own RFIs, because the record and the geometry never meet. The only thing that kills the question is having the answer in the same file the question is about.

BidLight runs from Basics at $260 per licence per year to Max at $590, with Enterprise custom. Every plan includes unlimited projects. That is cheap against one avoided week of idle crews. It is trivial against fifty RFIs a year.

Turn the Answer Into a Service You Can Offer

Here is the part most firms miss. Once the model can answer RFIs in minutes, the model itself becomes a service you can offer. Owners value coordination that does not wait on paperwork. Architects value feedback that arrives while the design is still soft, not three weeks after issue. General contractors value a trade partner who shows up with the answer.

BidLight does done-for-you BIM work alongside the software. Execution plans, 4D sequencing, fabrication detailing and spooling. Firms that have the tool but not the bench use that to deliver, and firms that already have the bench use the tool to deliver faster. Either way, the deliverable is a coordinated model that answers questions, not a set of drawings that generates them.

Make the service visible. A coordination review with a live record attached is worth more than a PDF markup, because the client can see the traceability. A 4D sequence tied to the same model is worth more than a standalone schedule, because the changes and the sequence agree. You are offering the answer, not the hours spent hunting it.

That is the pitch in one line. Stop chasing scattered updates. Catch the clash in the model, pin it to the element, and close it with proof. The mechanism is simple. The record rides the same model the field builds from, and the question never becomes an RFI because it was answered before anyone typed it.

One live record of the project inside Revit, with every export versioned and every change diffed. That is the answer to the RFI your superintendent spent Tuesday morning measuring.