You can have a perfectly organised internal document library. Named correctly, filed correctly, version-controlled. Then someone asks you to send a specification to a subcontractor for review, and the whole thing unravels.

External review is the stress test that most document control systems fail. Not because the people are careless, but because the process demands things that file-based workflows can’t deliver.

The email loop

Here’s what usually happens. A project manager exports a specification as a PDF or Word file. They attach it to an email, add a note asking for comments by a certain date, and send it to the reviewer. Maybe they CC a colleague. Maybe they don’t.

The reviewer opens the attachment, marks it up, and sends it back. But the project manager is out that day, so the reply sits in their inbox. Meanwhile, a second reviewer sends their comments to a different email thread. A third reviewer prints the document, scribbles notes in the margins, and hands it to someone who scans it and emails it back as a new PDF.

Now there are three sets of comments, in three different formats, across multiple email threads. Nobody has a consolidated view. Nobody knows whether all the comments have been addressed. And if the specification changes while the review is in progress, there’s no way to tell whether the reviewers were commenting on the current version or an earlier one.

This is a regular occurrence. Research from zipBoard found that markups routinely get lost in email threads, version control becomes impossible when documents bounce between parties, and critical feedback falls through the cracks when there’s no centralised tracking.

What goes wrong, specifically

The problems with email-based review aren’t theoretical. They’re predictable and repeatable.

Comments get lost. When feedback comes in via email, it depends on someone manually collating all the responses. If a reply goes to the wrong thread, or gets buried under other project correspondence, it disappears. On a busy project with multiple concurrent reviews, this happens regularly.

Version confusion is the next problem. If the specification is updated while a review is in progress, the reviewer’s comments may apply to text that no longer exists. Worse, the reviewer might not know the document changed. They submit comments against an old version, and whoever processes the feedback has to figure out which comments are still relevant and which have been overtaken by changes.

There’s no status tracking either. Once a document is sent for review, the sender has no visibility into whether it’s been opened, whether comments are in progress, or whether the reviewer is waiting for clarification. The only way to check is to send another email asking for a status update. Autodesk’s construction research found that construction professionals spend 35% of their time on non-optimal activities, much of it chasing information that should be visible without asking.

And access persists after the review is done. When you email a document to an external party, they have a copy forever. There’s no expiration, no revocation. If the specification is subsequently updated, they still have the old version. On projects with confidentiality requirements, this is a problem. On projects where specifications carry contractual weight, it’s a bigger one.

The RFI bottleneck

Review comments often generate requests for information (RFIs) that need formal responses. In a file-based workflow, these get managed through yet another layer of email or a separate RFI tracking system that isn’t linked to the specification itself.

A study cited by Navigant Consulting found that responding to a single RFI costs construction firms an average of $1,080, and RFI delays can add up to 10% to a project’s total duration. When RFIs are disconnected from the specification sections they relate to, it takes longer to understand the context, longer to draft a response, and longer to close them out.

The average response time for an RFI is 9.7 days. On a project with dozens of active RFIs, that’s not a minor scheduling concern.

What external review actually needs

The requirements aren’t exotic. They’re just incompatible with email.

A reviewer needs scoped access to a specific document, not your entire project folder. They need to be able to comment on individual sections with clear status tracking, so both sides know what’s been raised, what’s been addressed, and what’s still open. The document owner needs a consolidated view of all feedback, not a pile of annotated PDFs from different sources. And when the review is done, access should expire without anyone having to remember to revoke it.

On projects where specifications are composed from reusable template blocks, the review process can be more targeted. Instead of sending an entire 200-page specification for review, you can scope the review to the sections that actually changed or that the reviewer is qualified to comment on. The reviewer sees less, focuses better, and the feedback is tied to specific content rather than floating in an email attachment.

Why it matters beyond convenience

External review is also a compliance problem. On projects where specifications carry regulatory or contractual weight, the review record matters.

If a specification is later disputed, you need to show that it was reviewed, by whom, and what comments were raised and resolved. An email trail can technically provide this, but reconstructing it months after the fact is painful. Anyone who has tried to piece together a review history from a project manager’s inbox during a contractual dispute knows how unreliable that process is.

A structured review workflow with timestamped comments, clear status tracking, and automatic access expiration gives you an audit trail without extra effort. It also means that when someone asks “was this section reviewed before it was issued?” the answer is verifiable in seconds, not hours of inbox archaeology.

The pattern

External review exposes the gap between where your documents live and how your team actually works with external parties. If your internal document control is file-based, every external review becomes an export, a detachment from version control, and a manual reconciliation exercise when the comments come back.

That gap isn’t something you can fix with a better naming convention or a stricter email protocol. It’s structural. The process needs to support external collaboration without losing control of the document, and file-based systems don’t do that.