Most automation projects that disappoint were not badly built. They automated a task that was not ready: the steps changed every week, nobody owned the result, or the hard part was a judgement call that no rule could capture. A short test before building saves far more time than any tool choice.
Why readiness matters more than the tool
Automation copies a process exactly, including its gaps. If a task currently works because one experienced person quietly fixes problems as they appear, an automated version will run without that person and the problems will pass straight through.
So the first question is never "which tool?" It is "is this task understood well enough that we could hand it to a new teammate with written instructions?" If the answer is no, the next step is mapping and an SOP, not a build.
The six questions
Answer each one honestly for a single, specific task — for example "send the weekly status report", not "reporting".
- Does it happen often enough to matter? A task done twice a year rarely repays the setup and maintenance effort.
- Are the steps the same each time? If every run needs a different path, write down the variations first.
- Is the input predictable? Forms, fixed spreadsheets and structured emails automate well; free-text requests usually need a person to read them first.
- Can you state the decision rules? "Approve if under the budget limit and the vendor is on the list" is a rule. "Approve if it looks reasonable" is a judgement.
- Who owns the result? Someone must notice when it fails and be allowed to fix it.
- What happens when it goes wrong? If a wrong output is costly or hard to undo, plan a human review step before anything is sent.
Reading the answers
Five or six clear "yes" answers: a good candidate. Build a small version, test it on real examples and keep a manual fallback for the first few weeks.
Three or four: automate the stable part only. A common pattern is to automate collection and formatting, and leave the decision to a person.
Two or fewer: do not automate yet. Map the process, agree the rules and run it manually from a written SOP for a month. Then run the test again.
An illustrative example
Consider a small team that copies new website enquiries into a spreadsheet and assigns them. The input is a fixed form, it happens daily, and the assignment rule is simple (by service type). That scores well. Replying to the enquiry with a tailored quote does not: the content depends on judgement. A sensible first automation is "form to sheet to assigned owner with a reminder", with the reply left to a person.
Key takeaways
- Test one specific task, not a whole department.
- Unclear rules and missing ownership are signals to map first, not to build.
- Partial automation of the stable steps is often the right answer.
