Pricing a Maintenance Contract for Connected Equipment

A maintenance contract for a pump is a settled genre. Annual inspection, defined response time, spares held or not held, an hourly rate for anything outside scope. Everyone in the room has signed a hundred of them and knows where the arguments will be.

Put a controller, a network connection and a firmware release cycle into that pump skid and the genre stops working. Not dramatically — the contract still gets signed — but a year later both parties are unhappy and neither can point at the clause that failed them.

What changes is that the equipment now has an obligation that never appears in the mechanical version: it has to keep working in a world that keeps moving. The customer's IT department will change something. A certificate will expire. A vulnerability will be published against a library inside the device. The mobile app the operators use will stop supporting the phone OS they have. None of these are faults. Nothing broke. The equipment is exactly as it was on the day it was commissioned, and that is the problem.

So the first thing a contract for connected equipment needs is a maintenance obligation on the software side that is separate from fault repair. Who produces updates, how often, for how many years, and what happens after that. Security patches specifically — with a target time from disclosure, distinguishing critical from routine, because "we release updates periodically" means nothing to anyone trying to complete a risk assessment. And an end-of-support date stated plainly, rather than discovered by a customer four years later when they ask for a patch and get silence.

The second thing is who does the work. Applying a firmware update to equipment in production is not a download; it's a change, and changes need a window, a test, a rollback plan and someone authorised to press the button. Many contracts are silent on this and both sides assume the other is responsible. The result is equipment running three-year-old firmware with known issues, while the vendor believes it has been diligent because updates were published.

Pricing is where the mechanical habit does the most damage. The vendor's cost for a connected product is not a truck roll; it is engineering time spread across a fleet, hosting, certificate management and a support function that answers questions rather than replaces parts. That cost is roughly constant per year per installed unit and does not go away in a year when nothing breaks. A contract priced as "callouts and spares" will therefore be either loss-making for the vendor or padded in a way the customer resents. Price the software obligation as its own line, per device or per site, and let the physical service be priced the way it always was.

Both sides should also settle the question of data before it becomes an argument. Who owns what the equipment produces, where it is stored, what happens to it at the end of the contract, and whether the vendor may use it in aggregate. This is cheap to agree at the start and expensive to litigate at the end, and the customer who has never asked is usually the one who will care most when they find out.

One last clause is worth more than it costs: what happens if the vendor stops trading or discontinues the product line. Source code escrow, a commitment to publish the local protocol, a right to continue operating without the cloud service. Vendors resist it, and the ones confident in their business resist it least. For a customer buying equipment with a twenty-year life from a supplier with a five-year history, it's the most important thing in the document.