Automation projects rarely fail on the technology. They fail at the moment somebody has to write down what the rule actually is. Here is how we pick the first process to automate — and how to tell whether you have a process at all.
The question arrives in roughly the same form every time. Somebody has decided this is the year, they have a budget, and they want to know where to start. Usually they arrive with a candidate already chosen, and usually it is the thing that annoys them most on a Monday.
That is not a bad instinct, but it is not a criterion. Below is the sequence we actually run, in the order we run it.
A task is not a process
A task is something one person does. A process is a sequence of tasks with a trigger at the front, decisions in the middle, and an output that somebody downstream depends on.
Automating a task gives you a macro. It saves the person who does it some typing, and the benefit stops at their desk. Automating a process changes what the business can do without hiring, because the gain compounds across every handoff in the chain.
The test is to draw it. Write the stages left to right, with the trigger and the output named. If you can describe the whole thing without once saying "and then it depends", you probably have a task. If your drawing contains a handoff — a moment where the work leaves one person's hands and waits for another — you have a process, and the waiting is usually where the cost lives.
Content Factory is a useful illustration because the naive version is obviously a task. "Make a short video" sounds like one job. The process is six stages: script, source, voice, render, publish, attribute. The interesting engineering is not in any single stage. It is in the licence-verified B-roll cascade — four ranked sources, tried in order — and the three fallback tiers behind every render stage, so that one provider having a bad afternoon does not empty a day's schedule. The stages are the easy part. The handoffs and the failure handling are the system.
Volume is the wrong first question
"We do this constantly" feels like it settles the argument. It does not. Volume tells you the size of the prize. It says nothing about whether the prize is winnable.
Two reasons. First, high-volume processes are often the ones that have already been smoothed. Someone has batched them, built shortcuts, learned where the sharp edges are. The remaining friction is real but it is not the largest friction in the building. Second, and more importantly, every run is another opportunity for reality to differ from the description. Exceptions are what automation projects die of, and a process you run constantly is a process that has met more exceptions than anyone has written down.
Volume is a multiplier, not a filter. Use it to rank the candidates that have already qualified on something else.
The four signals that a process is ready
Repeatable
Same trigger, same shape, same output. The test we use: could you hand this to someone in their first week, with a one-page written instruction, and expect a correct result on the first attempt?
If the honest answer is no — if the instruction would need to be followed by a conversation — then the process is not yet repeatable. It is a skill that lives in a particular person. Skills can be documented into processes, but that is the prior piece of work, and in our experience it is the piece that gets skipped.
Rule-bound
Every decision along the path can be written down as a rule, or explicitly handed to a named human. This is the signal that decides the architecture, so it is worth being pedantic about.
POD Engine runs nine stages from trend to storefront and keeps exactly one human approval gate. Not because the other eight could not be automated, but because taste and legal exposure are the two decisions that should not be. Everything mechanical runs unattended; the judgement stays with a person.
Growth Engine takes the same idea further and puts compliance in code rather than in a prompt. An address has to be published on the prospect's own site, with the source URL kept as evidence. Guessed or suppressed addresses fail closed. The banned-phrase check runs after the model has written, not instead of it. Zero email addresses are ever guessed — which is a rule, and therefore testable, in a way that "be careful about compliance" never is.
If a decision cannot be written as a rule and cannot be handed to a named person, it is not part of a process. It is a judgement, and it needs to stay with whoever currently makes it.
High-touch
Count the number of times a human has to pick the work up, move it, and put it down. Re-keying a figure from one system into another. Chasing an approval. Copying a number out of a report and into a different report.
This is the signal most often missed, because every individual touch is small and none of them feels like a problem. It is also where automation returns the most, because you are removing the waiting between touches, not just the typing during them.
Business OS is what this looks like at estate scale. Eleven businesses coordinated, one identity provider across all of it, so access is granted and revoked in one place rather than eight. A shared automation estate — 117 workflows, namespaced per business — so a new venture inherits the routing, notification and escalation patterns instead of rebuilding them. Secrets brokered centrally, so a credential rotates without redeploying every consumer. None of that is a clever algorithm. It is the removal of touches.
Error-prone
Not "does this go wrong", but "when it goes wrong, how long until anyone finds out, and what does finding out cost".
Contractor OS is built around exactly that question. Money is kept out of floating point end to end — integer cents in the calculation, numeric columns in the database, zero floating-point money values anywhere. Every financial document posts a balanced journal entry, one hundred per cent of them, without exception. The point is not the arithmetic. The point is that a rounding drift discovered in March costs far more than the same drift caught at the moment of posting.
Score a candidate honestly against all four. A process that scores on all four is a first automation. A process that scores on volume alone is a second or a third.
Measuring what it costs you now
The common mistake is to measure the obvious part — the data entry itself — and to ignore everything wrapped around it. The re-keying, the chasing, the checking, the reporting on the checking.
The arithmetic we use in the brief is deliberately blunt: hours per week, times the number of people, times a loaded hourly cost, times 52. Three numbers you type in yourself. There is no industry benchmark buried in it and no "typical savings" percentage, because a percentage we invented would not tell you anything about your business.
Three rules for getting the inputs right:
- Count per person, then count the people. Processes leak sideways across desks. The person who owns it is rarely the only one paying for it.
- Count the waiting where the waiting blocks something. If a job sits pending an approval, and the crew cannot start, that is part of the cost of the process even though nobody was working on it.
- Use loaded cost, not wage. Wage is the number to hand, which is why it gets used; it leaves out payroll burden, benefits and overhead, so it understates the figure you are trying to find.
Then the honest part. The figure you land on is the cost of the status quo. It is not the saving. Automation moves cost; it does not delete it. Something has to be maintained, watched, and occasionally corrected by a person who understands it. If the status quo cost only just clears the cost of running the automation, you have the wrong first candidate. Pick one where the gap is large enough that nobody has to relitigate it in six months.
Pick the one you can verify
The first automation has a job beyond its own return: it has to earn the trust that funds the second one. That argues strongly for choosing the process where a wrong answer is visible.
Three questions before anything is built:
- What does correct look like, expressed so that you could check it without opening the system that produced it?
- How would you sample the output — how many, chosen how?
- What does the system do when it cannot be sure? Stop, escalate, or guess?
When the Catalogue Engine storefront came off WordPress, 36,786 legacy URLs had to keep resolving through the DNS cutover. Verification was not "the mapping code looks right". It was a sample checked against production: 300 for 300. Contractor OS proves itself the same way — the demo dataset produces byte-identical figures on the embedded WebAssembly Postgres used locally and the managed Postgres in production, with the balance sheet out by exactly 0.00 on both. Content Factory publishes into the scheduler as drafts, so a person is always between the pipeline and the audience. That is a verification decision at least as much as an editorial one.
If you cannot describe what checking it looks like, you are not ready to build it. In our experience that is almost never a tooling problem. It is a sign that the rules have not actually been agreed.
The failure mode nobody plans for
Here is the failure we plan for.
Two people in the business hold different versions of the same rule. Neither of them knows it, because the disagreement has always been absorbed by a human exercising judgement in the moment. Nobody had to say out loud which version was correct, so nobody did.
Then it gets written down. The disagreement surfaces — and it surfaces as an argument about the software, which is the worst possible place to have it.
The early symptom is "it depends" appearing repeatedly in the specification conversation while nobody can finish the sentence. The late symptom is that the automation ships, does precisely what was specified, and somebody declares it broken. It is not broken. It is enforcing one version of a rule that was never settled, and now the enforcement is visible.
The fix is not a better tool. Settle the rule first, in writing, with the person who owns the outcome. If it cannot be settled, that is your finding, and it is a useful one: the process is not ready. Building anyway converts a management problem into a software problem, where it costs more and is harder to see.
A cheap move that works: run the disputed rule manually for a fortnight before automating anything. If people follow it and nothing catches fire, automate it. If they quietly go around it, you have learned something worth more than the automation would have been.
Which shape is yours
Two shapes recur often enough to be worth naming, and they want different first steps.
The estate shape, of which Business OS is the clearest example. The process spans several systems of record. Output volume per run is low. The cost sits in coordination and reconciliation rather than in production. Value comes from consolidation — one identity provider, one place credentials rotate, shared patterns rather than eleven separate rebuilds. You verify it by reconciling state: does the record agree with itself everywhere it appears?
The production shape, of which Content Factory is the clearest example. One artefact, made repeatedly to a standard, across 42 niches and four language regions. Value comes from throughput and consistency at a volume that hiring cannot reach. You verify it by sampling the output and by keeping a review gate in front of the audience.
They fail differently, and that difference matters when you are choosing which to do first. Estate automation fails quietly — a stale record, an access that was never revoked, something nobody notices until it is expensive. Production automation fails loudly and cheaply: a bad draft sits in a queue where somebody sees it before the audience does. Loud, cheap failure is a good property in a first project.
In order
- Write the process out as stages, with the trigger and every handoff named. If you cannot, it is a task or a skill, and that is a different piece of work.
- Score it on the four signals — repeatable, rule-bound, high-touch, error-prone. Use volume to rank the survivors, not to qualify them.
- Cost the status quo with your own numbers, counting the waiting and the chasing.
- Settle every disputed rule in writing, before anything is built.
- Of the candidates left, choose the one whose output you can check.
- Leave a human where the rules run out — and only there.
Most of that list happens before anyone writes any code, which is the actual point. The build is rarely the hard part. Deciding what the thing is supposed to do, precisely enough that a machine can do it and you can tell whether it did, is the hard part.
If you want a second opinion on which of your processes qualifies, the brief walks the same questions in about five minutes and tells you which of the systems we have already shipped is the nearest shape to yours. It is allowed to tell you it is too early. Sometimes that is the correct answer.