Automation field notes
How Long Does Business Process Automation Take? From Workflow Audit to Production
A one-workflow automation moves from discovery and access through prototype, exception testing and controlled rollout; the schedule depends more on permissions and review than on a demo.
How long should you plan for?
Plan in stages rather than treating a prototype date as a production date. For planning only, the illustrative stage ranges below add to roughly 11–32 business days if completed sequentially. They are not a GLCO estimate or delivery commitment: they assume one bounded workflow, a named process owner, usable sample records, an existing system with suitable integration access, and reviewers who can respond promptly. Some work can overlap; vendor approvals, procurement, security review, or a second system can extend the calendar substantially. Agree actual scope and schedule directly after the workflow and dependencies are known.
| Stage | Illustrative working time | What must be ready before moving on |
|---|---|---|
| Discovery and workflow audit | 1–3 business days | Owner, sample inputs, current steps, exceptions, measurable acceptance criteria |
| Permissions and data access | 2–10 business days | Approved account roles, test environment, provider terms and data-handling decision |
| Prototype | 3–7 business days | A narrow happy path plus review queue, with no unattended external action |
| Testing and revision | 3–7 business days | Realistic cases, failed inputs, duplicates, handoff rules and owner sign-off |
| Controlled rollout | 2–5 business days | Limited users, monitoring, rollback path, training and support owner |
Discovery: define a boundary before building
A workflow audit should end with one trigger, one source of truth, a destination, a human decision point and a definition of done. Walk a recent item from arrival through correction and completion; note the variants that currently require judgment. Count current handling time and error or rework frequency before changing the process, then choose acceptance measures such as accurate field extraction, exception capture and time to reviewer decision. If nobody owns the exceptions, the workflow is not yet scoped for automation.
- Bring a sanitized example of a normal item and one that required correction; do not put passwords or customer records in a contact request.
- Name the person who can approve process changes and the person who will operate the workflow after launch.
Further reading: How GLCO scopes and hands off a project
Permissions: the access path can set the calendar
Permissions are a separate delivery dependency, not a coding detail. Confirm who can authorize each connection, whether the existing software supports an approved API or export, what data may enter a model or outside service, and whether a nonproduction environment is available. Prefer least-privilege service access and a test dataset with sensitive fields removed where possible. If a provider blocks the needed access or the data policy rules out a proposed route, redesign around an approved export or manual review rather than rushing credentials into an unsafe workaround.
- Identify the account administrator and security or privacy reviewer before scheduling integration work.
- Record what the automation may read, write, retain and send; approval of each action is part of the scope.
Prototype: prove the handoff, not just the happy path
A prototype should take a realistic input, create a traceable proposed result and show a reviewer what needs attention. For a document workflow, that may mean extracting fields into a draft record with source references and confidence or validation flags. It should not silently commit payments, send customer messages or overwrite authoritative data. Demonstrate how the user corrects a bad extraction and how the corrected record reaches the destination; otherwise the demo has not tested the working process.
Further reading: Technical example: reviewed invoice extraction and AP reconciliation
Testing: make exceptions visible before sign-off
Production readiness requires testing on cases the prototype was least likely to handle: duplicates, missing fields, unusual formats, conflicting records, access failures and a destination outage. Define which cases stop automatically, which can be corrected by a reviewer, and how to retry without creating a duplicate action. Have the process owner check the results against the acceptance criteria, not against whether the screen looks convincing. A failure without an owner or recovery path is a reason to delay rollout.
- Keep a small review set with expected outcomes and record false positives, omissions and time spent on corrections.
- Test the same item twice and a failed destination write; verify that the team can identify and reconcile the result.
Rollout: start narrow and keep a return path
A controlled rollout starts with a limited set of users or records and a named person watching failures, review load and downstream results. Agree a pause or rollback condition, operating instructions, access ownership and the handoff to support before increasing volume. If the workflow involves approvals or external communications, preserve the human approval step until the owner explicitly accepts any change in authority. The first successful run is a milestone, not the end of operational responsibility.
What would a single-workflow calendar look like?
Consider a hypothetical small business that receives emailed PDF invoices and enters approved amounts into its accounting system. Discovery maps receipt, purchase-order comparison and the finance approver. Access waits for a sanctioned mailbox connection, an accounting-system test account and a decision about where invoice data may be processed. The prototype extracts a draft and flags mismatches; testing uses duplicate invoices, incomplete purchase orders and unreadable scans; rollout lets finance review proposed entries before posting. The stage ranges above are a planning exercise for this illustrative workflow, not a report of a GLCO client or a promise of delivery. If approval for the accounting connection takes three weeks, the calendar shifts even if the prototype itself is quick.
- A simpler approved CSV export can reduce integration scope, but it adds a manual handoff to maintain.
- Multiple entities, legacy access, changing policies or unclear approval authority should be scoped as separate dependencies rather than hidden in the same estimate.
How do you request a credible schedule?
Ask a provider for a stage-by-stage plan that names assumptions, decision owners, access prerequisites, test cases, sign-off criteria and the support handoff. Compare proposed delivery dates only after separating elapsed waiting time from implementation work and stating what happens if access or sample data arrives late. GLCO confirms project scope, fee and delivery schedule directly; a contact inquiry starts a conversation, not a booked or purchased project.
- Describe one workflow, the software it touches, approximate input volume, the exception you most worry about and who can approve access.
- Ask what evidence will show that the workflow is ready for a limited production release.
Further reading: Pricing and scope conversation·Compare project cost drivers