Yes, RFIs and change orders can be automated — but not the part most people mean. An AI agent should not be writing the answer to a construction RFI: that answer turns on drawings, contract scope, and liability a person has to own. What can be automated is everything wrapped around the answer — capturing the RFI, finding the specific drawing revision or spec section it hinges on, drafting a response for review, routing it to whoever is accountable, and logging the outcome where the project team will actually look for it. That wrapper is where the measurable cost sits, and it is almost entirely clerical.
The size of that cost is documented rather than estimated. The Navigant Construction Forum's April 2013 research perspective, Impact & Control of RFIs on Construction Projects, analysed 1,362 projects initiated between 2001 and 2012 — roughly 1.1 million RFIs in total, an average of 796 per project. Working from interviews with senior staff at three US design and construction-management firms, it put the typical RFI at eight hours to receive, log, review and respond, at an average cost of $1,080. On the average project in that data set, that works out to 6,368 hours and $859,680 spent on RFI handling alone. Read the cost figure the way the report itself frames it: Navigant's own footnote calls it an informal survey, notes the estimates are "not specific to any particular design discipline, industry sector or geographic area," and warns that actual costs "may vary widely." It is a well-constructed order-of-magnitude number, not a benchmark to hold a specific firm to — and the hours figure, 6,368 on one project, is the part that should stop a reader regardless of what hourly rate they would substitute.
Two details in that data matter more for mid-sized contractors than the headline. First, the RFI burden is proportionally heavier on smaller work: across the sample the ratio was 9.9 RFIs per $1 million of construction cost, but projects between $5 million and $50 million averaged 17.2 per $1 million, against 1.1 for projects over $1 billion. A firm running $30 million jobs carries a heavier per-dollar paperwork load than the megaproject contractors whose processes get written about. Second, the sample skews hard to Australia and New Zealand — some 79% of those projects — so treat the regional response times as directional for a US firm rather than as a domestic benchmark.
The latency is the part that turns paperwork into money. Navigant measured an average first reply time of 6.4 days and a median reply time of 9.7 days. Worse, a substantial share never got answered at all: the report puts no-reply rates at slightly under 19% in the Middle East at the low end and an average of 35% in Asia at the high end. An RFI that sits for ten days is a crew working to an assumption. An RFI that is never answered is a crew working to an assumption that nobody has written down, on a question someone already thought was important enough to ask formally.
That is also the mechanism connecting RFIs to change orders, which is why automating them as two separate systems misses the point. The Navigant report quotes a paper on the subject directly: "It is now common to see contractors submitting an exceptional number of RFI's and then presenting unapproved change orders which they claim are the result of the design professional's response to RFIs." Whether or not that is being done deliberately on your project, the structural fact holds — the RFI record is the evidence base a change order gets argued from. If your RFI log and your change order log are separate systems that a person reconciles by memory, you will find out they disagree during the argument, not before it.
So the automatable workflow is a specific four-step shape, and it is the one we build into an AI operating system for construction companies. Capture: the RFI is read as it arrives by email or in the PM platform. Retrieve: it is matched against the project's own drawings, specs, and prior RFIs — not a generic construction knowledge base. Draft: a proposed answer or routing decision is prepared that cites the specific drawing revision or spec section it came from. Route and log: it goes to the responsible PM or superintendent for approval, and the question, the answer, and the approver land back in the PM platform. The eight hours Navigant costed out is mostly steps one, two and four. Step three is where a person's judgment belongs, and it is the only step that should stay slow.
Two design constraints make the difference between this working and becoming a liability. Nothing auto-sends to a sub, an owner, or a GC — a draft on a live project is an internal artifact until a named person approves it. And every draft cites its source, so the PM reviewing it checks the drawing revision the answer came from rather than the conclusion the model reached. That second constraint is what makes review fast enough to be worth doing; an uncited draft has to be re-researched from scratch, which costs the same eight hours you were trying to remove. Both constraints are the same discipline any production AI agent development work should already impose: the agent is accountable for finding and citing the evidence, and a person stays accountable for the decision.
The hard engineering here is retrieval, not generation. Answering "which revision of sheet A-301 governs this detail, and did a prior RFI already address it" means indexing drawings, specs, addenda, submittals, and the RFI history itself, and keeping that index current as revisions land mid-project. That is the same problem we solved on Haystack's AI data intelligence platform — one contextual search layer across documents, data lakes, and repositories, with real-time indexing so a new document is searchable the moment it exists, built in Golang specifically because the earlier system failed under load. A construction document set is smaller than that but harder in one way: being confidently wrong about which revision is current is worse than returning nothing.
It is worth being accurate about how far ahead of the field this puts anyone, because the widely-repeated version of the adoption statistic is wrong. Bluebeam's Building the Future: AEC Technology Outlook 2026, published 28 October 2025 from a July 2025 survey of more than 1,000 AEC technology decision-makers at manager level or above across the US, UK, France, Germany and Australia, found that only 27% of AEC firms use AI for automation, problem-solving, or decision-making. The often-quoted "94% plan to increase AI investment" is not 94% of the industry — it is 94% of the firms already using it. The gap is between a small group compounding and everyone else, not between intention and action. Bluebeam CEO Usman Shuja framed the state of play as: "The question now isn't whether AI works – it's how to integrate it effectively." Among those early adopters the same report found 68% had saved at least $50,000 and 46% had saved between 500 and 1,000 hours.
If you are evaluating this for your own firm, the useful first question is not which vendor to call — it is how many RFIs your last three comparable projects actually generated, what your median reply time was, and how many were never answered. Those three numbers tell you whether you are near Navigant's averages or well off them, and they are the only honest basis for estimating what automating the wrapper is worth to you specifically. If they are not readily available, that is itself the finding: an RFI process nobody can measure is one nobody can control, and it is the reason the change order argument is usually lost on evidence rather than on merit. An AI readiness assessment is built to establish exactly those baselines before any system gets scoped.
Find this useful? Tell Google to show you more of it.