The usual advice is to automate whatever takes the most time. That picks badly. The highest-hour workflows are usually high-hour because they are full of judgment, and judgment is the part that does not automate cleanly.
Here is a test that picks better. Four questions, applied before anything is built.
Does it have a definite end?
A workflow that ends can be measured, retried, and reasoned about. The quote is sent. The invoice is filed. The ticket is closed. A workflow that merely continues cannot.
“Keep an eye on the inbox” fails this. “Turn an inbound RFQ into a draft quote” passes it.
Can you tell a good run from a bad one without being there?
If the only way to know whether it worked is to have watched it, you cannot operate it and you certainly cannot improve it.
This is a higher bar than it sounds. It rules out most summarization work, because a bad summary and a good one look identical to anyone who has not read the source.
Does the input already exist in a system?
Not “could be gathered.” Already exists, in a place a machine can read, with the access already granted.
Workflows that fail here do not fail permanently. But the work is connecting the system, and that should be a separate, honest line item rather than a surprise discovered halfway through.
Is there a moment where stopping is cheap?
Somewhere the workflow can pause, hand a human a decision, and resume without losing state. If there is no such moment, the whole thing is all-or-nothing, and all-or-nothing automations get switched off the first time they are wrong.
The failure mode nobody plans for
The test passes, the workflow gets built, and it breaks on inputs nobody mentioned.
This is almost never because the four questions are wrong. It is because of who answered them. The person who wants the automation describes the process. The person who runs it every day knows the exceptions, and the exceptions are the workflow: the supplier who sends specifications as photographs, the customer whose part numbers never match the catalog, the quarter-end week when the rule about approval thresholds is quietly suspended.
A process diagram passes all four questions easily. The work as actually performed often fails the third one, because half the input lives in someone’s memory rather than in a system.
So the test has a prerequisite: answer it with the person who does the work, not the person who owns the outcome. Where they disagree, the operator is describing reality and the diagram is describing an intention. Stated as an assumption rather than a finding, since it has not been measured across enough engagements to call it a rule: one candidate that survives that conversation is worth more than three that survived the questions on paper.
What passing looks like
A workflow that passes all four is usually unglamorous and usually mid-volume: processing supplier confirmations, turning site survey notes into a structured record, reconciling delivery dates across two systems.
It is also the one that ships in two weeks and still works in six months, which is a better outcome than the impressive one that needs a person watching it.
If nothing in your operation passes all four, that is a finding, not a failure. It usually means the next piece of work is connecting a system rather than building an agent, and knowing that before you start is the entire point of the test.