Pay when it runs

Objections to automation projects cluster into five, and they show up in roughly this order: cost, confusion about too many vendors and options, time (the thirty-five week problem), maintenance, and commitment.

The first three are addressable with better process. The fourth is a service design question. The fifth is the one that quietly kills deals, and it is rarely stated directly. What if we buy this and it doesn't work? What if our product mix changes in two years and we own a very expensive single-purpose machine?

You cannot argue someone out of that concern. It is a rational response to a capital commitment made against a projection. The only convincing answer is structural: don't ask them to pay for the projection. Ask them to pay for the result.

Productivity-linked billing means the customer does not begin paying until the cell reaches an agreed rate, and that billing suspends when the cell is down. It sounds like a pricing gimmick. It is actually a set of engineering requirements, and they are not trivial.

Acceptance has to be real

If billing starts at a proven rate, that rate needs a definition and evidence. This is what the standard chain exists for. Factory acceptance runs at the integrator's facility (cycle counts at rate, a defect log, a punch list), and it is the last cost-effective moment to reject anything. A defect caught there costs roughly an order of magnitude less than the same defect found on the customer's floor. Site acceptance validates installation and real performance with real product mix. Commissioning proves the cell works inside the whole line rather than standing alone. Sustained operation at the agreed rate is the event that starts billing.

Those milestones stop being paperwork and become the payment spine.

Telemetry becomes a billing primitive

If downtime suspends billing, uptime measurement is no longer a dashboard; it is revenue infrastructure, and it needs the correctness discipline that implies. Every hour is billable or it isn't, and the customer will check.

Underwriting changes shape

A financing partner asked to fund an asset whose payments depend on performance needs to see performance data. The accumulating record of specifications, benchmarked quotes, acceptance evidence, and live uptime across deployed cells is precisely that dataset. Each completed deal makes the next one cheaper to underwrite.

Risk should sit with the party holding the information.

There is a fair objection: this transfers risk from the customer onto whoever structures the deal. That is the point. The party best positioned to judge whether a cell will hit its rate is the party that specified it, benchmarked it, and has run the same template before.

Customers do not want robots. They want productivity. Charging for the second thing rather than the first is the honest version of that sentence.