Automation
A process is ready to automate when it is stable, documented, high enough in volume to repay the work, and its systems can be reached programmatically. If any of those is missing, fix it before building anything.
In order
If the process changed in the last quarter or is being redesigned now, automation will freeze a version you are about to replace and make further change harder. Wait until the shape has settled.
Someone should be able to describe every step, every decision point and every exception. Where two people describe the process differently, that disagreement is the real first problem: automation will simply encode one version and break for the other.
Frequency times time saved, against build cost plus ongoing maintenance. Be honest about maintenance: an integration is not finished when it ships, and a process automated at the interface layer needs watching indefinitely.
Do the systems involved offer APIs or webhooks, or would this mean driving screens? Screen-driven automation is legitimate as a deliberate bridge and expensive as a permanent architecture. Confirm too who owns credentials and what happens when they rotate.
Stop and resolve it. That disagreement is the actual problem: automating one version encodes it as correct and the process will break for everyone following the other.
Not strictly (screens can be driven), but without them the automation is fragile and needs permanent maintenance. Treat that route as a deliberate bridge with an owner, not as the destination.
A process is ready to automate when it is stable, documented, high enough in volume to repay the work, and its systems can be reached programmatically. If any of those is missing, fix it before building anything.
You have read what we think. If you want to know what it means for your case specifically, describe it and we will tell you which parts of automation readiness checklist actually apply — and which do not.
