Every operations team has a list of things they would like to stop doing by hand. The list is usually right about the pain and wrong about the order. The task that annoys people most is rarely the one that automation handles best, and the one automation handles best is often so routine that nobody thought to mention it.
This is how we run the search for candidates, what we look for, and the two projects that taught us to look harder.
What "ready for automation" actually means
A task is ready when four things are true. It repeats often enough to matter. Its inputs arrive in a predictable place. The decision inside it can be described as a rule, or as a judgement a reviewer can check quickly. And when it goes wrong, the failure is visible and recoverable.
Most candidates fail on the third or fourth point. "Approve the invoice" sounds like a rule until you learn the approver also checks whether the vendor has been unusually quiet, a signal that lives in nobody's system. "Route the support ticket" is a rule until the one category that needs a human is the one that costs the most when missed.
The audit that changed our shortlist
On a project with a distribution business, the brief named three workflows to automate: purchase-order matching, customer onboarding, and delivery exception handling. We shadowed the team for a week before building anything. The purchase-order matching was genuinely ready. Onboarding turned out to be mostly waiting on documents from customers, which no automation would fix. And the exception handling was the interesting one: eighty percent of exceptions were three known causes with a fixed response, and twenty percent needed a phone call.
We built for the eighty percent, routed the twenty to a person with the context already assembled, and left onboarding alone. The team's own ranking had put onboarding first.
Shadow the work before you scope it. The written process and the actual process are different documents.
Where to look first
After enough of these audits, the same places keep producing good candidates:
- Document review with a rubric. Contracts, claims, applications, compliance forms. Anything where a person reads a document and fills in a structured judgement.
- Approval flows with a threshold. Expenses, discounts, access requests. The below-threshold cases are pure rule; above-threshold cases get assembled for a human.
- Status chasing. Someone whose job is partly "check whether the thing happened and tell people." This is data plumbing, not intelligence, and it frees the most time.
- Copy-between-systems tasks. Re-keying from email into a system of record. Boring, error-prone, and the easiest win of all.
Designing the queue, not just the automation
The pattern that works is a queue with a reviewer, not a black box. Automation drafts the decision and the evidence. A person confirms or corrects. Every correction is captured, because that is what tells us where the rule is wrong and what an AI model would need to learn.
In the first weeks the reviewer looks at everything. As confidence builds, low-risk cases skip review and only exceptions are surfaced. The level of automation becomes a dial the business owns, not a setting we chose for them.
Security and control
Automation touches systems of record, so the questions from security are fair and they are the same every time. Which service account performs actions, and what is the smallest set of permissions it needs? Is every automated action logged with the input that triggered it and the rule or model version that decided it? Can a human reverse it? Does any of the content go to an external model provider, and if so, has the data classification been checked?
We answer these in the design, not after. One detail that catches teams out: an automation that reads email or documents can be handed malicious instructions inside the content it reads. If an AI model is involved, the system must treat document content as data, never as commands, and the actions it can take must be limited regardless of what the content says.
Using it purposefully
The purpose of automating a workflow is to move people from doing the task to owning the outcome. When we get it right, the reviewer spends their time on the cases that need judgement and on improving the rules. When we get it wrong, we have built a faster way to produce mistakes nobody is watching.
A short list to run against any candidate:
- It happens weekly or more often.
- The inputs arrive in a place a system can read.
- The decision can be written as a rule, or checked by a reviewer in under a minute.
- A wrong result is visible and reversible.
- Someone owns the queue and reviews the corrections.
If a candidate passes all five, start there. If it passes three, it is probably a data problem in disguise, and fixing the data is the real project.