Draft for founder review. Not yet approved for publication.
The process that hurts most is usually the wrong one to automate first. It is painful because it is messy, and messy processes make poor first projects. A better first candidate is dull, frequent and well understood.
Five questions to ask
- Does it happen often? A task done every day repays automation sooner than one done at quarter end.
- Are the rules clear? If two experienced people would handle the same case differently, settle the rules first.
- Is the data already in a system? If it lives on paper, in email or in someone’s head, the first job is getting it into a system, not automation.
- Is there one owner? A workflow that crosses four departments with no single owner will stall on the first disagreement.
- Is a mistake cheap to catch? Start where a person can check the result before it matters.
A workflow that scores well on all five is a good first candidate, even if it is not the most exciting one.
Keep a person in the loop
For a first project, the software should prepare and a person should approve. That keeps mistakes small, and it builds the trust you will need for the second project.
Agree the measure before you build
Decide what you will measure and how, before any work starts: hours spent, errors found, time to complete. Measure it for a while by hand. Without a starting point, nobody can say afterwards whether the project worked.
What to leave for later
- Workflows where the data is known to be unreliable.
- Decisions that depend on judgement nobody has written down.
- Anything where a wrong action cannot be undone.
None of these are impossible. They are simply poor places to learn.