Alfred AnyanInsights
← All insights

Hardware Uptime: What a Maintenance Log Taught Kojo About Selling Reliability

Engineer examines heavy machinery in an industrial site, showcasing technical expertise.

Photo by abdo alshreef on Pexels

A second machine stops mattering when the buyer values uninterrupted output more than additional hardware. At that point, the founder has to decide whether to keep selling units or take responsibility for uptime.

Kojo is an invented composite, drawn from the decisions hardware founders face. At 4:40 on a Friday afternoon in Accra, he joined a buyer call with a revised production quote open on his laptop and a cold coffee beside it. The first machine had completed its pilot. He expected the operations lead to ask how quickly his team could deliver another.

Instead, she shared a maintenance log.

The order disappeared inside the maintenance log

The machine had stopped twice during the pilot. Neither failure had destroyed equipment, but each one had interrupted a shift while the buyer’s team waited for Kojo’s engineer to diagnose the problem.

The operations lead wanted to know what would happen after a larger rollout. Would Kojo monitor the machines? Who would respond when one failed outside working hours? How long would common replacement parts take to reach the site? Could the buyer see warning signs before output stopped?

Kojo answered carefully. His team could offer support, hold selected parts and add remote monitoring. Then the question that changed the call arrived.

“If we buy a second machine, does that improve our output, or does it give us two machines that can stop?”

The larger order was no longer waiting for a revised quote. The buyer could pause the rollout, keep the pilot unit and choose another supplier with a clearer support commitment.

Kojo had entered the call prepared to defend the machine’s price. He left needing to define what the company was willing to guarantee.

The buyer was purchasing a working production hour

Hardware founders naturally organise the business around units. A unit has a bill of materials, assembly time, shipping cost and sales price. Those numbers can fit into a forecast.

The buyer’s calculation starts elsewhere. They care about the hours when production can run, the staff who can keep working and the orders that leave on schedule. A cheaper machine with uncertain recovery can cost more than an expensive one with predictable support.

That shift changes product strategy. Reliability can no longer remain a broad promise in a sales deck. It has to become a set of operating decisions.

What can the company observe remotely? Which faults can a customer resolve without waiting for an engineer? Which parts must remain nearby? What response can a small team sustain across Ghana, Germany and the US without pretending to offer round-the-clock coverage?

Those questions expose the difference between a useful sales claim and an obligation the company can carry. They also surface assumptions hidden by finished hardware, much like finished CAD can hide the wrong manufacturing assumption.

Selling uptime changes the product and the company

On Monday morning, Kojo did not begin with a subscription price. He put the pilot maintenance log beside the product roadmap and marked every failure his team could have detected earlier.

One fault required a design change. Another needed a clearer diagnostic message. A third exposed a spare-part decision nobody owned. The work cut across engineering, support, inventory and contracts.

This is where an uptime offer becomes difficult. The recurring invoice may look attractive, especially for a hardware company with uneven unit sales. Yet the revenue arrives with recurring responsibility.

A founder considering this model needs to calculate the burden before naming the package. Start with the response the current team can deliver. Separate remote diagnosis from on-site repair. Decide which incidents qualify for service credits, if any. Record what the customer must provide, including connectivity, trained operators or basic maintenance.

Then test the commercial question: will the buyer pay enough for that responsibility to support the people, parts and monitoring behind it?

There is another constraint. A reliability promise can force roadmap choices that feel less exciting than new hardware. Better logs may outrank a new interface. Easier part replacement may matter more than another feature. Documentation may protect output better than a second prototype.

Founders who already face a smaller engineering team will recognise the trade-off. Kojo’s redesigned product plan after a senior engineer resigned begins from the same hard truth: capacity decides which promises survive.

The next proposal began with failure

By the following Friday, Kojo’s proposal looked different. The second machine remained in it, but the first page described the conditions required to keep production running: what his team would monitor, how faults would be classified, which parts would be held and where the support boundary ended.

He also removed one promise his team could not reliably meet. That made the offer narrower. It made the risk legible too.

The buyer still had a decision to make, and the larger order remained unresolved. Kojo had gained something more useful than premature confidence. He now knew what the buyer would judge after installation.

Before quoting your next unit, take the last failure log into the sales meeting. Circle every interruption the customer had to discover first. The service business begins in those circles.

Comments

No comments yet.