The cheapest robot can become the most expensive automation

Four stages, not one

Comparing on price covers only the first of the four stages in which project costs appear.

• BUY

  What you pay to own the robot

  Purchase price, accessories, chargers, software licences and warranty.

• DEPLOY

  What you pay to make it work in your flow

  Flow engineering, configuration, commissioning, interfaces with doors, lifts and conveyors, IT integration and training.

• RUN

  What you pay to keep it running

  Support, maintenance, spare parts, response time, downtime, cybersecurity and the protection of production data.

• SCALE

  What you pay when the system grows

  Additional robots, new flows, layout changes, and how far the existing configuration can be reused.

BUY: the easiest part to compare

This is the simplest stage to compare, because quotations start from the same basic elements: a price, a configuration and a delivery date.

It is still worth checking exactly what each quotation includes: the robot and its configuration, the charger or charging infrastructure, the accessories the application needs, the fleet manager, software licences, and the warranty and support terms. Two apparently comparable prices can cover different configurations and different services.

Once the quotations are on the same basis, the conversation about cost is only beginning.

DEPLOY: where the cost of implementation starts

The demo and real operation

An AMR can look impeccable in a demo. The route is clear, the pallet is in good condition, there is a single load, and nobody walks in front of the robot at the wrong moment.

In production things look different: damaged pallets, loose wrapping film, goods overhanging the pallet edge, a forklift parked temporarily on the route, a marking that was changed last week. The difference between platforms shows in how they handle these situations, and in how often an operator has to step in.

Every plant and every warehouse has its own exceptions: a damaged or unevenly loaded pallet the robot cannot pick up safely, an occupied drop-off point, or an urgent order that changes priorities mid-shift.

These situations show up directly in operation. A platform that handles them well can keep running with minimal intervention. One that frequently needs an operator produces short, repeated stoppages, calls to support, and people ending up resolving manually what the system should have handled itself.

Engineering, integration and commissioning

Implementation takes engineering time, and that effort has a direct cost. Flows, pickup and drop-off points, traffic rules, priorities, interfaces and the system's behaviour in exception cases all have to be configured.

The difference between platforms also shows in the effort needed to get from configuration to stable operation. One case is a standard implementation completed in a few days, followed by hypercare. Another is a project requiring dozens of days of configuration, testing and adjustment.

The cost is not only the supplier's services. A long implementation requires availability from production and involvement from the internal team for longer.

And that effort does not only matter at the start. A platform that is difficult to configure stays more expensive when a map has to be modified, a flow changed, a pickup or drop-off point added, or a problem diagnosed.

Infrastructure and automation interfaces

A properly conducted project analysis should identify from the outset the infrastructure the application requires: automatic doors, lifts, conveyors, sensors, charging stations, or other equipment the AMR system has to interact with. These elements and their associated costs need to be known before the purchase decision.

The difference between platforms appears in integration complexity: how much additional hardware is needed, how standardised the interfaces are, and how much engineering effort their configuration requires.

The same difference reappears when the infrastructure or the flow changes later. The more standardised and easily configurable the interfaces, the simpler the changes and the less engineering time they take.

IT interfaces and training

If the robot receives orders from a WMS, ERP or MES, the integration with that system has to be built and then maintained. Some platforms come with standard interfaces and documentation. Others require dedicated development, and the difference is measured in person-days, both at initial implementation and at every later change.

Training matters just as much. When operators can resolve routine situations themselves, the system returns to operation quickly. When any minor incident requires the supplier, the same situation becomes a support call and a longer stoppage.

RUN: what you pay to keep the system running

Support, parts and response time

What matters is how quickly someone responds, in which language, within which hours, and with what level of access to the system. The difference between a response time of a few hours and one of several days becomes significant when the robot is part of an operational flow.

The same is true of spare parts. A part that arrives in two days and one that arrives in six weeks have very different operational consequences, whatever the part itself costs.

Downtime

Downtime can change the economics of a project quickly. The cost of a stoppage is not limited to the failed component. In a flow running three shifts, the production or the dispatch that is waiting counts too.

And once the flow has been reorganised around the robots, temporarily reverting to the manual version is not necessarily simple or fast.

Confidentiality and cybersecurity

An AMR system operates inside the plant and processes information about the environment it works in. Navigation maps, routes, operating logs and mission data can describe sensitive processes and areas. If the robots use 2D or 3D cameras, the system may also process images from production. A standard LiDAR does not record video and does not produce photographic images, but its measurements describe the geometry of the environment and can be used for navigation and mapping.

For the operator of the plant, then, what matters is not only which sensors the robot carries, but which data is generated, where it is processed, whether it is stored, which data can leave the plant network, and who can access it. In industries where layout, products or processes are confidential, controlling that data also becomes a question of protecting industrial know-how.

In many AMR architectures the robots communicate over the plant Wi-Fi with a fleet manager running locally. The system can also have external connections, for example for diagnostics, remote support, transmitting operating data, or advanced KPI analysis. The existence of such functions is not in itself a problem. What matters is that they are known, documented and controllable by the operator.

A serious cybersecurity assessment should clarify which external connections the system can initiate, to which destinations, what types of data can be transmitted, and whether those communications can be limited or disabled. The same principle applies to the software components and services that form part of the platform, including those not directly visible to the operator.

Local processing, network segmentation, access control, secured communications and logging of remote access all reduce data exposure and the attack surface. For sensitive information the useful principle is simple: data that should not leave the plant ought to be able to stay in the plant.

Cybersecurity and confidentiality are not topics separate from the automation project. In a connected platform used daily in production, they are part of the system architecture and part of the total project risk.

Long-term operation and maintenance

One important question remains: how easily can the system be maintained over the long term?

A robot bought today has to be working in five years' time. That means updated software, available parts, documentation, and people who know the system well enough to intervene. The manufacturer matters, so does the integration partner, and so does how dependent operation is on tools, licences or services the operator does not directly control.

Long-term maintenance is not only about parts availability. It is also about being able to update, diagnose and modify the system without every intervention becoming a new project.

SCALE: when a few robots become a fleet

With a single robot the system logic is relatively simple. From two or three robots upwards, interactions already appear between missions, priorities, traffic and charging. In a fleet of five, ten or more, the fleet manager's ability to orchestrate the system becomes essential.

As the fleet grows, differences between platforms matter more. Some handle traffic, priorities, shared charging points and robot-to-robot interactions natively. Others require progressively more configuration and engineering as the fleet and the number of flows increase.

A new flow reveals how much of the existing configuration can be reused. If every extension takes roughly the same engineering effort as the original project, the advantage of scaling shrinks considerably.

Over time the layout changes: a line is moved, a picking area is added, dispatch is reorganised, or a new flow appears. The practical question is how easily those changes can be made. Can they be handled through configuration by the internal team or the integrator, or do they require additional development and the manufacturer's involvement?

When the inexpensive solution is the right choice

None of this means the more expensive platform is automatically the better choice.

A cheaper solution can be exactly the right one if it deploys quickly, integrates well into the real flow, runs stably, and can be extended without every change becoming a new engineering project. There are applications where precisely that happens, and the price difference remains a genuine advantage.

The point is not to choose the more expensive robot. The point is to compare the cost and the risk of the whole project, from BUY through to SCALE, rather than the purchase price alone.