Almost any robot looks capable for fifteen minutes in a controlled space. The properties that determine whether it is still doing useful work a year later are different, less visible, and rarely discussed in a sales conversation.
Success rate over many attempts
The first and most decisive property.
A demo shows one successful attempt. Real work is hundreds of attempts a day, and what matters is the proportion that succeed.
The difference compounds. A robot succeeding ninety-five times out of a hundred sounds excellent, and in a workplace doing three hundred cycles a day that is fifteen interventions daily. Whether that is acceptable depends entirely on how long each intervention takes and who is available to make it.
Ask for the number. Out of a hundred attempts under conditions resembling yours, how many succeed. A serious supplier has this figure or can produce it.
Measure it yourself during a trial. Count attempts and successes over several hours. The figure is usually lower than the impression left by watching a few good runs.
And ask about the failures. When it fails, does it stop safely, does it damage anything, and how long does recovery take. A robot that fails gracefully at ninety per cent beats one that fails badly at ninety-seven.
Behaviour when things go wrong
The property that most separates production equipment from prototypes.
Does it recognise failure? A robot that continues after a failed grip, producing a stream of errors, is worse than one that stops immediately.
Does it stop safely? Without dropping what it holds, without blocking a route, without leaving a person unable to recover the situation.
Can a person recover it easily? Recovery should take seconds and require no specialist. If clearing a jam needs a technician, the machine will spend a lot of time stopped.
Does it log what happened? Without a record, intermittent problems are unsolvable.
Does it resume correctly? After recovery, does it pick up where it should, or does it need reconfiguring?
These five questions are rarely covered in a demonstration because demonstrations are designed not to fail. They are exactly what should be tested during a trial, deliberately, by inducing failures rather than avoiding them.
Tolerance for the real environment
Demonstrations happen in prepared spaces. Work happens in ordinary ones.
Variable lighting. Sunlight through a window shifts through the day, and a vision system tuned in the morning may fail in the afternoon.
Noise. Speech recognition degrades sharply above a certain level, and real workplaces are loud.
Clutter. Items left in aisles, chairs pulled out, boxes stacked temporarily. These are normal and they are the leading cause of stoppages.
People moving unpredictably. Especially people not paying attention to the robot.
Dirt. Dust on sensors, spills on floors, marks on screens.
Variation in what it handles. Items that differ slightly from the sample, arrive at odd angles, or are occasionally the wrong item entirely.
The practical implication: a trial in your own space is worth more than any specification, because these six factors are properties of your environment rather than of the machine.
How much attention it needs
The property that decides whether a robot is still in use after six months.
Daily attention. Charging, cleaning, checking. A few minutes is sustainable; half an hour is not.
Weekly attention. Content updates, deeper cleaning, reviewing performance.
Skill required. Can ordinary staff handle routine care, or does everything need a specialist?
Consumables. How often, how expensive, and how easy to obtain locally.
Software updates. Automatic or manual, disruptive or seamless.
The honest question to ask a supplier. How much time per week does a customer typically spend looking after this. Vague answers usually mean more than expected.
Across many deployments, maintenance burden predicts abandonment better than reliability does. A robot that works well but demands constant attention gets quietly retired; one that is slightly less capable but nearly self-sufficient keeps running.
A checklist for a real trial
Design the trial around the properties above rather than around the demonstration script.
- Run several continuous hours, not fifteen minutes.
- Use your actual items and your actual space, at the actual busy hour.
- Count attempts and successes. Write the numbers down as they happen.
- Induce failures deliberately. Block the route, remove an item, cut the power, ask something out of scope.
- Let your own staff operate it, not the supplier's technician.
- Time a recovery. How long from stoppage to running again, performed by an ordinary employee.
- Note every time someone has to touch it. This is the maintenance burden made visible.
A trial run this way tells you more in one day than a month of specification comparison, and it costs very little compared with a purchase that turns out to be wrong.
Frequently asked questions
Which single number matters most?
Success rate over many attempts under conditions resembling yours. A demonstration shows one successful attempt; real work is hundreds a day, and the proportion that succeed determines how many interventions staff face.
Why test failures deliberately?
Because demonstrations are designed not to fail, so failure behaviour goes untested. How the robot stops, whether an ordinary employee can recover it in seconds, and whether it logs what happened all matter more than peak performance.
What predicts abandonment best?
Maintenance burden rather than reliability. A capable robot demanding constant attention gets quietly retired, while a slightly less capable but nearly self-sufficient one keeps running for years.
Why does a trial in your own space matter so much?
Because lighting, noise, clutter, unpredictable people, dirt and item variation are properties of your environment rather than of the machine — and they are what actually cause stoppages.
More in Myths and questions and Robots and jobs.
