Every building owner has watched a project RFI log grow. Slowly at first, then in clusters, then in the frantic middle stretch of a project when coordination gaps are everywhere and the schedule is already slipping.

Most owners treat the RFI as an administrative fact of construction life. Something to be managed, tracked, and resolved as quickly as possible. A cost of doing business.

That’s the wrong frame.

The RFI as diagnostic signal

A Request for Information is a symptom, not a root cause. Every RFI points to a gap that shouldn’t exist: a missing coordination detail, an ambiguous specification, a conflict between what one trade designed and what another needs to build.

Individually, an RFI is a minor friction point. In aggregate, the RFI log is a map of where your project’s information supply chain broke down.

That map is extraordinarily useful, if anyone reads it that way. In practice, it rarely is.

Most RFI management focuses entirely on the resolution end: how quickly can we get an answer, who needs to respond, what does the answer say. The question of why this RFI needed to exist at all rarely gets asked. And because it doesn’t get asked, the same types of RFIs appear on every project, from the same coordination zones, driven by the same gaps in design documentation.

What the data would show if we collected it honestly

The construction industry doesn’t have reliable industry-wide data on RFI patterns. Every firm tracks their own projects. Some GCs have internal benchmarks. But there’s no shared baseline that answers the most important questions.

What percentage of RFIs could have been prevented with better documentation at the design stage? Which phases of a project generate the most RFIs, and why? Which design disciplines generate the most downstream coordination requests, and what does that tell us about their documentation practices?

What percentage of RFIs are truly novel problems versus variations of issues that appear on every project? How much of the RFI volume is driven by design ambiguity versus field conditions versus coordination failures between trades?

These questions matter because the answers would change what owners require from their design teams. If 60% of your project’s RFIs trace back to MEP coordination gaps in design documentation, that’s a different conversation with your architect than “our RFI count seems high.”

The 10-15 RFI per million dollar benchmark, and what it hides

The construction industry often cites a benchmark: projects generate roughly 10 to 15 RFIs per million dollars of construction value. This number gets treated as a natural law. Something like the weather. You can’t change it, you can just manage it.

But that benchmark is descriptive, not prescriptive. It describes what happens when RFIs are treated as inevitable rather than as problems with identifiable causes.

Projects with rigorous design coordination, where AI or dedicated coordination teams catch conflicts before documents are issued, produce dramatically fewer field RFIs. Not because field conditions are simpler, but because more of the coordination work was done before the first shovel went in the ground.

The benchmark describes the average. The average is not the aspiration.

What you can require to lower your number

The path to a lower RFI count runs through the design phase, not the construction phase.

Your contracts should specify coordination requirements, not just deliverables. What level of design coordination is expected before documents are issued for permit? What conflicts must be resolved before the GC breaks ground? What documentation standards must be met before coordination is considered complete?

When a design firm knows you’ll be measuring RFI volume on their projects and asking them to explain the patterns, the incentive structure around documentation quality changes. Not completely, there will always be some RFIs generated by genuine field conditions, but meaningfully.

The learning that should be happening but isn’t

At project closeout, the RFI log should be reviewed as a learning document, not just filed as a record. What types of issues drove the most volume? Were there coordination zones that generated disproportionate numbers? Were there specific design decisions that propagated uncertainty downstream?

That analysis should feed the next project brief. The next design contract. The next set of coordination requirements.

If you’ve built more than one building without ever looking at your RFI history this way, you’ve been paying for the same gaps repeatedly without knowing it. The data to fix it has been sitting in your project management system the whole time.