One Robot, Multiple Shifts: How Utilization Stacking Can Improve Service-Robot Economics
Autonomous mobile robots are often sold with a simple promise: once deployed, they can work for
long hours without the constraints of a human shift. In practice, many robots spend substantial time
waiting - for an order, a user, an open elevator, a charged battery or a remote operator. That idle time
is not a small operational detail. It is one of the central economic problems in Robotics as a Service.
A recent Japanese field trial offers a useful way to think about the problem. Panasonic and Pasona are
testing the same Hakobo mobility platform for daytime concierge work and evening or night patrol at a
large tourism facility. The trial does not yet prove commercial returns, but it illustrates a disciplined
idea: utilization stacking.
Utilization stacking means assigning compatible jobs to the same robot during different parts of the
operating day. The objective is not to make one machine do everything. It is to spread the fixed cost of
mobility, compute, charging, remote supervision and maintenance across more productive hours.
Why idle time is the silent margin killer
A RaaS provider pays for the robot whether it is moving or parked. Capital, software, insurance,
connectivity, depot space and field support continue to accrue. A fleet that is technically available for
18 hours but paid for only four hours has a utilization problem, even if its navigation is excellent.
This is why deployed-unit count can be misleading. Better measures include productive hours per
robot-day, paid missions per available hour, human-assistance minutes, reset time between workflows
and contribution margin by mission type.
Choose compatible shifts, not random features
The temptation is to combine delivery, advertising, cleaning, guidance, inspection and security into
one product sheet. That usually creates a complicated machine with conflicting requirements. Good
utilization stacking starts with compatibility. Two shifts are compatible when they share most of the
same operating domain, mobility envelope, sensor set, charging location and field-support team.
● Compatible example: daytime guidance and after-hours facility patrol on the same paths.
● Potentially compatible: scheduled internal delivery and low-demand infrastructure inspection.
● Usually incompatible without strict controls: food delivery followed by waste handling or cleaning.
● Commercially weak: adding advertising simply because the robot has a screen, without a paying
media customer.
Design the shift change as a safety-critical state transition
A multi-purpose robot needs more than a menu setting. Each mission mode should define permitted
routes, speed, stopping behaviour, active sensors, privacy rules, payload configuration, lighting,
audible cues and remote-operator procedures. The transition between modes should verify the correct
module, battery state, camera configuration and software version before the next shift begins.
Fainzy perspective
A proposed strategy for Fainzy would be to build a stable indoor/outdoor mobility base with controlled
mission modules, rather than claiming one universal robot. ZiBOT or MiraX could expose common
interfaces for power, data, locking and module identity while each workflow retains its own ODD,
safety limits and acceptance tests.
A first experiment could pair scheduled internal delivery during peak periods with a low-risk inspection
route during quieter hours at the same controlled site. The commercial goal would be to test whether
the second shift increases productive robot-hours without increasing intervention cost or weakening
the safety case. This is a proposed experiment, not a statement of current Fainzy capability.
The bottom line
The strongest multi-purpose robot is not the one with the longest feature list. It is the one that can
change jobs predictably, safely and economically. Utilization stacking works when every shift has an
owner, an outcome, a bounded operating domain and a measured changeover cost.