What a 915-Submittal Mixed-Use Project Reveals About the Limits of Excel and Email
.png)
I managed a mid-rise mixed-use project in Brooklyn, NY that generated 915 submittals across 21 spec sections. We're talking commercial space, 250 hotel rooms, and 65 residential units stacked across 16 floors. We tracked everything in Excel and coordinated reviews through email, which worked fine for the first few months. Then it didn't.
Mixed-use projects create submittal complexity because different program types hit peak coordination at different times. Hotel MEP systems follow different review paths than residential units. Commercial tenant work overlaps with base building systems. You're not managing one clean sequence... you're juggling parallel streams that all share the same structural, envelope, and core infrastructure dependencies.
Project Overview
What Actually Broke
What actually broke was version control, reviewer accountability, and any sense of who was looking at what. The Excel log handled status tracking when submittal volume stayed low. By month four in during superstructure, we had 55 submittals in concurrent review. The spreadsheet became this forensic exercise where you'd spend 20 minutes trying to figure out which version the MEP consultant actually reviewed. Did the structural engineer see the revised embed schedule before or after the concrete sub resubmitted? When someone replied to an email thread from three weeks back, that response lived in one person's inbox while everyone else worked from old information.
Version confusion accumulated in ways that felt inevitable once you were in it. A mechanical submittal would reference a structural detail that was under revision. The structural detail would get approved, but the mechanical engineer was reviewing against the old version because nobody closed the loop. We'd discover the mismatch when the mechanical contractor fabricated to the wrong dimension. That's rework driven by information lag, not design error.
Email review threads broke down when concurrency increased. At 10 submittals in review, email works fine. At 55, it doesn't. Architects would respond to submittals out of sequence. Consultants would review outdated packages because they missed a revision notice buried in a separate thread. Our project engineer spent hours each week just reconciling what had actually been reviewed and by whom. We estimated that roughly 75% of submittals got approved on first pass, 20% needed one revision, and 5% needed two or more. But I'm being honest here... those percentages are based on team experience, not exact logs, because our tracking system couldn't reliably capture revision history once email threads fragmented.
Dependencies between early structural approvals and downstream MEP coordination created the worst friction. Concrete embeds had to be locked before mechanical hangers could be detailed. If the structural submittal cycled through revisions, every downstream trade just waited. Excel can't represent those dependencies. We knew they existed (you always know), but the log showed everything as independent line items with due dates. When structural submittals dragged, the mechanical and electrical teams didn't get automatic alerts. They found out when they asked why their submittals were sitting in "pending review" status for weeks.
The failure wasn't about people making mistakes. The failure was about using tools that can't represent workflow state, reviewer accountability, or dependency chains. Excel is a ledger. Email is a message transport. Neither one is a workflow engine, and pretending they are just creates more work.
Why the Failure Was Structural
Why the failure was structural comes down to this: email can't enforce process. When you send a submittal for review via email, you've created a request. You haven't created accountability. If the reviewer doesn't respond, you send a follow-up email. If they respond to the wrong version, you send a correction. If they lose the attachment, you resend it. Every failure mode requires you to manually intervene because email has no concept of state. A submittal isn't "in review" in any system. It's just mentioned in an email that may or may not have been read.
Excel can't represent dependencies between tasks. You can add a column for "predecessor submittal," sure. But that column is just text. The column doesn't stop you from marking a dependent submittal as submitted when its predecessor is still under revision. The column doesn't alert anyone when a predecessor cycles back to the contractor for resubmission. The dependency exists in your head and in hallway conversations, but not in the tracking system where it needs to live.
Concurrency amplifies small delays into cascading rework. If you've got five submittals in review and one gets delayed, you adjust. If you've got 55 submittals in review across multiple floors and program types, a delay in one creates a chain reaction. Mechanical submittals that depend on structural approvals sit idle. Electrical coordination that depends on mechanical routing gets pushed. By the time the structural issue resolves, you've lost two weeks across a dozen downstream submittals. That delay converts to real cost when trades get remobilized or when work sequences get compressed to recover schedule.
Where Submittal Software Fits
Submittal software exists because the tools we used (Excel and email) weren't designed for workflow management at scale. Dedicated submittal platforms replace status tracking with state management. A submittal isn't just a row in a spreadsheet with a due date. The submittal is an object with a defined state: draft, submitted, in review, approved, rejected, resubmitted. The system enforces transitions between states and logs who moved the submittal and when.
These platforms replace email threads with structured review workflows. When a submittal enters review, the system notifies the responsible reviewer, tracks whether they've opened the submittal, and escalates if they don't respond within a defined window. Reviewers work inside the platform, so their comments and markups attach to the submittal itself, not scattered across email inboxes. When someone uploads a revision, the system creates a new version and notifies everyone on the review path. There's no ambiguity about which version is current.
Dependency tracking becomes explicit in submittal software. If submittal B can't proceed until submittal A is approved, you define that relationship in the system. When submittal A gets rejected and cycles back for revision, submittal B's timeline updates automatically. The mechanical PM doesn't need to ask why their hangers are delayed. The system shows them that the structural embeds are still in revision.
Visibility across teams improves because everyone works from the same dataset. The architect sees the same submittal status as the contractor and the owner's rep. When someone asks where a submittal stands, the answer lives in the system, not in someone's email or in their memory of a conversation that happened in the trailer two days ago.
The category includes several platforms, each with different feature sets and interfaces. We've used SubmittalLink on more recent projects and found it handles the core workflow problems (state management, version control, and dependency tracking) without requiring extensive configuration. But the point isn't to advocate for one tool. The point is that dedicated platforms solve a specific class of coordination problems that Excel and email simply can't.
When Software May Not Be Necessary
Software may not be necessary for small projects with low submittal volume. If you're managing 50 submittals over six months with a tight team, Excel and email might be sufficient. The coordination overhead that breaks those tools at scale doesn't apply when concurrency is low and dependencies are straightforward. The decision depends on project complexity, not just project size. A $10M lab renovation with complex MEP coordination might justify submittal software, while a $30M ground-up office building with simple systems might not.
What Changed
What changed wasn't that we needed better spreadsheets or more disciplined email habits. What changed was recognizing we were using the wrong category of tool. Submittal coordination at scale requires workflow management, version control, and dependency tracking. Those capabilities don't exist in Excel or email. They exist in dedicated platforms, and the cost of not using them (measured in rework, schedule delays, and coordination time) exceeded the cost of the software itself.
If you're managing more than 200 submittals or dealing with high concurrency across parallel work streams, the question isn't whether you need dedicated tools. The question is which one fits your team's workflow and how quickly you can get it implemented before coordination overhead compounds into real cost.
Common Questions
At what project size does Excel actually stop working for submittals?
Excel stops working when you hit sustained concurrency, not a specific submittal count. If you're managing 15 submittals at once across multiple trades with dependencies, you'll feel it break. If you're managing 200 submittals sequentially over 18 months with minimal overlap, Excel might hold up. The breaking point is parallel review streams, not total volume.
Can you fix the Excel problem by just being more disciplined about naming conventions and folder structure?
No. Better naming conventions help, but they don't solve the core issue. Email still can't enforce workflow. Excel still can't represent dependencies or state transitions. You're just making a broken system slightly more organized, which means the failure happens a little later instead of not happening at all.
Is it worth switching tools mid-project if you're already deep into Excel and email?
It depends on how much runway you have left and how bad the coordination pain is. If you're six months from closeout and things are messy but manageable, you might ride it out. If you're 12 months from closeout and already losing submittals in email threads, switching now saves you from compounding that pain through closeout. Most platforms let you import existing logs, so you're not starting from zero.
What's the actual time cost of managing submittals manually at this scale?
Our project engineer spent roughly 10 hours a week just reconciling submittal status, tracking down reviewers, and clarifying which version was current. That's 25% of their time on administrative reconciliation instead of coordination or problem-solving. Multiply that across a year and you're looking at 500+ hours that could've been spent on actual project work.
Ready to stop losing submittals in email threads? See how SubmittalLink handles workflow, version control, and dependencies without the complexity of enterprise platforms.