The four-question test
- 1. Is it frequent? A task done twice a year rarely repays automation. Rule of thumb: annual hours spent must comfortably exceed build plus yearly maintenance hours.
- 2. Is judgment the job? Tasks where the value is the judgment — negotiation, hiring, sensitive customer issues — automate the paperwork around them, not the decision.
- 3. Is the process stable? Automating a process that changes monthly means rebuilding monthly. Stabilize first, automate second.
- 4. What does failure cost? If a silent error means lost money, legal exposure, or angry customers, the recovery design may cost more than the automation saves.
Clear no-go signals
- The process owner can't describe the current manual steps precisely.
- Exceptions outnumber the standard path.
- The underlying system has no API and changes its interface often.
- Nobody wants to own the automation after it's built.
What to do instead
For tasks that fail the test: document the process as a checklist, build a template or calculator that assists the human, or fix the process before considering automation. A good checklist beats a bad automation every time.
Assumptions and limits
- Framework is guidance; edge cases exist in both directions.
Common questions
How do I know if a task is worth automating?
Estimate annual manual hours, multiply by a realistic hourly value, and compare against build cost plus yearly maintenance. Then apply the four-question test — frequency, judgment content, process stability, and failure cost. If any answer is weak, don't automate yet. A task done twice a year rarely repays automation, and annual hours spent must comfortably exceed build plus yearly maintenance hours.
Should I automate a process that keeps changing?
No — stabilize it first. Every process change becomes a rebuild of the automation, and the maintenance burden quickly exceeds the original manual cost. Automate the stable core; leave the changing edges manual. The test on this page treats stability as a precondition: exceptions should not outnumber the standard path, and the process owner should be able to describe the manual steps precisely.
What tasks should never be fully automated?
Tasks where human judgment is the value (hiring, negotiations), where errors are catastrophic and hard to detect, and where the human touch is the product (high-trust customer relationships). Automate around these, not through them. For tasks that fail the test: document the process as a checklist, or build a template or calculator that assists the human instead.
Published · Updated . Automation planning guides for founders and developers. Models are planning tools, not guarantees.