Frequency comes first
A workflow is worth improving when it happens often enough for the time returned to matter. Monthly work can still be valuable, but daily or weekly friction gives you faster feedback and a clearer case for change.
A workflow that runs twice a year, however painful, does not give you enough repetitions to notice whether a change actually helped — you are stuck redesigning from memory each time. Weekly or daily volume, even if individual instances are small, gives you a rhythm and a comparison group. That is why an under-loved but high-frequency task usually beats a dramatic but rare one.
The inputs need to exist
AI is strongest when the source material is available and reviewable: notes, emails, templates, records, reports, checklists, or policies. If the real process lives only in someone's head, the first job is documentation.
If the process depends on institutional memory — a person who "just knows" a client's preferences, or the exceptions to the standing rule — the workflow is not ready for AI yet. It is ready for documentation. Writing the exceptions down first usually turns out to be the thing that made the workflow hard to automate in the first place.
Reviewable does not mean perfect. Messy notes and inconsistent templates are still usable material, because a person can still check the output against them. The absence of any material at all is the real blocker, not untidiness.
Measure the before state
Before building anything, capture the current cost: time spent, handoffs, rework, wait time, error rate, or confidence. The metric does not need to be grand. It just needs to be honest enough to compare later.
A rough baseline beats a precise one collected later from memory. Even a week of manually timing a task, or counting how many times a form gets sent back for corrections, gives you something concrete enough to compare after the change lands.
Where a metric already exists — a support tool that logs response time, or a CRM that timestamps stage changes — use it. Building a new measurement system just to justify an automation project is its own kind of overhead.
Put the three signals together
Take invoice chasing as an example. It happens most days, so frequency is satisfied. The inputs — invoices, payment terms, prior reminder emails — already exist in the accounting system, so the second signal is satisfied. The only gap is a measure: nobody currently tracks how many days overdue an invoice sits before someone chases it.
That gap is worth closing before building anything. A week of manually noting the average chase delay gives you a number to compare against once a drafted-reminder step is in place — and a way to know, a month later, whether the change actually shortened the delay or just moved the same delay somewhere else.
Run the same exercise against any candidate workflow before scoping it. Where all three signals are already satisfied, you are ready to build. Where one is missing, that missing signal — not the AI itself — is the actual next task.
Where this goes wrong
Some workflows look automatable and are not. A monthly report that changes format every time someone new asks for it fails the frequency test in disguise — it happens often, but never the same way twice, so there is no stable pattern to learn from.
A process with plenty of volume but no reviewable inputs is the second trap: sales calls where the only record is what the rep remembers. And a workflow with clear inputs and steady frequency but no agreed way to measure success is the third — teams build the automation, feel like it helped, and have nothing to point to when someone asks whether it actually did.
The pattern behind all three traps is the same: a workflow that fails one signal quietly puts the other two at risk too, because the missing signal is often the reason the other two looked attractive in the first place — high volume with no structure, or steady structure with nothing worth measuring.