The request usually arrives as a solution: "Can we use AI to do X?" The better first question is "why does X take so long today?", because half the time the honest answer is that X shouldn't exist.
Automation amplifies whatever you point it at
If a process has four unnecessary approvals, automating it gives you four unnecessary approvals at machine speed. You've spent money to make a bad design harder to see, because now it's buried inside a tool nobody wants to reopen.
A simple order of operations
- Map the real workflow, the one people actually follow, not the one in the handbook.
- Delete steps, anything that exists out of habit, fear, or an old incident nobody remembers.
- Simplify the rules, fewer exceptions make everything downstream easier.
- Standardise the inputs, most automation pain is really input chaos.
- Then automate what's left, and only the parts worth it.
Most of the value shows up in steps 1–4, before any software is written.
An example shape
A team wants to "AI-triage" incoming requests. Mapping the flow reveals that 60% of requests are one of three types that could be a dropdown at submission time. Fixing the intake form removes most of the triage problem, and the remaining AI-assisted routing is now a small, reliable job instead of an open-ended one.
The counterargument
"Process work is slow and political; software is something we can just do." That's exactly why broken processes survive, changing them requires conversations, and buying a tool avoids them. But the tool doesn't remove the conversation; it just postpones it and adds a licence fee.
Subtraction is unglamorous and usually the highest-leverage move on the board.