Here is the verdict up front: most warehouse automation projects that fail were not killed by technology. They were killed by bad math at the decision table.
The equipment itself is rarely the real culprit. In twenty years in this industry, I have walked past dead conveyors, idle AMRs, and dark AS/RS aisles in more warehouses than I can count. The machines turn on just fine. What kills them is what happened months earlier, in a conference room, when somebody ran the numbers wrong — or never ran them at all.
There are two sides to every one of these stories. On one side, the integrator's proposal is always modeled on ideal conditions. On the other, the buyer always overestimates how stable their own order profile is. Squeeze those two together, and failure is almost guaranteed.
Two failures I watched happen
The first one: 2019, a 3PL in Ontario, California, 80,000 square feet. The owner signed off on a $1.4 million conveyor and cross-belt sortation system. Eleven months of implementation. Then peak season trial runs exposed the problem: the proposal's throughput numbers assumed ideal takt time — standard cartons, large batches, evenly spaced waves. The real order profile was small-batch, high-SKU-mix, hundreds of waves a day. The belt could never be fed fast enough.
The result? The sorter ran at about 40% of its designed capacity. The other 60% of orders still went through manual pick carts. $1.4 million in equipment, eleven months of disruption, and the line's actual uptime never broke 60%. The most surreal sight in that building was the brand-new cross-belt gliding along at half speed while workers pushed carts right next to it — the most expensive decoration in the industry, bought for $1.4 million.
The second one: 2021, an e-commerce fulfillment warehouse that bought 25 AMRs. The contract looked good. The per-unit price looked reasonable. Then reality showed up in three installments: the Wi-Fi had dead zones deep in the racking, so robots went dark and someone had to go "rescue" them; the WCS-to-WMS interface was custom development that took two integrator engineers three months on-site to stabilize; and the facility had planned exactly four charging docks for 25 robots, so at peak they queued up like taxis at an airport.
The result: the fleet's effective productive hours came in under half of the designed figure, and peak season still required temp labor. The money was spent. Not a single headcount was saved. The owner later told me his real regret was not buying the AMRs — it was that nobody told him beforehand that the robots themselves are maybe 30% of a successful AMR project, and the "side details" of network coverage, integration, and charging infrastructure are the other 70%.
I have seen too many projects die this way. The causes of death differ. The underlying disease is always the same: the decision was made on an equipment quote, and the real bill showed up somewhere else entirely.
The postmortem: three ledgers
The project is already dead. Blame gets you nowhere. A postmortem needs accounting, and I only ever audit three ledgers. Get these straight and the next move becomes obvious.
| Ledger | What it is | How to calculate it | The classic mistake |
|---|---|---|---|
| Sunk cost | Money already spent, never coming back | Equipment + implementation + downtime losses, line by line | Refusing to stop because "we've already spent so much" |
| Opportunity cost | What this money could have done elsewhere | What the same budget would have bought in process improvement, labor incentives, or a WMS upgrade | Never setting a comparison baseline at all |
| Restart cost | What it takes to actually make it run | Network fixes + interface development + training + spares and maintenance, quoted item by item | Believing "just a little more investment will fix it" |
Of the three, the third one kills. Here is a counterintuitive judgment for you: the most expensive step in a failed automation project is usually "just one more round of investment."
I have watched too many projects die on top-up spending. Another $200K for "the interface," another $150K for "the network upgrade," and the line still does not run right. Every top-up sounds perfectly rational — "we've already spent $1.4 million, what's another $200K?" That is not rationality. That is a gambler's logic: the deeper the sunk cost, the harder it is to admit the loss.
There are two sides here, so let me split them. Some failed projects deserve rescue: the design was right but the execution drifted — the order profile genuinely fits automation, and the gaps are network, integration, or training. Fill those and it runs. Others should never be rescued: the order profile was never a fit for automation in the first place — like the cross-belt sorter in that small-batch 3PL. No amount of money fixes a fundamentally wrong match; every top-up just digs the grave deeper.
The only way to tell them apart: stop, take your last twelve months of actual order data, and re-run the capacity model. Not the integrator's PowerPoint numbers. If the model shows utilization can clear 75%, rescue it. If it cannot even touch 60%, take the write-off, sell the equipment secondhand, recover what you can. Taking the loss takes guts — but it is cheap compared to an open-ended top-up spiral.
Three questions before your next project
A postmortem exists so the next one does not happen. These are the three questions I now ask every client before any automation decision. If you cannot answer them, do not sign anything.
First: can automation actually digest your order profile? Automation eats "stable, high-volume, predictable" orders. If your building does 20,000 orders a day in peak and 3,000 in the slow season — a seven-fold swing — which number do you size the line for? Size for peak and the equipment gathers dust half the year; size for average and peak season is manual anyway. Bluntly: volatile businesses have a structurally hard ROI case for automation. Get your ABC classification and wave strategy solid first, then talk equipment.
Second: is uptime in the contract? Forget "designed throughput." Demand "acceptance criteria." The contract should state: over 30 consecutive days, average daily volume of X orders, equipment uptime no less than 98% — miss it and there are penalties, free remediation, or return rights. Verbal promises do not count when things go wrong. I have said this to every client at least three times.
Third: are payments tied to milestones? 30/30/30/10, 40/40/20, whatever the split — the final payment stays in your pocket until acceptance criteria are met. I have seen too many contracts where 90% was paid the day equipment arrived, and afterward the integrator would not return a phone call. Whoever holds the money holds the leverage. Nowhere is that truer than in automation projects.
Automation itself is not the problem. The people running the numbers are. Machines do not lie to you; proposals do. Data does not lie to you; gut feeling does.
When was the last time you ran an honest ROI on that line of yours?
By Lao Mi, Supply Chain Veteran (20 yrs)
