.png)
Most content about automation consulting is written for people who want to become automation consultants. This post is not that.
This is for the COO, VP Operations, or Operations Director who is evaluating whether to bring in an automation partner, and wants to know concretely: what do you actually get, month by month, if you sign with one?
Not the pitch. The deliverables.
The majority of automation engagements are structured as projects. You define a scope, the firm builds it, they hand it off, you maintain it. That model works for a one-time need.
The limitation: it does not build a program.
A program is what happens when you have an automation engineer running continuous discovery, building in prioritized sequence, and compounding the infrastructure from one workflow to the next. That is what this post describes.
If you are reading this because you are evaluating a one-time project for a specific workflow, the project model may be exactly what you need. If you are reading this because you want automation to become an ongoing operating advantage and not a series of isolated improvements, the ongoing model is worth understanding.
Every firm that sells ongoing automation consulting talks about "continuous discovery." This is what it should mean in practice:
The automation engineer spends structured time each week (roughly 20% of engagement hours) doing three things:
The output of discovery is a prioritized backlog. Not a wishlist. A ranked queue with a dollar-value estimate attached to each item, ordered by margin impact.
That backlog should be visible to you at all times. Not as a deliverable in a quarterly review, but as a living document that your automation partner updates each week.
Discovery: The engagement starts with two to three weeks of structured interviews and system review. The goal is to surface the top five to ten automation candidates, score them for readiness, and identify the one that is highest-ROI and most ready to build.
"Most ready" means: the process is documented, the data is accessible via API, there is a named internal owner, and the expected output is clearly defined.
Build: One workflow in production by the end of month one. Not a proof of concept. Not a sandbox demo. A workflow running in your production environment, handling real transactions.
For most manufacturers, this first workflow is either:
What you should see: A working automation, a runbook documenting how it operates and what to do when it fails, and a preliminary measurement baseline (time per transaction before automation, benchmark for comparison at month three).
What to watch for: If the first workflow is not in production by the end of week five, the engagement is behind and the reason needs to be addressed. Common causes: missing ERP API credentials, undocumented process logic that surfaces late in the build, or internal owner not engaged.
Refinement of workflow one: The first month in production will surface edge cases that were not visible during scoping. The automation will encounter invoice formats it was not built for. The ERP will return data in an unexpected structure. A supplier will send a PO acknowledgment via a new channel.
Month two is where the build gets hardened. Edge cases get handled. The exception paths get tested with real scenarios. The runbook gets updated.
This is not failure. It is how production automation works. A workflow that handles 80% of cases correctly on day one and gets tuned to 97% by week eight is a success. A workflow scoped to handle every edge case upfront before launching is a workflow that never ships.
Discovery continues: While workflow one is being refined, the engineer is continuing discovery on the next priority. By the end of month two, workflow two is scoped, the ERP API connections for it are confirmed, and the build is ready to start.
What you should see: Workflow one handling the majority of transactions without manual intervention. A documented exception rate that is declining week over week. Workflow two scoped with a defined trigger, logic, and output.
Measurement: Three months of data is enough to calculate real ROI on workflow one. The measurement is straightforward:
If workflow one was AP matching and it recovered four hours per week for a $45/hour AP clerk, the annual value is $9,360. That is from one workflow.
Workflow two in production, workflow three scoped: By month three, a well-running engagement has two workflows live and a third in the build pipeline.
The compounding effect starts to show here. Workflow two often uses the same ERP API credentials as workflow one. The n8n instance is already deployed. The Retool dashboard, if used, is already live. The infrastructure cost of the third and fourth workflows is lower than the first because the foundation is already in place.
What you should see: A documented ROI calculation for workflow one. Workflow two live with the same monitoring and runbook approach. Workflow three in active build.
By the time an ongoing engagement reaches month six, a well-run program looks like this:
The ROI curve on ongoing automation is not linear. The first workflow requires the most overhead: API credentials, environment setup, testing protocols, documentation standards. Each subsequent workflow builds on what already exists. By workflow five or six, the marginal cost of a new workflow is significantly lower than the first.
This is why the comparison for ongoing automation is not "what does one workflow cost?" The comparison is "what does the operating advantage of a continuously growing automation program cost, relative to hiring a full-time automation engineer at $150,000 to $180,000 per year to build and run it?"
The engagement can only compound if three things are in place on your side:
An internal champion. Not an approver, a champion. Someone at the operations leadership level who cares about the program, reviews the backlog with the engineer regularly, and advocates for the workflows internally when they require buy-in from department heads. Without this, discovery stalls and prioritization decisions get made in a vacuum.
API access to the ERP. This is the technical dependency. If your ERP does not have a documented REST API, or if your IT team has locked down API credentials behind a multi-month procurement process, the program will be limited to non-ERP workflows until that is resolved. Get this sorted in month one.
An internal owner per workflow. Each workflow needs one person who understands what it does, monitors the exception queue, and knows to escalate when something is wrong. This does not require technical knowledge. It requires domain knowledge and accountability. One owner per workflow. No owner = no adoption.
At the end of a well-run 12-month engagement:
The transition at month 12 is a strategic choice: continue the program with the external partner, transition to an internal hire who takes over the engineer's role, or move to a reduced maintenance arrangement while the internal team absorbs what was built.
All three are valid. The important thing is that at month 12, you have something real: a program with measurable ROI, not a series of projects with sunk costs.
The Flow Kaizen guide covers how to scope a first workflow, how to run the readiness audit, and how to structure the first conversation with an automation partner so you know what to ask and what answers should raise flags.
.png)
