Robotics ROI and deployment cost

Why most robotics business cases are wrong

Not because the robot was too expensive. Because the business case counted the robot and little else, and because the baseline it was compared against never existed as a measurement.

This page sets out the cost categories and the structure of an honest return calculation. It contains no prices. Figures vary by an order of magnitude across platforms, regions, tasks and years, and a number invented here would be worse than no number. The point is to make sure nothing is missing from your own.

The costs beyond the robot

• Integration engineering. Connecting the robot to the systems that tell it what to do. Frequently the largest single line, frequently estimated from the happy path, and frequently dominated by exception handling.
• Environment modification. Guarding, floor marking, charging infrastructure, power, network coverage, lighting, racking changes, sometimes flooring. The robot is often not the thing that requires construction.
• Safety work. Risk assessment, protective measures, validation, documentation, and the competent person who performs them.
• Data collection. If the capability requires demonstrations, somebody provides them, on paid time, possibly repeatedly.
• Training. Operators, maintenance staff and supervisors, including the people who will be covering during the transition.
• Process redesign. The task as documented and the task as performed differ. Reconciling them is work, and it happens whether or not it was budgeted.
• Ongoing engineering. Products change, SKUs change, layouts change. A deployment that is not maintained degrades.
• Spares and service. Consumables, wear parts, grippers, batteries, and a service agreement.
• Software licensing. Per robot, per site or per task, recurring.
• Supervision. Somebody monitors and intervenes. The intervention rate determines how much of a person this consumes, and it is rarely zero.
• Opportunity cost during deployment. Commissioning happens in a working building and usually disrupts it.

The baseline, which decides everything

A return calculation compares against something. If nobody measured that something before the project started, the comparison is against a recollection, and recollections favour whoever is presenting.

What to measure, before anything is installed:

• Cycle time for the task, over enough instances to show its distribution rather than its average.
• Throughput per shift, including the variation between shifts and across the week.
• Error and rework rate, and what each error costs downstream.
• Labour actually applied to the task, including partial allocation and supervision.
• Exception rate and exception categories. This is the number that most often invalidates a projection.
• Downtime and its causes.
• Fully loaded cost per unit handled.

Measuring this has value even if the automation never happens, which is the honest reason to do it first.

Building a calculation that survives

• Model the intervention rate explicitly. A system requiring a person every twenty cycles has not removed a role; it has changed one. This single assumption moves most business cases more than hardware price does.
• Use availability, not uptime. Include recovery time, which usually exceeds fault time.
• Use the measured exception distribution. The long tail decides staffing, and the tail is where projections break.
• Model the ramp. Performance at commissioning is not steady-state performance, and the ramp can run for months.
• Include the re-scope. Assume one significant change of scope, because the first attempt reveals the task is not what was described.
• State the assumptions separately from the arithmetic, so a reviewer can argue with the assumptions rather than the spreadsheet.
• Run a pessimistic case. Not a sensitivity slider — an actual scenario in which the intervention rate is twice your estimate and the ramp is twice as long. If that case is survivable, the project is.

Where projections usually go wrong

• Assuming labour is removed rather than redeployed. Most first deployments change what people do; they rarely eliminate a headcount cleanly, and claiming otherwise damages trust internally.
• Counting peak throughput instead of sustained throughput at the required accuracy.
• Ignoring the exception tail because it was not visible in a short trial.
• Omitting ongoing engineering, which makes year one look like every year.
• Treating the pilot environment as representative when it was the tidiest corner of the site.
• Forgetting that the comparison is not robot versus nothing. It is robot versus the cheapest alternative — process change, different layout, better scheduling — which sometimes wins.

Robots-as-a-service

Subscription and per-unit pricing models shift capital cost into operating cost and shift some risk onto the supplier, which is genuinely useful for a first deployment. They do not remove integration, environment, safety, training or supervision cost, and those are frequently the larger part. Read what the recurring fee actually includes, what happens to your data, and what the exit looks like — including whether the environment modifications you paid for remain useful without that supplier.

Who should own the business case

Not the supplier, and not the person whose budget or promotion depends on approval. That sounds obvious and is routinely violated, usually because the supplier has the only model and the sponsor has the only enthusiasm.

A business case worth trusting has three properties: the assumptions are stated separately from the arithmetic so they can be argued with; the baseline was measured by someone other than the project sponsor; and someone with no stake in approval has reviewed the intervention-rate assumption, because that single number moves the result more than anything else.

It is also worth writing down, in advance, what result would mean stopping. A project without a defined failure condition cannot fail — it can only be extended — and extended projects consume the budget that the next, better-chosen project needed.

The honest summary

Robotics returns are real in bounded, high-volume, well-measured tasks, and they are rarely as fast or as clean as a proposal suggests. The projects that work tend to share three things: a task chosen for tractability rather than for impressiveness, a baseline measured before anything changed, and a business case that modelled the intervention rate honestly.

A supplier willing to discuss the second and third of those is more useful than one with a better robot.

Leasing, financing and how the cost is structured

How the cost is paid for changes which projects get approved, independently of whether they are good projects. Capital purchase puts the whole cost in one budget year and makes the asset yours, including the obligation to maintain and eventually dispose of it. Leasing spreads it and usually bundles service. Subscription or per-unit pricing moves it into operating budget entirely, which frequently matters more internally than the total.

What none of these change is the part that is usually larger than the hardware: integration, environment modification, safety work, training and ongoing engineering are paid in cash and staff time regardless of how the robot itself is financed. A proposal that makes the robot cheap and leaves those unstated has moved the number, not reduced it.

Comparing against the alternatives you did not consider

The comparison that matters is not robot versus nothing. It is robot versus every other way of achieving the same outcome, and automation frequently loses that comparison on honest numbers.

• Process change. Reordering steps, relocating a station, changing when work is scheduled. Often free and often sufficient.
• Fixed automation. A conveyor, a chute, a gravity feed. Unglamorous, cheap, extremely reliable, and the right answer more often than it is proposed.
• Better tooling for people. A lift assist, a better jig, improved lighting. Cheap, fast and usually ignored because it is not a project.
• Doing less. Some tasks exist because of a decision nobody revisits. Eliminating the task beats automating it.

A business case that evaluated these and rejected them with reasons is credible. One that compares a robot only against the status quo has not done the work, and the omission is usually visible to whoever approves it.

The measurement side of the same question: pilot acceptance criteria and scorecard.