For years, automation business cases could hide a surprising amount of uncertainty inside the equipment line. This week offered a useful correction.

A securities filing involving Agility Robotics put unusually specific assumptions around the economics of its Digit humanoid. Hai Robotics announced a 1,500-plus-robot fulfillment project. And Vecna Robotics pointed to a GEODIS operation where its CaseFlow system reportedly doubled picking throughput.

Different machines. Different maturity levels. Different workflows.

But together they expose a more important question for operators: How many economically productive hours will the operation actually get from the automation—not simply how many hours will the equipment be available?

Uptime Is Not Productive Time

Agility’s filing is interesting because it makes assumptions visible.

One illustrative model for Digit v5 assumes roughly $200,000 for the robot, a $20,000 deployment fee, and about $36,000 per year for software and maintenance. Over an assumed five-year useful life, that approaches $400,000. These are modeling assumptions, not quoted customer pricing, and Agility explicitly notes that contracts are negotiated.

The important number is not $400,000.

It is everything required to make that $400,000 productive.

A robot expected to operate across multiple shifts has a very different economic profile from the same asset spending hours waiting for work, recovering from exceptions, charging, being serviced, or operating well below its designed rate.

This distinction between uptime and productive time is important. I have seen plenty of systems report good uptime while actual performance remained far from design performance. The losses were often elsewhere: exception handling, recurring micro-stops, poorly designed flow bottlenecks, or processes that could not sustain the expected throughput during peak hours.

None of those necessarily makes the equipment look unavailable. But all of them reduce the productivity of the system.

That distinction becomes more consequential as systems get larger.

Hai Robotics says a European fashion retailer has selected more than 1,500 HaiPick Climb robots for a 30,000-square-meter automated fulfillment operation with 1.2 million storage locations. The system is designed for throughput exceeding 24,000 totes per hour. This is a selected project, not evidence that those operating results have already been achieved.

At that scale, robot capability is only one part of the performance equation. Inventory accuracy, induction, workstation design, order release, replenishment, controls, software orchestration, maintenance capacity, and exception handling all determine whether theoretical capacity becomes sustained productive throughput.

Then consider a smaller workflow.

Vecna Robotics reported that GEODIS increased CaseFlow picking throughput from 125 to 250 units per hour. The reported improvement points toward a different economic mechanism: reducing travel and changing how people interact with the workflow, rather than evaluating automation primarily through machine speed.

This is what others may be missing.

As automation becomes more flexible, intelligent, and software-defined, more of the investment risk moves from the purchase price of the asset to the operation’s ability to turn available hours into productive hours.

A lower robot price helps. Higher technical availability helps. Better AI helps.

But uptime is not throughput, and throughput during a controlled test is not necessarily throughput during peak.

The Productive-Hour Test

Before approving an automation business case, I would separate three numbers that are too often treated as one:

• Available time: How many scheduled hours is the equipment technically capable of running after faults, maintenance, charging, and planned downtime?
• Productive time: During those available hours, how much time is the system actually processing economically useful work rather than waiting, recovering from exceptions, experiencing micro-stops, or being constrained elsewhere?
• Sustained performance: During productive time, what percentage of design throughput can the operation maintain under real order mix, labor conditions, variability, and peak demand?

This distinction changes the ROI discussion.

A system can have 95% uptime and still disappoint economically if it spends significant portions of that available time starved for work, blocked downstream, recovering from exceptions, or running below design rate.

So I would test the business case at the system level.

Start with the expected productive utilization. Then model what happens at 90%, 75%, and 60% of that assumption. At each level, ask what caused the loss.

Was the equipment unavailable? Or was it available but unable to produce?

That second question is often more revealing. It forces the team to examine the architecture around the machine: upstream flow, downstream capacity, exception rates, controls logic, labor response, inventory accuracy, software orchestration, maintenance, and peak-hour behavior.

Then identify the break point: the productive-utilization level below which the investment no longer clears its financial hurdle.

That number belongs in the capital-approval discussion alongside equipment cost, labor savings, and payback.

If the project only works when the system operates close to theoretical performance, the automation may be technically excellent. The investment case is simply fragile.

Price Transparency Should Raise the Standard

More visible robotics economics are useful because they let operators move beyond abstract arguments about whether robots are becoming “cheap enough.”

But lower equipment cost does not eliminate automation risk. It changes where we should look for it.

As physical AI expands the set of tasks machines can perform, the economic question increasingly becomes whether the surrounding operation can create enough productive work, manage exceptions efficiently, and sustain performance when demand and variability are highest.

That should raise the standard for automation business cases. Do not approve only an expected utilization number. Ask the team to expose the losses between scheduled time, available time, productive time, and sustained throughput—and show how sensitive the return is to each.

Before approving the next automation investment, ask one question: At what level of productive utilization does this business case stop working, and what operating constraint is most likely to take us there?

If this question is active in your organization, reply and tell me where the operating reality differs from the technology narrative.