What is the most expensive part of your product?

What a service visit really costs you, what it costs to stop sending one, and how to tell which of the two is bigger on your fleet.

Besides the investment itself - buying, renting or building a product - there's a stage that usually gets neglected. Some companies know exactly how much it costs, others know it indirectly - as a cost scattered across payroll, insurance and fuel. The stage we'll discuss in this blog post is maintenance. Service, truck roll - you name it. We will address everything from defining it, through measuring it, to remediation. Regardless of where you stand, you'll find something useful here. Let's jump directly into the topic.

What a visit actually costs

You know the drill: something stopped working, you got called, you sent someone to fix the problem. That is the cost. Fuel and the hourly rate are usually the only lines everyone remembers. The reality is more complex, so straight to the point:

• ‍The technician's day - the whole day, not the hour spent on the fault.‍
• The vehicle - per kilometre/mile, insurance, rent.‍
• The job that got displaced - the technician was supposed to install for a new customer? Too bad - the old one is suffering.‍
• The second visit - one in five trips typically repeats.‍
• Coordination - intake, scheduling, write-up, invoicing.

Write it as arithmetic:

• ‍D - the technician's loaded daily cost, not their hourly rate‍
• K - average round trip in kilometres, times your all-in per-km rate‍
• C - coordination: intake, scheduling, write-up, invoicing‍
• O - the displaced day: what that technician would otherwise have earned‍
• r - the share of trips that turn into a second trip

A technician's day at 400, a round trip at 110, coordination at 60, a displaced day at 600, and one repeat trip in five:

One widely quoted industry estimate puts a single field-service dispatch anywhere from about 150 to about 1 000 dollars - a sevenfold spread that is itself the argument for building your own number instead of borrowing one, however it was arrived at.

The good news: most of that cost is avoidable

The good old rule of problem solving advises us to divide and conquer. So let's split last year's trips into three piles: needed hands (H - a part was actually broken), needed eyes (E - a setting, a restart, a diagnosis that could have been made from a desk), needed neither (N - it was already fine). The second and third piles are the entire business case.

‍

A fourth pile is worth keeping: trips you cannot classify at all from what was written down (U) - blind rate. It is the ratio of unclassified trips to all trips. It tells you in how many trips you don't know what happened or what the solution was. We should minimize this metric as much as possible.

On a 300-unit fleet with 180 trips split 60 / 63 / 21, plus 36 unclassified, avoidable spend is 117 600 a year - money spent driving to faults that did not need a driver - and blind rate is 36/180 = 20%: one trip in five where you cannot say what happened, which is exactly what you will be asked to produce when a customer disputes a claim.

The bad news: it's harder than you think

Each rung is built on the one below it - you cannot diagnose a device you cannot see, or push a fix to a fleet you cannot inventory.

Climbing is not free. If you want to build it yourself, here are a couple of things you need to consider:

• security - both data and operations - what happens if someone takes over your device? Or your data leaks? Or a library you used has a vulnerability
• connectivity - what to do when the device connection dies?
• OTA updates - how do you want to fix your firmware? How will you deploy your change? How do you revert a bad change?
• observability - how do you want to know if your server is doing well? What if the database dies?
• scalability - one server will work for 1 000 devices, but what if the fleet you manage is 14 000?
• device side - an identity per unit, firmware that reports its own state, maybe even a small hardware module will be needed
• work management - how will you track who is working on what?

 Building, and after that managing, all of the above while running your actual business will be a headache. Fortunately there're many existing solutions which may help you with that - from open source platforms like ThingsBoard or Mender for OTA updates, through fleet-first products like OpenThings (the platform we develop), balena or Memfault, up to the hyperscalers with AWS IoT Device Management and Azure IoT Hub.

It's all about the balance

Regardless of whether you build it yourself or use something existing, you need to know when the right time is. In our experience it's when three things are true at once.

1. ‍The financial case is real. Avoidable spend clearly exceeds what climbing costs.‍
2. The fleet is large enough to carry it. The one-off engineering cost is roughly the same whether you have forty devices or four hundred, so it is amortised across whatever you have. On a small fleet the ratio inverts: the same months of firmware work sit against a much smaller pile of avoidable trips, and the case gets thin.‍
3. You know your own numbers, not an industry average. Your V, your split of hands / eyes / neither / unclassified, your avoidable spend, your blind rate - built from your own trips.

Get all three right and the decision stops being a matter of taste. It is arithmetic which you can defend to whoever signs it off.

Three ways forward

Once the balance holds, there are three ways to actually get there.

Build it yourself, with your own team.

• For: total control over the model, and the deepest possible fit with your own firmware and hardware roadmap.
• Against: you are hiring for a skill set - embedded security, device PKI, fleet software - that is scarce and slow to hire, and every year of maintenance afterwards is yours too.

Hire someone to build it for you

• For: faster than hiring in-house, and somebody else absorbs the risk of getting the first working version out.
• Against: the knowledge of how it works leaves with them when the contract ends, and you are back to hiring - or renewing - to keep it alive.

Use an existing platform

• For: the fastest route to a working pilot, the security and update burden carried by someone whose whole job is that burden, and a cost you can see before you commit.
• Against: less freedom to bend it to something unusual in your fleet, and a dependency on somebody else's roadmap - so check, before you sign, whether you can leave with your data if you need to.

None of the three is automatically right. Which one fits depends on how unusual your fleet is, how much of this you want to own forever, and how fast you need the case above to turn from arithmetic into something running.

Summary

Wherever you stand right now - service is not on your radar yet, you are starting to feel the cost of it, you are working out how to tie it all together, or you already have something running - focus on three simple steps which will help you with your situation:

Measure. Build your V. Tag each customer visit with what was needed: hands / eyes / neither / unclassified. Count how many devices are deployed. Review periodically.

Analyse. See trends, compare costs. Only then move to the next step.

Decide, now, because you have a number you trust, not a feeling or intuition.

Sometimes it's not worth the effort, other times it's the only way.

If you would rather not build everything from scratch: OpenThings, the platform we develop, exists because we kept meeting companies in exactly this position. Get in touch if you would like a hand mapping your fleet onto the ladder above.