The $350,000 automation that changed nothing

Alex Hormozi tells a story about a company he was brought in to help. He invests in and advises the businesses whose stories he tells, so this one is first-hand, not folklore. Eleven virtual assistants handled a data-cleaning process for about $11,000 a month. The work was fine and the process ran. The company then spent $350,000 to build an AI system that would replace it. The automation worked: it shipped, it ran, and it did exactly what it was supposed to do. It also swallowed nearly three years of the manual bill, paid up front, to remove a process that was never the thing limiting the business. Revenue did not move. Capacity did not move. They needed more customers, and this was not that. The constraint was somewhere else entirely.

Nobody in that story made an obvious mistake. The process was repetitive, well understood, and clearly automatable, which is exactly why it got picked. That is the trap: the easiest thing to automate is rarely the thing holding you back.

Automatable is not the same as valuable

When companies decide "we should do something with AI", the selection process usually runs on visibility. Someone lists the processes everyone complains about, ranks them by how automatable they look, and starts at the top. It feels rigorous. It is actually a filter for familiar and well-documented, which correlates with "we have already made this process cheap and predictable", which correlates with low leverage.

The question that should come first is different: what is the constraint? What is the one thing that, if it doubled in capacity tomorrow, would actually show up in the numbers? For a growing installation company that might be quoting speed, because every quote that goes out a day earlier wins work from slower competitors. For a wholesaler it might be order intake errors, because every mistake burns margin and a customer's patience. For a clinic it might be scheduling, because empty slots are revenue that expires the moment they pass.

Automate the constraint and the whole business moves. Automate next to it and you get a nicer version of a problem you did not have.

A simple test before you build anything

Before we build an automation for a client, or for ourselves, it has to pass three questions:

1. If this works perfectly, what number changes? Not "which annoyance disappears", but which number: revenue, capacity, error rate, days-to-quote. If nobody can name the number, the project is a hobby.

2. Is that number currently constrained by this process? Plenty of processes are annoying without being limiting. Your team may hate the weekly report, but if nobody is waiting on it to sell, serve, or ship, automating it buys comfort, not capacity. Comfort is fine, but it should be priced as comfort.

3. What does the manual version cost, honestly? Hours, errors, delay, and the opportunities you decline because you have no slack. Then compare that with what the automation costs to build and to keep running. The Hormozi example fails exactly here: $350,000 against $11,000 a month is a bet that only pays if the process would have run unchanged for years, and it was not even the constraint.

Notice that none of these questions mention AI. That is deliberate. AI has made automation much cheaper, and it has expanded what can be automated at all: judgement calls, messy documents, free-text email. It has not changed the arithmetic of leverage. It has only made it cheaper to get wrong, faster.

What to leave alone

Just as important as the list of things to automate is the list of things to refuse, or at least to question harder:

• Processes that are still changing every month. These used to be an automatic no: automation froze the process in code, and freezing it too early meant paying twice, once to build it and once to unpick it. AI has loosened that, because much of the how-to now lives in written instructions rather than in code, and rewriting an instruction is far cheaper than rebuilding software. Frequent change no longer disqualifies a process; it raises the bar and moves the cost from building to keeping up, so budget for the upkeep before you commit.
• Processes that run four times a year. The break-even on rare work almost never arrives, no matter how painful the four occurrences are.
• Judgement you would not delegate to a new hire on day one. If you would not hand the decision to a capable junior with a written procedure, do not hand it to a system either. Automate the preparation around the judgement, keep the judgement.
• Anything you cannot describe as a procedure. If three people do the process three different ways, that is not an automation project yet. It is a decision that has not been made. Make the decision first; it is free, and sometimes it removes the need to build anything.

Advice first, then software

This is why the first thing we do with a new client is not build. It is sitting down with the owner and finding the constraint: where the hours actually go, what the errors actually cost, and which process is genuinely in the way of the next customer. Sometimes the answer is an AI automation. Sometimes it is an integration between two systems that were never introduced to each other. Occasionally the honest answer is that the highest-leverage move is not worth automating at all this year.

That conversation is cheap. Building the wrong thing is not. The companies getting real returns from automation right now are not the ones automating the most; they are the ones choosing best.