The business case usually starts the same way. A robot costs this much, a picker costs that much per year, divide, and there is your payback period.
That calculation is wrong in both directions, and it is why automation projects either get killed unfairly or approved on numbers nobody can defend eighteen months later.
Why the Simple Comparison Fails
It overstates the saving by ignoring integration, maintenance, downtime and the supervision a robot still needs. It understates the benefit by ignoring throughput consistency, night coverage, injury reduction and the recruitment cost of a role with high turnover.
Those errors do not cancel out. They just make the number unreliable in a way that becomes obvious to your CFO about ten minutes into the meeting.
The Numbers You Actually Need
| Input | Where to get it | Common error |
|---|---|---|
| Fully loaded labour cost | Payroll, not the wage | Forgetting turnover and training |
| Actual throughput per hour | Your WMS, on a normal day | Using a peak-day figure |
| Robot throughput | Vendor figure, discounted | Trusting the demo rate |
| Expected uptime | Ask for a reference customer number | Assuming near-perfect |
| Integration cost | Quote it separately | Bundling it into the robot price |
| Facility changes | Walk the floor with the vendor | Discovering the floor is uneven |
| Exception rate | Your current error data | Assuming robots have none |
The Metric That Decides It
Cost per unit handled, measured across a full cycle including exceptions, downtime and supervision. Not cost per hour, and definitely not headcount reduction.
Headcount is a poor proxy because most successful deployments redeploy people rather than remove them, and the benefit shows up as more throughput from the same team. If your business case only works through redundancies, it is fragile both financially and politically.
Where Automation Reliably Pays
- Horizontal movement. Moving goods across a floor is structured, repetitive and well solved.
- High-volume, low-variety picking. Fewer object types means higher reliability.
- Night and weekend coverage. Where labour is expensive or simply unavailable.
- Physically punishing tasks. Injury and turnover costs are real and usually under-counted.
- Cycle counting and inventory. Tedious for humans, easy for machines, immediately valuable.
Where It Usually Disappoints
High-variety manipulation, anything requiring judgement about damaged goods, and facilities where layout changes seasonally. Robots reward consistency, and if your operation changes shape every quarter you will spend the savings on reconfiguration.
Also be honest about your data. Automation exposes bad master data instantly. If your dimensions and weights are wrong in the system, that is your first project, and it is not a robotics project.
Conclusion
Model cost per unit handled across a full cycle rather than robot price against wages. Discount vendor throughput figures, get an uptime number from a reference customer, and quote integration separately. Start with horizontal movement or cycle counting, both of which pay back on their own. And fix your master data first, because automation does not tolerate the approximations your team has been quietly correcting for years.
Frequently Asked Questions
What payback period should we target?
Under two years is comfortable for most operations, under three is defensible. Beyond that you are betting on volumes and a facility footprint you cannot forecast.
Should we pilot or commit?
Pilot, in one zone, with the exception rate measured properly. A pilot that skips exception measurement tells you nothing useful about the full deployment.
What about robotics as a service?
Useful for converting capital expenditure into operating expenditure and for shifting maintenance risk. Check the throughput commitments and what happens when they are missed, because that is the whole value of the arrangement.