The robot pizza problem I read this week about robotic pizza makers failing across the US. Millions invested, years of development, and the machines just couldn't match what a human with a dough hook could do. The technology worked. The automation was real. But the thing being automated was wrong. This happens constantly in smaller operations too. Someone reads about automation, gets excited, picks a process, builds the system, and six weeks later wonders why everything feels worse. The problem is rarely the tool. It's the choice of what to automate. Why people automate the wrong things I've worked with people in London and beyond who came to me after spending £3,000 or more on automation that made their business harder to run. The pattern is almost always the same. They automated something visible rather than something valuable. Sending invoices looks like busywork, so they automate it. But the actual problem was that nobody followed up on unpaid invoices. The automation just made ignored invoices arrive faster. Or they automate client onboarding because it feels repetitive. But the repetition was where they built trust. The new client got a slick automated sequence and felt like a number. Conversion dropped. Visibility is not the same as value. The tasks that annoy you most are not necessarily the tasks that cost you most. What actually should not be automated Here's my working list, built from watching things go wrong: Anything where judgement changes the outcome. If two situations look similar but require different responses, a human should be in the loop. Automated customer support that routes complaints to the wrong queue because keywords matched. Automated scheduling that books a new client into a slot you needed for prep. The system cannot know what you know. First impressions. The first email, the first call, the first meeting. These are where relationships form. Automation here saves maybe 15 minutes per client but loses something you cannot measure until three months later when they don't refer anyone. Anything you don't understand well enough to explain. If you cannot write down the exact logic of how a task should work, you cannot automate it. You will just encode your confusion into a system that runs it badly, at scale, while you sleep. Processes that are still changing. I see this constantly. Someone builds automation for a workflow they invented last month. Then the workflow evolves and the automation becomes a constraint. You spend more time updating the system than you saved by building it. What should be automated The things that work well when automated share a few traits. They are stable. The process has been the same for six months or more. You know the inputs, the outputs, and the exceptions. They are high volume. Sending one reminder email per week does not need automation. Sending forty does. They are low judgement. The decision tree is simple. If X, do Y. If not X, do Z. No nuance required. They are invisible to the client. Internal data moves, backups, reconciliation, reporting. Things that make your operation run but do not touch the relationship. One client I worked with automated their expense categorisation. Receipts came in, got sorted, fed into their accounting software. Saved them 4.5 hours per month. No client ever noticed. That's the right kind of automation. The real cost of bad automation When you automate the wrong thing, you pay three times. Once to build it. Once to fix the problems it creates. Once to rebuild trust with whoever got caught in the mess. I've seen a go-getter lose a client because an automated follow-up sequence sent a sales email the day after the client's father died. The system didn't know. Couldn't know. But the damage was real. Automation does not care about context. That's its strength and its danger. How to decide Before automating anything, I ask three questions: What is the actual cost of doing this manually? Not the annoyance. The hours, the errors, the delays. Put a number on it. What could go wrong if this runs without human oversight? Not the best case. The worst case. Is this process stable enough that I won't need to change it for six months? If the cost is low, the risk is high, or the process is still evolving, I don't automate. I document it instead. Write down the steps. Make it easy for someone else to do. That's often enough. At alira.london, we have a 5 Whys tool that helps with this kind of thinking. Not because it's about automation specifically, but because it forces you to find the real problem before you build a solution. Most automation failures start with solving the wrong problem. The pizza lesson Those robotic pizza makers failed because pizza is not really about assembly. It's about feel. Dough behaves differently on humid days. Toppings need to be distributed by someone who can see the whole pie. The task looked mechanical but was actually judgement-heavy. The companies that succeeded in food automation picked different targets. Dishwashing. Inventory tracking. Prep scheduling. Boring, stable, invisible. The lesson applies to any operation. Automate the infrastructure, not the craft. What to do this week List every process you've considered automating in the past year. For each one, write down the actual hours it costs you monthly and what could go wrong if it ran unsupervised. Strike anything where the risk outweighs the time saved. Pick one internal process that is stable, high-volume, and invisible to clients. That's your automation candidate. Spend 30 minutes researching whether a simple tool already exists for it. For everything else on your list, write a one-page document explaining how to do it manually. That document is often more valuable than any automation you could build.