How to Reduce Medtech Service Costs by 27%

How to Reduce Medtech Service Costs by 27%

How to Reduce Medtech Service Costs by 27%

A major US medtech distributor cut its total service costs by 27%. Processing effort per case dropped by half. Customer satisfaction moved up between five and ten points. Those three numbers come from the same deployment, measured on that company's own service data.

The percentage matters less than where that cost sat before it moved.

Service cost in medtech is mostly travel

Ask a service director where the money goes and the answer is rarely parts. It is the trip. A single on-site visit in the medical field runs somewhere between 1,000 and 1,500 euros once you count the technician's day, the vehicle, and the work that did not happen elsewhere. That is a field figure our own team uses in customer conversations, and it sits close to the published industry benchmarks for medical service calls.

So the question is how many of those visits were avoidable in the first place.

In most fleets, a meaningful share of visits are triggered by three things that have nothing to do with a broken device:

  • The caller could not describe which device they had, so a technician went to find out.
  • The fault was a setting, a consumable, or a step in the manual.
  • Nobody knew the device had already been serviced for the same issue six weeks earlier.

What they have in common is a missing piece of information, and the way the process handles missing information is to send a technician.

Almost everyone who comes to us has already counted their service costs. What they have usually not counted is how many trips happened only because nobody could say which device was on the phone. We ask for that number in the first workshop, and most teams have to go away and measure it first.

Sebastian Eberhardt, Director Business Development

What changed at the device

The distributor runs its device service on sqanit. The mechanism is the same in every sqanit deployment: a code on the device that opens on any phone, with no app, tied to that specific unit.

Whoever is standing at the device scans it and lands on that unit. Not a product page or a support portal, but the exact machine in front of them, with its configuration, its history, and the instructions that apply to that revision.

Three things follow from that. The deployment measured their combined effect on cost rather than splitting it between them.

The ticket arrives identified. When a case is opened by scanning, the serial, the model, the location, and the service history are already attached. The service desk no longer has to start by establishing what the caller actually has.

Some cases get resolved before they become a ticket at all. The person at the device finds the answer where the device is. In one device maker's deployment of emergency stretchers, 93% of users scanned the code when they hit a problem. That figure comes from a different deployment than the 27%, and it measures adoption rather than cost, but it answers the question people ask first about this approach: whether anyone actually scans.

Repeat diagnosis drops. History lives with the device rather than in a technician's notebook. The second person to touch that unit sees what the first one did.

A second deployment, measured the same way

A German laser systems manufacturer published its own numbers with us. A ticket that used to take three to four hours now closes in 41 minutes, creating it takes 78 seconds, and case handling overall runs about four times faster.

Those are the laser manufacturer's numbers on its own data, not the distributor's. We keep them apart on purpose. Any vendor who merges results from two deployments under one headline is selling you a model and calling it evidence.

What the two have in common is the starting condition. Both had devices in the field they could not address individually. Both fixed that first and got the operational numbers second.

What this does not fix

It does not reduce the cost of a genuine hardware failure. A pump that fails still needs a technician, a part, and a trip.

It does not work on devices you cannot identify. If your installed base lives in a spreadsheet that was last reconciled two years ago, the first phase of any such project is finding out what you have and where. That is unglamorous and it is the real work. Budget for it.

And it does not work without adoption. Any saving of this kind depends on people at the point of use actually scanning. That is why the code has to open in a browser with no login and no app install. Every step between the problem and the answer costs you a share of the people who would have solved it themselves.

Estimating your own number

Do not take 27% and apply it to your budget. Take your own three inputs:

  1. Your annual service cost. Technician time, travel, the service desk, warranty work.
  2. The share of that which is on-site. In most medtech fleets it is the largest single line.
  3. Your avoidable visit rate. If you have never measured it, ask your dispatchers to flag, for four weeks, every visit that turned out to need no part. The number usually surprises people.

Multiply the third by the second and you have the realistic ceiling for what device-level visibility can reach. It will not be 27% for everyone.

If you want the comparison against the other tools in this space, we wrote that up separately in our comparison of remberg, ClearOps and sqanit.

Where compliance comes in

One side effect matters more than it used to. Every case is filed against the specific device it concerns.

Neither EUDAMED nor the FDA's QMSR prescribes this exact record. What it does is make post-market questions faster to answer: which units are affected, where they are, and what has been done to them. For the regulatory side, see what manufacturers must do before November 2026.

Want to know what your own avoidable visit rate is worth? Talk to us.

FAQs

Frequently asked questions.

01.

What does the 27% actually measure?

Total service cost reduction at a major US medtech distributor, measured on that company's own service data. It covers service operations cost, not resolution speed. Resolution time at the same customer halved, which is a separate figure.

02.

Why are the customers not named?

Because we do not name customers in blog posts. You get the number with an honest description of the deployment instead of a logo attached to it.

03.

How long does a rollout take?

Typically six to twelve weeks to live, depending mostly on how well your installed base data is organised before you start. The software is rarely the bottleneck.

04.

Do technicians need to install an app?

No, the code opens in the phone's browser, and that is deliberate. Adoption drops sharply with every install step, and adoption is what the cost saving depends on.

05.

Does this replace our field service management system?

No. It sits in front of it. The device layer identifies the asset and captures the case, then hands it to whatever system already dispatches your technicians.