Automation Planning Checklist
Work through this before you build. It will stop roughly half of your automation ideas, which is the point.
About half of what people want to automate shouldn't be. This checklist finds out which half before you spend a week on it.
Work through it honestly. A "no" isn't a failure — it's a build you didn't waste.
Read the workflow design principles · Request Your Free Systems Audit
Stage 1 · Should this be automated at all
- The process is documented. A written procedure exists and someone has followed it.
- It's stable. It has run the same way for at least four weeks.
- It's frequent. Enough executions that the build pays back within a reasonable period.
- It doesn't need judgement every time. Decisions can be written as rules.
- Failure would be detectable. You'd know it broke without a customer telling you.
- Someone owns it. A named person is notified on failure and responsible for the fix.
Any unchecked box means not yet.
The most common failure is the first. An undocumented process gets automated as the version someone imagined, and the exceptions become errors.
Stage 2 · Is it worth it
Rough arithmetic, but do it:
Time per execution: ____ minutes
Executions per month: ____
Monthly time spent: ____ hours
Estimated build time: ____ hours
Estimated monthly upkeep: ____ hours
Months to pay back: build ÷ (monthly time − upkeep) = ____
- Payback is under six months
- The process will still exist in a year
- The upkeep estimate is realistic, not zero
Automations are not free to own. Tools change, integrations break, requirements shift. Budget something for upkeep or you'll be surprised later.
If payback is over a year, the honest answer is usually to simplify the process instead.
Stage 3 · Have you simplified first
- Every step has been questioned
- Steps that exist for no current reason have been removed
- Duplicate data entry has been eliminated where possible
- The process is as short as it can be
Automating a ten-step process that should be six steps means building four unnecessary steps and maintaining them forever.
Simplification is free. Do it first, every time.
Stage 4 · Specify before building
- Trigger — the specific event, and where the data comes from
- Conditions — validation, filtering, deduplication rules
- Actions — what happens, in order
- Notifications — internal and customer-facing, separately
- Record updates — field mapping written as a table
- Follow-up — timing, condition, and timeout
- Stop condition — what makes it stop applying to a record
- Error handling — retry rule, escalation, logging, manual override
- Reporting — where success is visible, and where failure is
The last three are what separate something you can leave running from something you have to watch.
Stage 5 · The unhappy path
Write down what happens when:
- A required field is missing
- The same input arrives twice
- An external system is unavailable
- The run is interrupted halfway
- Ten executions arrive in a minute
- The data is present but wrong
If you haven't designed these, you haven't designed the automation — you've designed the demo.
Stage 6 · Build and test
- Built outside production
- Tested with real data, not invented examples
- All six acceptance tests run and recorded:
| Test | Result |
|---|---|
| Normal case completes correctly | |
| Missing field stops cleanly, no partial record | |
| Duplicate input creates no duplicate | |
| External system down: retries then escalates | |
| Ten consecutive runs all complete | |
| Stop condition correctly halts it |
- What it does not do is written down
Stage 7 · Before go-live
- Written approval for anything customer-facing
- Rollback procedure written
- Someone other than the builder knows how to switch it off
- Monitoring confirmed working
- First real execution supervised end to end
Stage 8 · After go-live
- Checked daily for the first week
- The person who owns the process knows it exists and what it does
- Documentation updated to reflect that this step is now automated
- Review date set for one month out
That last one catches the automations that work correctly but produce something nobody wanted.
When the answer is no
| Situation | Do this instead |
|---|---|
| Not documented | Document it. You may not want the automation afterwards. |
| Not stable | Wait. A moving process will outrun any workflow. |
| Low volume | Write the procedure, keep it manual. |
| Needs judgement every time | Support the decision — surface the information, don't make the call. |
| Failure wouldn't be detectable | Build the detection first. That may be the whole project. |
| Payback over a year | Simplify instead. |
None of these are permanent. They're a sequence.
The question worth asking first
Before any of the above: what happens if this doesn't get automated?
Sometimes the honest answer is "very little." A task that irritates you weekly but costs fifteen minutes isn't a build. It's fifteen minutes.
The automations worth having are the ones where the answer is a number — hours per month, errors per quarter, enquiries lost.
Half of what you want to automate shouldn't be. Finding out which half before you build is the point of planning.
Not sure whether a process is ready?
A free systems audit tells you which of your processes are ready, which need documenting first, and which should stay manual.