Automation readiness assessment and checklist
Assess process stability, ownership, data access, risk, and ROI before choosing workflow automation software.
Score the workflow before you automate it
Give one point for each statement you can support with a written answer. Four or five points suggests a bounded pilot. Two or three means document the gaps first. Zero or one means the process is not ready.
- Stable triggerThe same event starts the work most of the time.
- Named ownerOne person can approve rules and resolve failures.
- Accessible dataInputs and outputs can be reached through an API, export, email, or approved connector.
- Known exceptionsThe common failure and manual review paths are documented.
- Measurable valueVolume, manual time, review time, and failure cost have a baseline.
Why this step comes before tool selection
Automation moves work between systems and people. If the current process has unclear ownership, unstable rules, or missing exception handling, software can make the problem run faster and become harder to see. The goal is a workflow that is observable, reversible where possible, and owned by someone who can act on failures.
Do not automate a process that changes weekly or has no accountable owner.
Score the process before the product
Readiness depends on stability, volume, data access, reversibility, and consequence. A repetitive task with stable inputs and a clear owner is a stronger candidate than a rare task that requires judgment. Give each dimension a simple low, medium, or high rating. Start where repetition is high, exceptions are visible, and an incorrect action can be reversed without customer or financial harm.
Recognize a false automation candidate
Teams often nominate the task they dislike most, but frustration is not enough. A process may actually need policy clarification, better source data, or removal of an approval layer. If employees use different rules for the same request, capture those differences before encoding one version. Otherwise the project will convert unresolved disagreement into software behavior.
Define a go or no-go threshold
Proceed only when the workflow has a named owner, a stable trigger, an accessible system of record, a measurable baseline, and a tolerable pilot boundary. Defer when credentials cannot be separated from a personal account, exceptions exceed normal cases, or nobody can explain how to recover from a partial write.
Build the decision record
Write down the trigger, inputs, expected output, system of record, monthly volume, allowed delay, consequence of a wrong action, and the person who approves changes. Include credentials and data classifications without storing secrets in the document. This record becomes the basis for comparing platforms and reviewing future changes.
Run a bounded pilot
Use a narrow set of reversible records. Observe normal runs, duplicates, missing fields, expired credentials, destination outages, and manual overrides. Measure setup time, maintenance time, correction rate, and review time. Only expand the scope when the failure path is as clear as the happy path.
Review cadence
Review the workflow after the first week, first month, and whenever a connected system changes. Retire automations that no longer serve a named outcome. Keeping unused workflows active increases permission and continuity risk without producing value.
Turn the checklist into a pilot-ready scope
The $149 workflow teardown documents the current process, exception path, ROI assumptions, platform shortlist, and fixed pilot quote.