Automation multiplies whatever process you point it at. If the process is wrong, you get more of the wrong thing, faster.
Most of the automation requests we turn down are technically easy. That is not why we turn them down.
Automation is a multiplier. Point it at a process that works and you get the same result with less human effort. Point it at a process that does not work and you get the same broken result at scale, arriving faster than anyone can review it.
Three cases where the answer is "not yet"
Nobody agrees on the rule. If two people in the same company would handle the same order differently, there is no rule to encode, only a preference that changes depending on who is on shift. Writing that into software freezes one person's habit into policy. Agree on the rule first, on paper. That conversation is usually the actual deliverable.
The input is unreliable. Automating a report built on numbers somebody types in by hand does not fix the numbers. It removes the one moment when a human might have noticed they were wrong. Fix the capture point before you automate the summary.
The work only looks repetitive. Plenty of tasks look identical from the outside and turn out to carry a judgement call in the middle: a discount that depends on the customer, a substitution that depends on what is in the fridge. Those are worth building around, with a person kept in the loop, but they are not worth pretending are simple.
The version we do say yes to
The good candidates are boring. High volume, one clear rule, an input you can trust, and a cost of being wrong that is small and reversible. Daily reconciliation. Report assembly. Moving data between two systems that both refuse to talk to each other. Turning a stack of receipts into rows.
None of that is impressive in a demo. All of it gives your team their week back.
If you are not sure which category your process is in, that is a fine thing to bring to a first conversation. Half the time the answer is that the process needs fifteen minutes of clarity, not software.