
Ask anyone who has bid or managed a project during pre-construction what slows the process down most, and RFIs come up constantly. Not because the questions themselves are complicated, but because of how many steps it takes for a question to travel from the person asking it to the person who can actually answer it.
During construction, plenty of tools already give GCs and design teams a direct line to each other. Pre-construction is a different story. Before a GC is even under contract, that direct relationship usually doesn't exist yet, and RFIs during bidding tend to follow a much longer path.
It typically looks something like this: a subcontractor or supplier has a question and sends it to the GC. The GC sends that question, often bundled with questions from several other subs, to the ownership group or owner's rep. The ownership group compiles all of the incoming questions from every bidding GC into a single list and sends that list to the architects and engineers. The design team works through the list and sends their responses back to the ownership group. The ownership group then compiles those responses and sends them back out to the GCs. The GCs pass the answers back to the subs and suppliers who asked in the first place.
That's six steps. A question travels from sub to GC, GC to owner, owner to design team, design team to owner, owner to GC, and GC back to sub, before anyone actually has their answer.
The step-count alone is a problem, but the bigger issue is what happens at each compiling stage. Ownership groups typically don't send questions to the design team one at a time as they arrive. They wait, collect RFIs from all the bidding GCs, and send them over in a batch. The same thing happens on the way back: rather than relaying each answer the moment it's received from the architect, the ownership group often waits until the full batch of responses is complete before sending anything back to the GCs.
That waiting period is where real time gets lost. Even if every individual step in the chain only takes a single day, a six-step process still adds up to roughly six days between a question being asked and an answer actually reaching the person who needed it.
Six days doesn't sound catastrophic on its own, but it matters more during bidding than at almost any other point in a project. Bid windows are typically only a few weeks long. Losing six days to an RFI relay, on a question that might directly affect how a GC prices their bid, is a meaningful chunk of an already short window.
Multiply that across dozens of RFIs on a single project, from multiple bidding GCs, each waiting on batched responses before they can finalize pricing, and the six-step relay becomes one of the more significant hidden time costs of the entire bidding process.
Batching questions into a single email or a single list can feel like the efficient move. Fewer messages, fewer things to track, one send instead of several. But that same batching is also where questions quietly go missing.
When ten or fifteen RFIs get bundled into one long email, it's easy for an architect or engineer to answer eight of them and lose track of the other two, especially if those questions are buried in the middle of the list or phrased less clearly than the rest. Nobody notices right away, because from ownership's side, a response came back. It just wasn't a complete one. That gap doesn't usually surface until a GC follows up asking why a specific question was never addressed, at which point more time has already been lost re-asking something that should have been answered the first time.
A structured system where each question is tracked as its own distinct item, rather than one line inside a longer email, makes it much harder for an individual RFI to get overlooked. Every question has its own status, answered or not, so nothing gets buried inside someone else's inbox.
Ownership should still decide who's responsible for answering each question. That control matters, and it doesn't need to disappear for this to get faster.
What can go, though, is the manual compiling on both ends. On the way in, the real friction isn't that ownership routes the question to the design team. It's that they wait until they have a full batch from every bidding GC before sending anything over. On the way back, the friction goes a step further: ownership has traditionally had to wait for the design team to answer everything, then manually compile and relay those answers back to the GCs themselves.
That second step doesn't have to happen at all. Once ownership has assigned a question to the right architect or engineer, the answer can go straight back to the GC the moment the design team submits it, without ownership needing to compile or forward anything. The information still flows through the same relationship chain, GC to ownership to design team and back, but the return trip no longer requires a manual hand-off at the ownership stage. The result is a process that's still built on the same chain of responsibility, just without the batching delay on the way in and without a manual relay step on the way out.
The pre-construction RFI relay has been slow, and prone to dropped questions, for the same reason: batching feels efficient because it means fewer emails to send, but it comes at the cost of both speed and accuracy. In a phase of the project where GCs are working against a hard bid deadline, holding answers until a batch is complete, requiring a manual relay on the way back, or letting individual questions get buried inside a long list all work against everyone, including the ownership group that ultimately wants accurate, well-informed bids back.
This is why RFIs work the way they do during pre-construction on Outbidd. Every question is tracked individually rather than buried in a batch, ownership groups still decide who's responsible for answering each one, and once the design team responds, the answer goes straight back to the GC without ownership needing to compile or forward anything.