An ISO automation timeline isn't a fixed number a vendor can hand you before seeing your document control process. It's set by three variables: how many processes and document types you're automating, how many sites are in scope, and how mature your existing documentation already is. Change any one of those and the timeline moves.
That's not a dodge. It's the honest structure of the problem, and understanding it gets you a more useful answer than a guessed week count ever would.
The three variables that set an ISO automation timeline
Process count
Each document-control process — new document, revision, cancellation, controlled copy, uncontrolled copy — has its own rules, fields, and edge cases. Automating one cleanly is a contained project. Automating five means five sets of logic tested against your SOPs, all passing acceptance criteria before anything ships. Scope grows roughly with process count, sometimes faster where processes interact: a cancellation has to update the same master document list a revision does, so the two can't be built apart from each other.
Site count
A single-site build has one set of physical folders, one document controller's workflow, one distribution matrix. Add a second facility and you're not doubling the work — you're reconciling however each site actually runs document control today, which is rarely identical even under the same certificate. Multi-site scope also raises the stakes on testing, because a mistake in shared logic now touches more than one facility's live registers.
Documentation maturity
This is the variable people underestimate most. If your SOPs describe your process accurately and consistently, a build can be derived directly from them — the fastest, lowest-risk path, and the one we always prefer. If your SOPs are outdated or contradict each other, that gap has to be resolved before automation logic can be written against it. Automating a process nobody actually follows produces a system nobody trusts. Closing that gap is real work, and it belongs to your team as much as ours — only the people running the process know which version is current.
Size your own project before the call
| Factor | Smaller, faster-moving scope | Larger, slower-moving scope |
|---|---|---|
| Process count | One or two processes first (revision + cancellation) | All five processes in one build |
| Site count | Single facility | Multiple facilities with differing local practice |
| Documentation state | SOPs current and followed as written | SOPs outdated or contradictory |
| Register backend | Existing spreadsheet maps directly | Registers need restructuring first |
| Gate structure | Approval gates map cleanly onto the four-gate model | Approval steps are informal or inconsistent across departments |
| Stakeholder availability | QMR and DCC can walk the SOP with us directly | Reviews are hard to schedule or spread across many people |
Nothing in that table promises weeks or months. It's a way to see, honestly, which side your own operation sits on before you ask for a number.
What a scoping conversation establishes
Before we can give you a real estimate, we need your process count, site count, and documentation state — applied to your actual SOPs, not a hypothetical. That's what a scoping call is for. We walk through what ISO automation will and won't touch, look at your registers and approval structure, and identify where your documentation is solid enough to build on versus where it needs reconciliation first.
That conversation also covers cost, a separate question that gets asked in the same breath. We can talk through how implementation cost compares to a document controller retyping the same eight fields into six registers every revision, and how that compares to certification body fees you're already paying regardless. What we won't do, on that call or anywhere else, is hand you a number before we've scoped your process. A quote given blind is a guess with a currency sign on it.
Signs your deployment will move faster
- A single, well-defined process first. Automating revision control cleanly and expanding from there beats automating everything at once.
- SOPs that already reflect reality. If what's written down is what people actually do, logic can be derived directly instead of negotiated.
- A gate structure that's already explicit. If your reviewer, approver, and sign-off steps are already defined, mapping the four decision gates onto them is straightforward.
- One register backend, not several competing ones. Fewer places the same information lives means less reconciliation before automation can sit on top.
- A DCC or QMR who can walk us through the process directly. Firsthand knowledge, not a summary of how it's supposed to run, shortens scoping considerably.
Signs it will take longer, and that's fine
The opposite conditions aren't a disqualifier — they're a bigger project once it's done. Multiple sites with different local practice, SOPs that need reconciling before they can be automated, or five processes in scope at once are all legitimate starting points. They just mean the honest estimate is larger, and scoping takes longer to get right before implementation starts.
FAQ
Can you give me a rough timeline range without a scoping call?
Not an honest one. Timeline depends on process count, site count, and documentation maturity — none of which we know about your operation until we look at it.
What's the fastest way to get a real estimate?
A scoping call where you bring your current SOPs, your existing registers, and a sense of how many sites and processes you want covered. That's the same information that determines cost, so it's worth doing once, thoroughly.
Does messy documentation disqualify us from automating now?
No. It means the project includes reconciling your documentation before automation logic gets built on top of it. That's more common than clean documentation, not less.
Do you quote a fixed price upfront?
No. Pricing is shared only after scoping, because quoting blind means guessing at your process count, site count, and documentation state — the same three things that determine cost.
Should we start with one process or automate everything at once?
Starting with one well-defined process — often revision control, since it's the highest-frequency event — is usually lower risk, with the other processes added once the first is proven against your acceptance criteria.
If you want an honest estimate instead of a guessed one, request a scoped quote and bring your current SOPs and registers to the conversation. 1% EVO scopes every deployment against your real document count, site count, and SOPs before naming a number, not before.