The shift to automation usually requires a substantial upfront capital expenditure. The true outlay often goes beyond the sticker price of hardware, encompassing software integration, facility modification, workforce training, as well as potential downtime during deployment.
A miscalculated CapEx can tie up critical company capital for years. Therefore, making a rigorous financial analysis, one that accurately maps the total cost of ownership against long-term efficiency gains, is absolutely essential before a purchase order is signed.
This article walks through what an honest warehouse automation ROI calculation looks like. It covers the five benefit categories that most cases include, the costs that most cases miss, a worked example structure, and how to stress-test the answer before you commit.
The five categories of benefit
A defensible business case usually rests on some combination of five sources of return:
1. Labour savings
The largest line in most warehouse automation cases is labour. If a goods-to-person system lets a picker work at three times the rate, you need a third of the pickers. Multiply by fully-loaded labour cost and the number is large.
The problem is that real labour reductions rarely match the design assumption. Pickers do not pick for eight hours of an eight-hour shift. They cover absence, train new starters, handle exceptions the system cannot, and do the work that sits adjacent to picking.
The other issue is what the saving actually represents. If you remove ten warehouse operatives from a 3PL contract, that is a cash saving. If you remove ten operatives from your own operation and redeploy them to higher-value work, that is a productivity gain. The business case needs to be clear on the difference.
2. Capacity and throughput
Automation can allow a warehouse to handle more orders per day, more lines per order, or more peak volume without adding floor space or shifts.
Vendors will quote throughput at the sustained maximum the equipment can support under ideal conditions. However, real operations run at a lower average, with peaks that test the design and troughs where the equipment is underused. The business case should be built on the realistic operating profile, not the peak design figure, with a separate line of reasoning for what peak capacity is worth.
Peak capacity has value, but it is option value rather than guaranteed return. If your peak is twice your average, the case for sizing the automation to handle peak rests on what happens when you cannot. The cost of overflow, expediting, or turning business away is what justifies the peak capacity headroom, and that number needs to be in the case explicitly.
3. Space efficiency
Automation, particularly high-density ASRS and goods-to-person systems, can store significantly more SKUs in the same building footprint. For operations that are constrained by space and would otherwise need to extend or relocate, this is often the largest single benefit in the case.
However, “the new system stores three times more than the existing racking” is on its own misleading. The relevant figure is the cost of the additional space you would otherwise need, including the cost and disruption of acquiring it, against the cost of the automation that avoids it.
If the alternative is renting more space at a known cost per square metre, the calculation is fairly straightforward. If the alternative is building or extending, the calculation needs to include the time and risk of doing so.
4. Service level and quality
Automation usually improves consistency: Pick accuracy goes up, mis-ships go down, OTIF improves, returns processing accelerates.
Your business case needs to quantify the current cost of failure. What does a mis-ship cost in remediation, return logistics, and lost customer lifetime value? What is the OTIF gap costing in retailer fines, lost listings, or chargebacks? Once those numbers exist, the business case can claim a proportion of them as recoverable through automation, with the proportion being a defensible assumption rather than a hopeful one.
5. Risk reduction
The fifth category is reduction in operational risk. Automation can reduce dependency on a labour market that is tightening, reduce injury rates in physically demanding roles, and reduce single-points-of-failure where the operation depends on one or two experienced people.
The right way to handle this is usually a sensitivity rather than a base-case number. Show the case at today’s labour cost, then show what it looks like if labour cost rises by 5%, 10%, or 15% a year. The case that survives the higher numbers is the one worth defending.
The costs most cases miss
On the other side of the coin, a good Warehouse automation business case also needs to consider the costs that are probably not in the vendor’s quote. Some examples include:
The implementation dip
Installing automation in a live warehouse temporarily reduces productivity. Sections of the building are out of use, staff have to split attention between the existing operation and the new system. Parallel running, where the old and new processes both operate while the new one is proven, doubles the workload for the period it lasts.
Change management and training
A serious automation project needs investment in training, in change management capacity inside the operation, and in the time of experienced staff who are pulled away from their day jobs to define how the new system should work. None of this is automation cost in the narrow sense, but it is a real cost, and should be included in a good business case.
Maintenance, spares, and software
Most vendor quotes cover the first year of support. A good business case needs to include realistic figures to support the automation’s full lifecycle.
As a broad orientation, ongoing maintenance and software costs typically run anywhere from 5-20% of original capex per year. As it varies significantly by technology, it’s important to have confidence in these numbers.
Residual labour
Automation reduces certain types of work and leaves others unchanged or even increases them. Exception handling, system supervision, maintenance liaison, inbound and outbound coordination, returns processing, and the long tail of tasks that automation does not touch all still need people.
The honest residual labour figure is usually significantly higher than the early business case assumes.
Forecast risk
The business case is built on a volume forecast, it’s important to understand how wrong that forecast can be before the case stops working.
A case that breaks if volume comes in 10% below forecast is a fragile case. A case that still pays back, more slowly, at 20% below forecast is a robust one. The case should be tested at multiple volume scenarios and the result of each made explicit, so the decision-makers know what they are signing up to.
Exit and obsolescence
What happens to the automation in fifteen years, when the lease ends, the operation moves, or the technology is superseded. Specialist warehouse automation typically has limited resale value and significant decommissioning cost.
Payback, NPV, or IRR
Three metrics are routinely used to assess warehouse automation: Payback period, Net Present Value, and Internal Rate of Return. They answer different questions and the right one depends on what the decision-maker actually wants to know.
Payback period answers how quickly you get your money back. It is simple, intuitive, and biased toward short-horizon thinking. For automation, which typically has a 10-15 year economic life, payback period understates the case for the better systems.
Net present value (NPV) answers how much the project is worth in today’s money at the company’s cost of capital. It is the right metric for a capital decision of this size, because it captures the time value of money and the full economic life of the asset.
Internal rate of return (IRR) answers what return the project generates as a percentage. It is useful for comparing projects of different sizes and capital profiles, and most large operations will want to see it alongside NPV.
A serious business case includes all three, with the NPV as the primary number and payback period as the sanity check. A case that only quotes payback period is usually one where the longer-term economics are not as strong as the short-term ones, which is worth knowing.
How to stress-test before you commit
A business case that has been stress-tested is a different document from one that has not. Three tests matter more than the rest:
Volume sensitivity
Run the case at minus 10%, minus 20%, and minus 30% against forecast. The case should still hold at minus 10% if the forecast is credible. If it breaks at that level, either the forecast is too aggressive or the case is too tight.
Cost sensitivity
Run the case with capex 15% higher than quoted and maintenance 25% higher than assumed. Automation projects routinely overrun on both, and a case that only works at the quoted numbers is a case that probably will not work.
Timing sensitivity
Run the case assuming go-live slips by six months. Most automation projects slip, and the cost of the slip falls on the operation, not the vendor. A case that depends on the quoted timeline is more fragile than it looks.
If the case survives all three, the decision is defensible. If it does not, the question is not whether to redo the case, it is whether the project is the right one.
Working with a partner who knows the data
A well-constructed warehouse automation business case is not a vendor deliverable. Vendors have an interest in the project proceeding, their models will make generous assumptions on throughput, conservative assumptions on cost, and will not stress-test the result with any real enthusiasm.
Getting to a business case you can actually defend to a board or investment committee means doing the analytical work independently.
At Trym, that is what we do. We are supply chain consultants who are, first and foremost, obsessed with the data. We build financial models for automation decisions from scratch, stress-test them properly, and tell clients what the numbers actually say – including when the numbers say the investment does not stack up.
If you are building a business case for warehouse automation, or trying to sense-check one you have already been given, we can help. And if the right answer turns out to be something other than automation, we can help with that too.
About the author
Ashleigh’s work focuses on the performance of data analysis and production of statistical models to derive insights.
Ash has worked with start-ups, defence contractors, retailers and the NHS to derive value from data and solve big problems.