Which Process to Automate First? The Candidate Nobody Nominates

Your first automation target is rarely the one you were asked about

The best first process to automate has three properties: a decision rule somebody can state out loud, an input that arrives in the same shape every time, and a person who already does the work by hand today. The process your loudest stakeholder nominates almost never has all three, because importance and automability are different axes, and the nomination is a signal about the first one.

The right first process to automate is the one with a written decision rule, a stable input, and an existing human operator — which is almost never the process a sponsor nominates, because sponsors nominate what is visible, not what is predictable.

Everything below is how I test that claim against real candidates.

Why does the loudest candidate usually fail the test?

A nomination tells you where the pain is felt at management level. It rarely tells you where the work is repeatable. I have seen this pattern in four consecutive engagements, and it has the same shape every time.

The nominated process is usually important because it is ambiguous. "Improve margin on renewals" and "forecast demand for the next quarter" are strategic precisely because no documented rule produces the answer. Strategic ambiguity is where human judgement earns its salary. It is also the worst possible place to put a system that needs a defined notion of correct output.

The second problem is that important processes are almost always cross-functional, so the input is not stable. The data a decision depends on lives in three systems, two of which are owned by teams that are not in the room. You will spend the entire project building intake, not automating decisions, and the pilot will be judged on the intake pipeline's quality.

The third problem is quieter and it is the one that kills projects. The loudest process frequently has no single human who performs it end to end today. If nobody owns the manual version, you cannot compare machine output to a human baseline, you cannot label examples, and you cannot tell whether a wrong answer came from the model or from a process that was never coherent in the first place.

What are the three tests, and how do you run them in a week?

The decision rule test. Ask the person who does the work to write the rule in one paragraph, including the exceptions they actually apply rather than the ones in the policy document. Then find a second person who does the same job and give both the same ten real cases. If trained people disagree on more than one or two of them, the variance is in the process, not in the model, and a model trained on that process will inherit the disagreement.

The input stability test. Pull the last 200 instances. Count how many arrived complete and in the expected format. Count how many required an email, a phone call, or a lookup before the rule could be applied at all. If a third of them need repair first, your project is an intake project wearing an automation project's clothes, and it will take three times as long as the version you scoped.

The existing operator test. Name the person who does this by hand today, at volume, with opinions about edge cases. That person gives you three things you cannot buy: labelled examples, a correctness baseline, and a reviewer who can say "this output is wrong" without needing to be convinced. I have never seen an automation survive without a named reviewer.

What does the screening look like on real candidates?

This is a mid-size distributor's operations team, screened in one afternoon. The candidate list came from the executive team; the counts came from their own ticket log and order system, which is the only data source worth trusting for this.

The row that got built first is the third one, and it is the least exciting row on the page. It is also the only row where a written rule, a stable input, and a full-time human operator coexist. The demand forecast row failed all three tests while being the single most requested item in the meeting.

Why does an existing human operator matter more than clean data?

Because the operator is the specification. In practice you do not write the automation's rules from the policy document; you write them from what the analyst does when a supplier sends a partial shipment and the receiving record does not match. That knowledge is not in any system: it exists as habits in one person's head and comes out through interruption, not documentation.

The operator is also the fallback path and the political owner of the process. When automation handles most cases and routes the rest to a review queue, that queue needs a person with the authority to decide the leftovers. A process with no human owner produces a queue that nobody clears, and an unclear queue turns a 70% automation rate into a visible operational failure.

How do you count the volume and the minutes honestly?

Take the numbers from timestamps, not from interviews. Ask people to estimate how long rote work takes and they will overstate it, because the memorable cases are the hard ones.

For the exception-handling process above: 1,200 instances a month, and a median of 11 minutes of touch time measured from the gap between ticket creation and ticket resolution, minus waiting periods. That is 13,200 minutes, or 220 hours a month, which is roughly 1.3 full-time equivalents of analyst attention. At a fully loaded RMB 30,000 a month for an operations analyst — a figure I take from Shenzhen hiring I have been part of, and which you should replace with your own payroll number — the touch time costs about RMB 40,000 a month.

Then refuse the tempting arithmetic: automation does not remove touch time, it removes the touch time spent on the decision. If the system drafts the correct action and the same analyst reviews and commits it in 3 minutes instead of 11, you have recovered 160 hours a month, not 220, and the review queue is now the constraint. That remaining 3 minutes is where the real discipline sits, and it is why the first version should end with a human pressing a button rather than a system writing to the order book unsupervised.

On the cost side, the inference bill is the least interesting number, but it is the one finance will ask about first. Per-run cost is worth modelling properly before the pilot starts, using a per-run cost model that survives a finance review rather than a per-seat licence comparison, because the shape of the cost curve is what determines whether the second and third processes are affordable. What I will not give you is a predicted success rate. Published automation success percentages are not reproducible across process types, so the honest planning assumption is that the first project is an infrastructure project that happens to save some hours.

What should the first version deliberately not do?

Scope matters more than model choice here. The first version should not automate the decision; it should draft the decision and hand it to the existing operator with the evidence attached. The operator compares draft to their own judgement for two weeks. Disagreements become test cases. Agreement becomes the automation rate you quote to the board.

Do not touch the write path in version one. Do not add a second process. Do not let the intake pipeline grow — accept the formats that already arrive, and queue the rest for manual entry, because a 12% manual-entry tail is a cheaper problem than a three-month normalisation project.

What are the signals that you chose wrong?

Set these as kill criteria before the build, and check them at week four.

• The operator disagrees with the written rule more often than with the model. The process is not ready, and no model will fix it.
• Intake repair consumes more build time than decision logic. You picked a data problem.
• Nobody can define correct output for one case in five, and the fifth is usually the one the customer notices.
• The process owner changes during the pilot. Ownership turnover means the spec is moving; pause until it settles.
• The automation rate plateaus below 50% after two weeks of tuning, with the misses clustered rather than random. Clustered misses usually mean a missing rule, which the operator can supply, or a genuinely judgement-heavy segment that should stay manual.

None of these are model failures. That is the point of screening for a stated rule, a stable input, and an existing operator up front: almost every reliable signal of a doomed automation project is visible in the process, before any technology arrives.

The candidate nobody nominates is the one that funds the rest

The strategic process will still be there in six months, and by then it will be cheaper to attack, because you will have built intake handling, a review queue, cost logging, and a team that knows how to grade output. The first project's real deliverable is not the recovered hours; it is the organisation's ability to say yes to the second project with evidence instead of hope. So choose the boring candidate, the one with a rule and an operator and a boringly countable volume, and treat the recovered hours as a side effect of building that capability. If you cannot name the person who does the work by hand today, you have not found a first automation candidate — you have found a reorganisation that has been described as a technology project.