Five questions worth answering first
If a process fails any of these, automating it tends to cost more than it saves.
- Frequency: does this happen often enough that the setup pays back?
- Stability: has the process stopped changing month to month?
- Rule clarity: can you state the rule without using the word "usually"?
- Cost of error: if it fires wrongly, is the damage recoverable?
- Reversibility: can you switch it off without unpicking a mess?
Frequency and stability together
A weekly process that has been stable for six months is an excellent candidate. A monthly process still being argued about is not, regardless of how tedious it is.
Stability matters more than frequency, because an unstable process automated early means maintaining the rule instead of the work — often a worse job than the one you replaced.
The "usually" test
If describing the rule requires qualifiers — usually, unless, depending on — the exceptions are load-bearing and the rule is not ready.
Two options follow: narrow the rule until the exceptions fall outside it, or leave it manual. Encoding a rule with hidden exceptions produces failures nobody notices until they compound.
Start where the cost of error is low
Creating an internal task is cheap to get wrong. Sending something to a customer, changing a deal value or altering permissions is not.
Sequencing automation from low-consequence to high-consequence lets the team build trust in the rules before anything customer-facing depends on them.