How to pick the first workflow (and the three you should not start with)

Field notes. John Arndt, Soxoa. Published September 11, 2026.

The first workflow you automate decides whether there is a second one. Not because of the technology, which will be fine, but because the first attempt spends something an organization only has a limited amount of: its willingness to try this again. Spend it on the wrong candidate and the next proposal arrives into a room that has already made up its mind.

So the selection is the decision. Here are the five tests I put a candidate through, and the three candidates that keep getting chosen anyway.

Five tests the first workflow has to pass

A candidate that fails one of these can sometimes still be fixed before the work starts. A candidate that fails two should wait.

1. Countable volume

   Somebody can tell you how many times a week this happens, and the number is large enough that a saved minute matters. If the honest answer is a shrug, you cannot measure the result, and an unmeasurable result turns into an argument about whether anything improved. Count it for two weeks before committing if you have to. That count is cheap and it is the baseline you will be judged against.

2. A named owner

   One person, named out loud, who performs or supervises the work and will accept responsibility for the system afterwards. Not a department, not a committee, not the person who is most enthusiastic about AI. If nobody will take the name, you have found something more important than a tooling problem, and no build fixes it.

3. Examples you are allowed to share

   Real examples of the work, thirty to fifty of them, that somebody with authority has approved for use with the tool you intend to use. If getting that approval requires a three-month legal review, the review is the project and the build is not ready to start. Find out now rather than on the build day.

4. A mistake you can catch

   There has to be a point where a wrong answer is visible before it does damage: a reviewer who accepts or rejects, a total that has to reconcile, a customer reply that a human sends. This is the test that keeps a first project safe, because a first project will be wrong sometimes and the whole question is what happens next.

5. A result you can measure

   Agree, in writing, what number you will look at afterwards and who will look at it. Hours on the task, turnaround time, error rate, backlog age. One measure is enough and one is better than four. Agree it before the build, because a measure chosen afterwards is chosen to flatter the result.

The three you should not start with

These three come up constantly, and all three fail on the same underlying point: nobody can tell whether the finished thing is working.

The pet idea nobody performs daily

An executive has a specific idea, usually a good one in the abstract, for work that nobody in the building does every day. It gets chosen because of who suggested it. It fails because there is no volume, no practitioner to correct the design, and nobody whose week improves, so the finished system has no advocate and quietly stops being used. Write it down as a candidate for later and pick something the room actually performs.

The workflow nobody can describe

You ask five people how it works and get five answers, all partly right. This is not a reason to automate the workflow; it is a reason to write it down first. Automating a process nobody can describe produces a system nobody can evaluate, and the arguments about whether it is correct will be unresolvable because there was never an agreed version of correct. Spend a week mapping it. Then decide.

The one where an error is irreversible

Money leaves. A filing is submitted. A message reaches a customer who then tells other customers. Automating in front of an irreversible consequence is possible, and I do it, but not first. A first project should be somewhere a mistake costs a correction rather than a apology, because you are not only building a system, you are building the organization’s belief about what these systems do when they are wrong.

When the best candidate fails one test

Usually the failure is fixable and the fix is cheap. No count: count it for two weeks. No approved examples: get the approval decided, which is a conversation with one person rather than a project. No measure agreed: spend twenty minutes agreeing one.

The failure that is not cheap is ownership. If the workflow is real, the volume is there, the examples exist, and still nobody will put their name on the result, the constraint is not the workflow. That is the case where I would rather start somewhere else and come back, and it is the reason ownership is scored first in the AI Readiness Assessment.

One more piece of advice that people dislike: do not pick the workflow that is most annoying. Annoyance and volume are different things, and the most irritating part of a week is often a rare task with a fiddly exception in it. The boring high-volume step next to it is the one worth building.

Where this fits

If the candidate clears the five tests and you want it operating in your own environment, with evaluation on real examples and a defined review path, that is an AI Build Sprint. If you are less sure and would rather have the team do one with me first, it is a Live Build Workshop, where the selection argument happens on the wall in the first hour. Bring the two candidates you are torn between to a strategy call, or start with the readiness assessment if you want the wider picture first.