A realistic 30-day ISO automation pilot covers one document-control workflow, end to end, built from your actual SOP — not a partial demo and not your entire QMS. In 30 days you can scope, build, test, and hand over one real workflow with its human decision gates intact. You cannot, in that time, automate every register you own, retrain your whole document control process, or replace judgment work. Anyone offering the second list in 30 days is scoping for a sales call, not for your factory.
This matters because "pilot" gets used loosely. Some vendors mean a slide deck. Some mean a sandbox you'll never actually run on live documents. A pilot that's worth your document controller's time produces one thing: a working automation, verified against your own change-request forms, that you can watch run for real before deciding whether to extend it.
What an ISO automation pilot should mean
A pilot is not a smaller, faster version of the whole project. It's the whole project, scoped to one workflow instead of many. The difference matters because it changes what gets tested. If you automate one workflow properly — including the parts most vendors skip, like activity logging and idempotency — you learn everything you need to know about whether automation will hold up under audit. If you instead automate five workflows shallowly, you learn nothing about any of them, because none get the scrutiny a single real workflow gets in 30 days.
We scope pilots around a single controlled-document lifecycle: new document, revision, cancellation, controlled copy, uncontrolled copy. That's the same scope we used for our reference build for a Thai manufacturer — one workflow, derived from their existing written SOPs, covering the full lifecycle rather than a slice of it.
Week-by-week breakdown
| Week | Focus | Output |
|---|---|---|
| 1 | SOP mapping and gate confirmation | Documented decision gates, register fields, and folder structure matched to your actual process |
| 2 | Build | Working automation covering the full document lifecycle for one workflow |
| 3 | Verification | Test cases run against real (or shadow) document events; unrelated systems checked for zero impact |
| 4 | Handover | Activity log review, walkthrough with your document controller, sign-off against agreed acceptance criteria |
Week 1 — map the SOP, not a template
The first week is spent reading your actual change-request forms, your master document list, your amendment record, and your distribution matrix — not filling in a generic template. This is where the human decision gates in your process get documented precisely: who reviews, who approves, and what "approved" triggers downstream. If your process has four gates, the automation preserves four gates. If it has two, it preserves two. The automation is built to match what your SOP already says, not to impose a new process on top of it.
Week 2 — build against the real lifecycle
Building means wiring the automation to execute the clerical consequences of an approval — the parts document controllers currently retype by hand. In our reference build that meant eight fields written after final sign-off: revision number, effective date, amendment-record entry, master document list row, change-register entry, request number, page count, and retention/disposal date. Your pilot scope may differ slightly depending on your registers, but the principle holds — the system acts only after a human decision is recorded, never before.
Week 3 — verify, don't assume
This is the week most pilots skip, and it's the one that actually matters. Verification means running real or shadow document events through the workflow and checking two things: did the automation write what it should have, and did it leave everything else alone. In our reference build, verification included checking that all 51 pre-existing unrelated workflows on the same automation tenant were unchanged, and that the five original source documents were unchanged — same file IDs, names, formats, and modification times. That kind of check is what separates a pilot you can trust from one you're taking on faith.
Week 4 — handover, not lock-in
A pilot should end with you owning what was built, understanding how it works, and being able to run it without us. Handover includes walking your document controller through the activity log — every automated write should be individually traceable — and confirming the workflow against agreed acceptance criteria before anyone calls it done.
What a 30-day pilot does not include
Being clear about scope protects you from disappointment and protects the pilot from scope creep. A 30-day pilot does not include:
- Automating every register or workflow you run — one lifecycle, done properly, is the point
- Migrating historical records into a new system
- Replacing your QMS software platform
- Any judgment work — content adequacy review stays with your reviewer and approver, exactly as it does today
- A finished, permanent integration with every downstream tool you use — that's a scale-up conversation after the pilot proves out
If a proposal promises full-QMS automation inside 30 days, ask what gets skipped to hit that date. Something always does, and it's usually verification.
Why 30 days specifically
Thirty days is roughly the shortest window in which one workflow can be mapped, built, verified against real events, and handed over without cutting corners on any of those four steps. Shorter than that, and verification is usually what gets sacrificed — a vendor ships an automation that looks correct in a demo but hasn't been checked against your actual paper forms or your other live workflows. Longer than that, and you're usually looking at a scope that has quietly grown from one workflow to several, which is a different project with a different timeline.
The 30-day figure isn't a marketing number — it maps to the four phases above, one week each, with a small buffer built into weeks 2 and 3 for the SOP details that only surface once you're building against real documents instead of a description of them. Factories rarely have a change-request process that matches their written SOP exactly; there's usually a workaround someone added that never made it into the document. Finding that in week 1 or 2, rather than at handover, is part of what the timeline is for.
How to know if your pilot scope is realistic
Ask three questions before a build starts:
- Is it built from your SOP, or from a template? If nobody has read your actual change-request form, the automation will match somebody else's process, not yours.
- Does it preserve every decision gate you currently have? If gates get "simplified" during scoping, that's the judgment layer being touched — which it should never be.
- Is there a verification step that checks nothing else broke? Automation that isn't checked against your unrelated existing workflows is automation running on faith.
If the answer to any of these is unclear, the scope isn't realistic yet — it's aspirational.
FAQ
Can a 30-day pilot cover more than one workflow?
It's possible if the workflows are simple and closely related, but scoping two full lifecycles in 30 days usually means shortening verification on both. One workflow, fully verified, is a stronger pilot than two done halfway.
What happens after the pilot?
You decide whether to extend the same approach to other registers or workflows. Nothing is auto-renewed or auto-expanded — the pilot is scoped, delivered, and handed over as its own complete unit.
Do we need to pause our current manual process during the pilot?
No. A pilot is typically built and verified against real document events without requiring you to stop using your existing forms and registers until you've decided to switch over.
Will the pilot touch our other automations or spreadsheets?
It shouldn't, and that's exactly what week 3 verification checks — that everything outside the scoped workflow stays untouched.
Is the pilot priced separately from a full build?
Pricing isn't published here; it's discussed on a scoping call once we understand which workflow you want piloted and what your registers currently look like.
If you want a pilot scoped against your actual SOP instead of a generic timeline, book a free consultation with 1% EVO. Bring your current process; we map the 30 days against it before anything gets built.