RFIs and submittals already have their own tracking systems. That doesn’t stop half their real activity from happening in email instead — where the tracking system can’t see it. Every RFI and every submittal lives, in theory, inside a structured tracking system — a log with statuses, dates, and assigned owners. In practice, a huge share of the actual back-and-forth that resolves an RFI or moves a submittal toward approval happens in email, running parallel to and often disconnected from the official log. Someone emails a quick clarifying question about an open RFI. Someone else emails asking whether a submittal has been reviewed yet. A subcontractor emails a revised submittal directly to a project engineer instead of uploading it through the formal system. None of this is unreasonable behavior — email is fast, familiar, and doesn’t require anyone to log into a separate platform for a quick question. The problem is that this parallel, informal communication channel creates a specific kind of bottleneck: the official tracking system shows one thing, the actual state of the conversation is somewhere else entirely, and reconciling the two requires someone to manually cross-reference email against the log, which is exactly the kind of tedious task that tends to fall behind under normal workload pressure.
| ★ Key Takeaway The bottleneck in RFI and submittal communication usually isn’t a lack of activity — it’s activity happening in two disconnected places at once, with nobody keeping the official record and the actual email conversation reliably synchronized with each other. |
|---|
This article covers how this specific bottleneck forms, why RFIs and submittals are particularly prone to it, and how connecting email communication directly to the official RFI and submittal systems closes the gap between what’s actually happening and what the log says is happening.
Key Definitions
| Term | Working Definition |
|---|---|
| RFI Bottleneck | A delay in resolving a Request for Information caused by communication happening outside the formal tracking system, rather than by the underlying technical question itself. |
| Submittal Communication Gap | A discrepancy between a submittal’s official tracked status and the actual, more current state of the conversation happening about it through other channels. |
| Parallel Channel | An informal communication path — typically email or phone — running alongside a formal tracking system, often carrying information the formal system doesn’t reflect. |
| System Synchronization | The degree to which a formal tracking log accurately reflects the actual, current state of a specific RFI or submittal at any given time. |
| Connected Communication | An email or messaging workflow directly linked to the formal RFI and submittal tracking systems, so informal communication updates the official record automatically. |
| Response Chain Visibility | The ability to see a complete communication history for a specific RFI or submittal, rather than only the most recent formal status update. |
Objectives
- Connect informal email communication about RFIs and submittals directly to the formal tracking systems that govern them.
- Reduce the gap between an RFI or submittal’s official tracked status and the actual, current state of the underlying conversation.
- Eliminate the specific bottleneck caused by someone having to manually reconcile email threads against the formal log.
- Preserve a complete, accurate communication history for every RFI and submittal, not just the most recent status entry.
- Speed up resolution by making it easier to see the full context of a question without searching across multiple disconnected channels.
Importance
An RFI or submittal that’s actually further along in resolution than its official status suggests creates real, avoidable confusion. A superintendent checking the log and seeing an RFI marked “open” might assume no progress has been made, when in fact a clarifying email exchange has already resolved most of the underlying question — the answer just hasn’t made it back into the formal system yet. That gap between perceived and actual status leads to duplicated effort, unnecessary follow-up questions, and sometimes field decisions made based on outdated information.
The compounding cost shows up specifically during busy periods, when the volume of parallel email communication grows faster than anyone’s capacity to manually keep the formal log synchronized with it. This is exactly when the gap between the log and reality tends to widen the most, which is unfortunately also exactly when accurate, fast information matters most — during an active construction push when multiple RFIs and submittals are moving simultaneously and everyone is relying on the log to reflect current reality.
| ◆ Industry Insight A meaningful share of RFI and submittal-related schedule friction traces back not to slow technical resolution, but to a communication gap where the actual resolution happened informally through email while the formal tracking system continued to show an outdated, unresolved status. |
|---|
This distinction between technical delay and bookkeeping delay matters because the two call for completely different fixes. If a design team is genuinely slow to answer a technically difficult RFI, the fix involves engineering resources, priority setting, or schedule negotiation. If an RFI was actually answered days ago but the log never caught up, the fix is entirely different — it’s a communication and process discipline problem, solvable without touching the underlying technical work at all. Teams that misdiagnose the second problem as the first waste effort trying to speed up something that was never actually the bottleneck.
Stakeholders
| Role | Interest in Reducing RFI and Submittal Communication Bottlenecks |
|---|---|
| Project Engineer | Manages the formal RFI and submittal logs and bears the burden of manually reconciling them against parallel email communication. |
| Superintendent | Relies on the formal log’s accuracy to make field decisions and plan sequencing around open items. |
| Subcontractor / Trade Partner | Often initiates parallel email communication and benefits from that communication actually updating the record trade partners rely on. |
| Architect / Engineer of Record | Responds to RFIs and reviews submittals, and benefits from having full communication context rather than a fragmented, partial picture. |
| Project Manager | Needs accurate visibility into genuine RFI and submittal status for schedule and risk management. |
| Owner / Owner’s Rep | Bears the schedule consequence of decisions made based on inaccurate or outdated status information. |
Construction Workflow
Where the Gap Between Email and the Formal Log Actually Opens
- A subcontractor emails a clarifying question about an open RFI directly to a project engineer instead of through the formal RFI system, and the answer, once given, never gets logged back into the official record.
- A quick phone call or informal email exchange resolves an ambiguity in a submittal’s requirements, but nobody updates the submittal’s tracked status to reflect that resolution.
- A subcontractor sends a revised submittal as an email attachment rather than uploading it through the formal document control system, creating a version that exists only in someone’s inbox.
- Multiple people are copied on an email thread that discusses an RFI’s resolution, but no single person takes responsibility for updating the formal log afterward.
- The volume of parallel email communication during a busy period outpaces anyone’s available time to manually reconcile it against the tracking system.
A Connected Communication Sequence
| Step | What Happens | Output |
|---|---|---|
| 1. Email Intake and Analysis | Incoming email related to an RFI or submittal is automatically identified and categorized. | Categorized communication linked to the relevant item |
| 2. Record Matching | The email is matched directly to its corresponding RFI or submittal in the formal tracking system. | Linked communication history |
| 3. Status Cross-Check | The system flags any discrepancy between the email conversation’s apparent resolution and the formal log’s current status. | Flagged synchronization gaps |
| 4. Update Prompt | A responsible team member is prompted to confirm and update the formal status based on the actual communication. | Synchronized, accurate record |
| 5. Consolidated History | All communication related to a specific RFI or submittal remains visible together, rather than scattered across separate email threads. | Complete, accessible communication record |
| ▣ Field Reality An RFI that shows as “open” in the formal log for two weeks after it was actually resolved through a three-email exchange isn’t a technical resolution failure — it’s a bookkeeping failure, and it’s one of the most common, quietly frustrating gaps in day-to-day construction communication. |
|---|
The frustration this generates tends to be quiet precisely because it’s diffuse — no single person experiences the full cost of it at once. A superintendent loses a few minutes double-checking something that was already resolved. A project manager includes an inaccurately “open” RFI in a status report that then requires an awkward correction. A subcontractor gets asked the same question twice by two different people who didn’t realize an answer already existed. None of these individually feels like a crisis, but added together across a project’s full RFI and submittal volume, the cumulative drag on everyone’s time and patience is real, even though it never shows up as a single, obvious line item anyone would think to fix directly.
Required Documentation
- The complete, current RFI and submittal logs, including status, assigned owner, and resolution history for every item.
- A centralized or connected email channel for project communication, allowing systematic matching between incoming email and formal tracking records.
- Clear internal protocol for who’s responsible for updating the formal log when a resolution happens informally through email.
- A documented policy on which communication channels are acceptable for submitting or resolving RFIs and submittals, to reduce fragmentation.
- An audit trail connecting every formal status change to its supporting communication, for accountability and dispute resolution.
Technology Integration
The technical foundation for closing this gap is connecting email communication directly to the RFI and submittal tracking systems, so that a message related to a specific item gets matched to that item automatically, rather than existing as an isolated, disconnected conversation that someone has to remember to reconcile manually later.
What a Connected System Provides
- Automatic matching between incoming email and the specific RFI or submittal it relates to, based on content analysis rather than requiring the sender to reference a specific tracking number correctly.
- Flagging of discrepancies between an email conversation’s apparent resolution and the formal log’s current recorded status.
- A consolidated communication history for every RFI and submittal, showing the complete conversation rather than requiring someone to search across separate email threads.
- Clear prompts directing a responsible team member to confirm and update the formal record whenever a resolution happens through informal communication.
| ✎ Expert Tip Periodically audit a sample of “open” items in the RFI and submittal logs against actual email activity related to them. This is the fastest way to gauge how large the gap between formal status and actual resolution has become, and whether a connected communication process is genuinely closing it. |
|---|
AI-Assisted Opportunities
AI assistance is well suited to this specific problem because it requires reading email content, understanding which formal record it relates to, and recognizing when the content of a conversation suggests a resolution that the formal system hasn’t yet captured — a synthesis task that benefits from a system holding both the email content and the formal tracking data simultaneously.
Matching Communication to Formal Records Automatically
Rather than requiring every email to reference a specific RFI or submittal number correctly, an AI-assisted system can read an email’s content and match it to the correct formal record based on what it’s actually discussing, catching connections a rigid, number-based matching system would miss when someone forgets to include the reference.
Recognizing Resolution Language
A system trained to recognize resolution-indicating language — confirmation that a question has been answered, agreement that a submittal meets a specific requirement — can flag when an email conversation suggests a formal status update is needed, prompting a person to confirm and make that update rather than the resolution simply staying informal indefinitely.
| ● Important Automated matching and flagging accelerates keeping the formal record synchronized with actual communication — it doesn’t replace the judgment needed to confirm that a suggested resolution is genuinely complete before formally closing an RFI or approving a submittal. A flagged, likely resolution should still receive a person’s confirmation before the formal status changes. |
|---|
This safeguard matters because email language suggesting resolution isn’t always as conclusive as it sounds. A message saying “this should work” or “I think that answers it” might reflect genuine confidence, or it might reflect a tentative first impression that still needs verification against the actual specification or drawing before anyone treats it as final. A system flagging this kind of language as a likely resolution is doing exactly what it should — drawing attention to it — but treating that flag as equivalent to an actual, confirmed closure would risk formally resolving items based on language that was never meant to be the final word.
Implementation
| Phase | Activities | Owner |
|---|---|---|
| Gap Assessment | Audit a sample of currently open RFIs and submittals against actual email activity to measure the existing synchronization gap. | Project Engineer |
| Pilot | Connect email communication to the formal tracking systems for a subset of active RFIs and submittals. | Preconstruction Manager |
| Protocol Definition | Establish clear responsibility for confirming and updating formal status when a resolution is flagged from email activity. | Project Manager |
| Rollout | Extend connected communication tracking to the full RFI and submittal log. | Project Team |
| Outcome Tracking | Monitor the gap between formal status and actual resolution over time to confirm the connected process is working. | Preconstruction Manager |
Best Practices
| Practice | Why It Matters |
|---|---|
| Connect email communication directly to formal RFI and submittal systems | This is what allows informal resolution to actually update the official record rather than existing only in someone’s inbox. |
| Assign clear responsibility for confirming flagged status updates | A flagged discrepancy still needs a specific person to verify and act on it, not just a system notification nobody owns. |
| Periodically audit for gaps between formal status and actual communication | This reveals how well the connected process is actually working and where synchronization is still slipping. |
| Discourage submitting revised documents solely through informal email | Documents that exist only in an inbox aren’t part of the formal, traceable record other team members rely on. |
| Preserve complete communication history for every RFI and submittal | A consolidated history supports faster resolution and protects against later disputes about what was actually communicated. |
| ✓ Best Practice Set a standing expectation that any RFI or submittal resolution reached informally through email gets formally logged within a defined, short window — treating prompt log updates as a normal part of closing the loop, not an optional afterthought. |
|---|
Common Mistakes
| Mistake | Consequence |
|---|---|
| Allowing informal email to become the de facto resolution channel without updating formal records | This creates a persistent, growing gap between what the log says and what’s actually happening. |
| Assuming the formal log is always current because it’s the official system | Official status is only as current as someone’s last update — the system itself doesn’t automatically stay synchronized with parallel email activity. |
| Not assigning clear ownership for reconciling email against the formal record | A responsibility nobody specifically owns tends not to get done consistently, especially under workload pressure. |
| Accepting revised submittals through informal email attachments | This creates documents outside the formal, traceable system that other team members may not know exist. |
| Treating a flagged status discrepancy as automatically resolved without confirmation | A suggested resolution from email content still needs a knowledgeable person’s confirmation before it becomes official. |
| ✕ Common Mistake “We handled that over email” is a common, informal way of describing a resolution that the formal system doesn’t yet know about. Until the formal record reflects it, the resolution isn’t actually visible to anyone relying on the official log. |
|---|
Industry Examples
Commercial Office Tower Structural RFI
An RFI regarding a structural connection detail was effectively resolved through a three-message email exchange with the structural engineer, but remained marked “open” in the formal log for over a week until a connected communication system flagged the discrepancy and prompted a formal closure.
Healthcare Facility Submittal Coordination
A medical equipment submittal’s requirements were clarified through an informal email exchange between the equipment vendor and the mechanical engineer, and a connected system correctly matched that exchange to the formal submittal record, prompting an update that avoided a redundant, duplicate clarification request from a different team member.
Industrial Process Facility RFI Volume
During a particularly active RFI period on a process plant expansion, connected communication tracking caught that several RFIs marked open in the formal log had actually been resolved through direct engineer-to-engineer email exchanges, preventing redundant follow-up questions that would otherwise have added to an already high RFI volume.
Data Center Electrical Submittal Package
A submittal revision was emailed directly to a project engineer rather than uploaded through the formal document control system, and connected communication tracking flagged the email attachment as a document requiring formal submission, prompting the engineer to properly log it rather than letting it exist only in an email thread.
Residential High-Rise Waterproofing RFI
A waterproofing detail RFI’s resolution, reached informally through a phone-call-followed-by-email confirmation, was captured and matched to the formal RFI record once the confirming email was sent, closing a gap that would otherwise have left the RFI showing as unresolved despite the field team already proceeding based on the agreed clarification.
Institutional University Laboratory Submittal Review
A laboratory equipment submittal’s back-and-forth clarification with the architect happened entirely through email over several days, and a connected communication system preserved the complete exchange as part of the submittal’s formal record, giving a later reviewer full context that a status-only log entry would never have captured.
Infrastructure — Bridge Rehabilitation RFI Tracking
A bridge rehabilitation project’s RFI regarding a specific bearing pad replacement detail was resolved through a direct phone call followed by a brief confirming email, and connected tracking correctly captured the confirming email as evidence of resolution, preventing the RFI from lingering as officially unresolved for the remainder of an already tight construction window.
Manufacturing Facility — Specialty Equipment Submittal Clarification
A specialty equipment vendor’s clarifying email about a submittal’s electrical requirements was automatically matched to the correct submittal record despite the vendor never referencing the submittal’s tracking number directly, preventing what would otherwise have been an orphaned communication disconnected from the formal review process.
FAQs
Why do RFIs and submittals specifically develop this kind of communication gap?
Because resolving them often requires quick, informal back-and-forth that’s naturally easier through email than through a formal system, even though the formal system is what everyone else relies on to know the actual current status.
Should informal email communication about RFIs and submittals be discouraged entirely?
Not necessarily — email is fast and useful for quick clarification. The goal is connecting that communication to the formal record, not eliminating the convenience of email as a communication channel.
How does a connected system know an email relates to a specific RFI or submittal?
By analyzing the email’s content and matching it to the corresponding formal record, rather than relying solely on the sender remembering to reference a specific tracking number.
What should happen when a system flags a likely resolution from email content?
A responsible person should confirm the resolution is genuinely complete before formally updating the status — the flag accelerates awareness, but the judgment call about closing an item still belongs to a person.
How often should teams audit for gaps between formal status and actual communication?
Periodically, and especially during high-volume periods when parallel email activity is most likely to outpace manual reconciliation efforts.
Does this approach help with disputes about what was actually communicated?
Yes — a preserved, connected communication history gives a clear, documented record of exactly what was said and when, which is considerably more useful in a dispute than relying on individual memory or scattered email threads.
How should revised submittal documents sent by email be handled?
They should be formally logged through the proper document control system promptly, rather than allowed to exist only as an email attachment that other team members may not know about.
What’s the relationship between this issue and general email communication automation?
This is a specific, high-value application of the same underlying principle — connecting communication directly to the project data and formal records it actually relates to, rather than treating email as a disconnected, parallel channel.
How should a project handle disagreement about whether an RFI is genuinely resolved?
The formal record should only be updated once a responsible party explicitly confirms resolution, rather than closing an item based solely on an automated system’s interpretation of ambiguous or tentative email language.
Can this kind of connected tracking help identify which RFI or submittal categories generate the most communication overhead?
Yes — analyzing which types of items generate the most back-and-forth email exchange can reveal categories where documents or specifications might benefit from clearer, more complete information upfront, reducing the need for repeated clarification.
Expert Recommendations
- Connect email communication directly to formal RFI and submittal tracking systems rather than treating them as separate, disconnected channels.
- Assign clear, specific responsibility for confirming and updating formal status whenever a resolution is flagged from informal communication.
- Periodically audit open items against actual email activity to measure and address any growing synchronization gap.
- Discourage accepting revised documents solely through informal email, directing them instead through the proper formal document control process.
- Preserve complete communication history for every RFI and submittal, supporting both faster resolution and stronger protection against later disputes.
Professional Conclusion
RFIs and submittals rarely stall because the underlying technical questions are genuinely hard to resolve. They stall, or appear to stall, because the resolution happens in one place — an email exchange, a quick phone call — while the official record everyone else relies on stays frozen at an earlier, outdated status. That gap between actual progress and recorded progress is where a surprising share of RFI and submittal-related friction actually originates.
Closing it doesn’t require eliminating email as a communication tool — it requires connecting that communication directly to the formal systems it should be updating, so a resolution reached informally doesn’t stay invisible to everyone who isn’t part of that specific email thread. Teams that build this connection into their standard communication workflow consistently keep their RFI and submittal logs closer to reality, reducing the redundant follow-up, confusion, and field decisions made on outdated information that a disconnected communication process reliably produces.
