Why most robot pilots never reach production.

McKinsey's work on manufacturing describes a pattern it calls pilot purgatory, where roughly two thirds of organisations remain stuck in pilot mode and only about a third scale across the enterprise.1 That research is about AI programs rather than robot cells specifically, so treat the number as an analogy rather than a measurement of robotics. But the shape of the failure is identical, and everyone who deploys automation for a living recognises it immediately.

What follows is not research. It is what I have seen, so weigh it accordingly. I have tried to write each item as something you can check against your own project rather than as a general observation.

1. Nobody owned part presentation

This is the big one. It is the cause in more stalled cells than everything else on this list combined.

A robot needs the part to arrive in a known position, in a known orientation, within a known tolerance, every single time. That is part presentation, and it is fixtures, trays, conveyors, bins, dunnage, vision, and someone deciding whose job it is to load them. In a quote, part presentation is often either absent, or listed as "by customer", which means absent.

So the integrator builds a cell that works perfectly given a correctly presented part, hands it over, and the plant discovers that presenting the part correctly is a job nobody costed, staffed or designed. The robot sits idle while an operator hand-loads a fixture, at which point the cell is slower than the manual process it replaced.

Put this in the contract: "Part presentation for the part numbers listed in Appendix A is in scope, including fixtures, dunnage and any conveyance, and the acceptance test shall be performed with parts presented by the method that will be used in production."

2. The pilot ran the easy part

Every plant has one part that is flat, rigid, high-contrast and dimensionally boring. It is very tempting to pilot on that part, because it de-risks the pilot.

It de-risks the wrong thing. Nobody doubts the robot can pick a flat rigid part. What is genuinely uncertain is whether the cell survives the warped one, the one with flash on the parting line, the one that arrives in a different bin because second shift ran out of the usual ones. Piloting the easy part converts a project's only cheap opportunity to discover those problems into a demonstration of something you already knew.

Then the pilot succeeds, the cell goes to production, and the real mix breaks it in week two, with the purchase order already closed and your leverage gone.

Put this in the contract: "The acceptance test shall include part numbers X, Y and Z, selected to represent the range of geometry and condition the cell will encounter, including at least one part the parties agree is difficult."

3. Done was never a number

Ask a stalled project what its acceptance criteria were and you will frequently get a sentence like "the cell shall reliably perform the deburring operation". That is not a criterion. It cannot be passed and it cannot be failed, which means the project cannot end.

The consequence is not usually a dispute. It is drift. The cell mostly works, some parts need rework, nobody can point to a written line it has crossed or failed to cross, and the project quietly stops being anyone's priority.

Put this in the contract: a table with cycle time in seconds per part, first-pass yield as a percentage, a continuous run duration the cell must complete without human intervention, the part numbers in scope, and the changeover time between them. Five numbers. Agreed before the purchase order, not after commissioning.

4. The cell had no owner on Monday

The integrator finishes, trains three people, and leaves. Six weeks later one of the three has moved to nights, one has left, and the third was never really the owner. A gripper pad wears, the cell starts dropping one part in fifty, and there is no person whose job includes noticing.

A cell is a machine on your floor and it needs the same thing every other machine on your floor needs: a named owner, a maintenance interval, and spares in a drawer. Automation projects skip this far more often than machine tool purchases do, I think because a robot arrives framed as a technology project rather than as equipment.

Put this in the contract, and in your own plan: a named cell owner before commissioning starts, that person present for the whole acceptance test, a written preventive maintenance interval, and a spares list with the wear items identified and at least one of each on site at handover.

5. The pilot was scoped to prove feasibility, not to run

This one is subtle and it is the most expensive.

A feasibility pilot asks: can a robot do this? It gets built on a bench, in a corner, off the production network, with a laptop taped to the frame. It succeeds. And then it turns out that nothing about it transfers, because a production cell needs guarding, a safety assessment, an interlock strategy, a place in the plant's electrical and network topology, an operator interface someone can actually use on a night shift, and a physical footprint that does not block a forklift aisle.

The feasibility pilot answered a question nobody needed answered. Robots have been able to do these tasks for years. The question is whether this cell, in your plant, with your people, produces parts on a Tuesday.

Put this in the contract: "The pilot shall be installed in its production location, on production power and network, with production guarding and safety systems, and shall produce saleable parts." If a vendor will not pilot into production conditions, you are buying a demonstration.

The pattern underneath all five

Every one of these is the same mistake in a different costume: treating the robot as the project. The robot is the least uncertain component in the entire system. It is a mature, well-understood, heavily commoditised piece of equipment with published specifications, and it will do what the datasheet says.

The risk in a robot project is never in the robot. It is in everything that touches it.

Which means the useful question when you are evaluating a vendor is not what arm they use or what their demo looks like. It is how much of the surrounding system they will take responsibility for in writing, and what they have agreed to do when part number 41 shows up. Our integrator guide works through that from the buying side, disclosure included.

If you want a second pair of eyes on a project that has stalled, that is a conversation I am always happy to have, whether or not it goes anywhere commercially. There is a contact form, or you can book a call.