Multi-site ISO automation means running the same document-control logic — the same decision gates, the same register, the same numbering scheme — from one backend that every facility reads from and writes to, so revision history never splits by site. It does not mean one facility's approver can sign off a document that belongs to another facility, and it does not mean every site suddenly shares one identical distribution list.
Most manufacturers with more than one facility don't design their document control for multiple sites on purpose. It grows that way — one register per plant, one document controller per plant, each keeping their own spreadsheet the way their predecessor set it up. It works, until it doesn't, and the failure mode is always the same: two sites end up with different revisions of what's supposed to be the same controlled document, and nobody notices until an auditor cross-checks them side by side.
What breaks first when document control spans multiple facilities
A single-site document register has one failure point: the person maintaining it. A multi-site setup has that same failure point, multiplied, plus a second one that single-site operations never have to think about — synchronization.
The typical pattern looks like this:
- Site A's document controller updates the master list after a revision, site B's controller finds out by email, sometimes late, sometimes not at all
- Each site numbers revisions independently, so "Rev 4" at one plant and "Rev 4" at another plant can be different documents entirely
- Distribution matrices are copied and re-copied by hand between sites, drifting a little further from each other every cycle
- When a document is cancelled at one site, the controlled copy at the other site sometimes just keeps circulating, because nobody sent the memo
None of this is a training problem. It's a structural one — spreadsheets and paper forms don't have a mechanism for keeping two locations in sync, so the burden of synchronization falls entirely on whoever remembers to send the update. That's not a resilient system design; it's a hope-based one.
What multi-site ISO automation fixes
An ISO automation system fixes this by making synchronization structural instead of manual. Every site's document events write to the same register and the same master document list. There is one revision counter per document, not one per site. A revision written at Site A is the same revision Site B sees, immediately, because there was only ever one place it could be written.
This is the same architecture used for a single facility — it just means the backend isn't scoped to one plant's spreadsheet. The master document list becomes the shared reality across every site, and each facility's distribution matrix is a column or a filtered view on that shared list, not a separate, hand-maintained copy of it.
Practically, this means:
- One document register, with a site or department field on every row — not one register per site
- One numbering scheme, so a revision number means the same thing everywhere it appears
- One activity log, so an auditor tracing a document's history sees every event across every facility in one place, in order
- Site-specific distribution lists, generated from the shared master list rather than maintained as independent files
How the four decision gates hold up across facilities
Preserving human decision gates gets more important, not less, once more than one site is involved — because the temptation with multi-site rollouts is to centralize the decision-making along with the register, and that's a different (and riskier) change than centralizing the record-keeping.
The gates should stay local to where the document actually lives and gets used. A reviewer at Site A reviews Site A's change requests. An approver at Site B approves Site B's document adequacy. What changes with automation isn't who decides — it's that once a decision is recorded, the clerical consequences propagate to the shared register automatically instead of depending on someone remembering to update a second spreadsheet at a second location.
This is the same pattern we used building the reference automation for a Thai manufacturer operating two ISO 9001:2015-certified facilities. The four gates — reviewer sign-off on the change request, approver check on content adequacy, and the combined final gate covering master and external/support document sign-off — stayed exactly where their SOPs already placed them. The automation didn't move a single decision between people or between sites. It only removed the retyping that used to happen after each decision, across both facilities, into one shared set of registers instead of two separate ones.
Single-site vs multi-site document control
| Single-site manual | Multi-site manual | Multi-site automated | |
|---|---|---|---|
| Document register | One spreadsheet | One spreadsheet per site | One shared register, site-tagged |
| Revision numbering | Consistent by default | Can drift between sites | Enforced identical across sites |
| Distribution updates | Manual, one list | Manual, multiple lists, easy to miss one | Generated from shared master list |
| Audit trail | One paper trail | Multiple, inconsistent formats | One activity log, all sites, in order |
| Who approves content | Local reviewer/approver | Local reviewer/approver | Unchanged — still local, still human |
What doesn't change with more sites
The judgment layer doesn't scale by site — it multiplies by it, and that's correct. Adding a facility should never mean fewer people are checking content adequacy; it means more clerical work is happening in parallel, which is exactly the layer that should be automated rather than the layer that shouldn't.
A system that lets one site's sign-off silently apply to another site's documents, or that lets an algorithm decide a change is "the same as last time" across facilities without a local human checking it, has crossed from clerical execution into judgment. That's the line that should never move, no matter how many sites are on the same backend.
FAQ
Does multi-site automation mean one person approves documents for every facility?
No. Each site keeps its own reviewer and approver, matching whatever your SOPs already assign locally. Automation shares the register and the audit trail — not the decision-making authority.
Can two sites use different revision numbering schemes on a shared system?
They can, but it defeats the purpose. The value of a shared backend is that a revision number means the same thing everywhere it's referenced, which is why the numbering scheme should be standardized once, at setup, across all sites.
What happens if one site cancels a document that's still controlled at another site?
That's exactly the failure case a shared register is built to prevent. A cancellation event writes once, to the shared master list, and every site's controlled-copy status reflects it immediately — instead of depending on someone remembering to notify the other plant.
Do all facilities need to be on the same automation platform?
They need to write to the same register and master document list. Our reference build uses n8n with Google Sheets as that backend because it matched the manufacturer's existing infrastructure — the platform should fit what you already run.
Is this harder to set up than single-site automation?
It takes longer to map, because there are more existing SOPs and local variations to reconcile before the register can be shared safely. The underlying mechanism — automate after the decision, not instead of it — doesn't change.
If your facilities are already running different versions of the same register by accident, that's worth seeing mapped out rather than described. Book a free consultation with 1% EVO. Bring the document lists from each site; we open a running system and walk it through, live.