Workings · 05 · the limits
Five things I tried to automate, and stopped.
Everyone selling automation shows you the wins. The failures are more useful, because they're where the money actually goes — and because the pattern in them tells you what to try in your own business and what to leave alone.
These are all from my own business, which is retail and e-commerce: a shop, a warehouse and a website. I've filed the specifics off where they'd identify a supplier, but the failures are real and I'm still living with every one of them.
01 · Deciding who gets the limited stock
When a scarce product lands, orders arrive from people who want it and from people who want to resell it. Sorting one from the other looks like a classic scoring problem — order history, address clustering, how fast they bought, how many they took.
The scoring works. The decision doesn't. Cancel a real customer's order because they happened to buy quickly and you've lost them permanently over a machine's guess, and the machine is confident in exactly the cases where it's most wrong. There is no threshold that trades those two errors acceptably, because the costs aren't symmetrical and never will be.
What I do instead: the software ranks and explains, a person decides. Nothing is ever cancelled on the score alone — every one is reviewed by a human before anything happens to an order. The rules are mine, written down and argued about. It saves the hours of sorting and none of the responsibility.
02 · Product descriptions, unattended
New products arrive as a spreadsheet row: a code, a name, a trade price. Somebody has to turn that into a page worth reading. Generating them automatically is easy and the output is fine — genuinely fine, most of the time.
"Most of the time" is the problem. In a batch that size you can count on at least one that confidently states something untrue about the product, and that one is now on the internet with my name on it. I can't tell you the rate, because I've never let a batch through unchecked to find out. The cost of the miss is far higher than the cost of the check, so the check stays.
What I do instead: drafted automatically, published by hand. Everything lands as an unpublished draft. The saving is in the writing, not the publishing, and that's still most of the work.
03 · Knowing what's actually on the shelf
The system's stock figure and the shelf's stock figure disagree. They always disagree. Breakages, miscounts, something put back in the wrong place, an order picked but not marked — none of it is visible to software, and no amount of integration invents a fact that was never recorded.
I spent real time trying to reconcile this automatically before accepting that I was building an ever more elaborate way of being confidently wrong.
What I do instead: automation decides what to count and when — the lines where an error would cost most, prioritised — and a human walks over and counts them. The robot picks the shelf. The person has the eyes.
04 · The thing the platform simply won't tell you
A small one, and my favourite, because it's the failure nobody warns you about. I wanted to work out sales by staff member from the till. The platform records which staff account processed a sale. It will not, through its interface for developers, tell you that person's name.
No clean answer through that door that I could find, and I looked hard. The data exists; the part that makes it useful isn't handed over.
What I do instead: a small hand-maintained list mapping the internal ID to a name, kept alongside the automation. It works, it's ugly, and it needs updating whenever someone joins or leaves. Total build time saved by discovering this early: none. Total build time lost to assuming it would be there: about a day.
Every integration has one of these. Finding yours is a large part of what an audit is for.
05 · The supplier relationship
Ordering can be automated almost end to end — what to buy, how much, when. What can't be automated is the phone call when an allocation is short, or the goodwill that decides whether you're the account that gets looked after when something scarce turns up.
I tried treating purchasing as a pure optimisation problem. It made the numbers better and the relationship slightly worse, which over a year is a bad trade in an industry where allocation is discretionary.
What I do instead: the machine produces the order and the reasoning. A person sends it, and keeps the relationship that the order sits inside.
The pattern
Read the five back and the same shape turns up in all of them.
Automation is good at the work and bad at the consequences. Every one of these failed at the point where being wrong costs something asymmetric — a customer, a reputation, an allocation, a person's trust. None of them failed at the gathering, sorting, costing or drafting.
Which is why the split I keep landing on isn't "automate this job, don't automate that one". It's: let the machine do everything up to the decision, then hand over a decision that's already been made easy.
When I rank your repetitive jobs, the ones that go to the top aren't necessarily the biggest. They're the ones where being wrong is cheap and recoverable. A job that eats six hours a week and can't hurt you when it misfires beats a four-hour job that can lose you a customer.
If someone tells you every part of your operation can be automated, they have not yet had to apologise to anyone.
All five are still unresolved and I don't expect to resolve them. That's not pessimism about the tools — it's the reason the work is worth paying for: knowing where the line is saves more money than pushing past it.