Installed Base Management Software: 2026 Guide

Installed base management software tracks every unit you have sold that is still in service: its configuration, location, service history, contract status and documentation. Four kinds of vendor compete for this search: field service management, asset management and CMMS, quality suites, and device-level service layers. They solve different problems, and most manufacturers end up running two.

Buyers routinely lose a few months working out which of the four they were actually looking at.

This guide is written so it is useful even if you end up choosing a competitor.

What installed base management actually covers

Your installed base is every unit you have sold or placed that is still in service. Installed base management is the practice of knowing, per unit:

• What it is: model, serial, revision, build configuration, options fitted
• Where it is: site, department, operator, country
• What state it is in: warranty, service contract, maintenance due, open issues
• What has happened to it: every case, part, upgrade and inspection
• What applies to it: the documentation, bulletins and regulatory records for that configuration

The test of whether you have it is one question. Pick a serial number from two years ago. How long does it take to answer all five?

If the answer needs several systems and a colleague's memory, that is the gap this category of software exists to close. A field safety corrective action is where the gap gets expensive, because it does not give you time to assemble the answer by hand.

The four kinds of vendor that answer this search

Most real setups end up with two of these four. The mistake is buying one and expecting it to be all of them. We compared three of the device-level layers directly in remberg vs ClearOps vs sqanit.

Seven questions to ask in a first call

1. What is the atomic object in your data model: the product, the customer, or the unit?

Ask it exactly like this. The answer predicts most of what follows. A product-centric tool can tell you about a model. A customer-centric one can tell you about an account. Only a unit-centric one can tell you that serial 44192, at that clinic, running firmware 3.2, had this done to it in March.

When we join an evaluation, the question that sorts a shortlist fastest is which object the system is actually built around. Half the vendors in this category answer with the customer or the product, and that is fine. It only means they are solving a different problem than the one in the room.

Julian Sotek, Founders Associate

2. How does a unit get into the system, and how does it stay current?

Initial import is the easy half. Ask what happens when a device is moved, resold, upgraded, or returned from loan. If the answer is that someone updates a field, your data will be wrong within a year. Look for the update to be a by-product of work people already do.

3. Who is expected to use it at the point of use, and what do they have to install?

If the answer involves an app download or an account, ask for the observed adoption rate at a comparable customer, not the licensed seat count. Adoption is where these projects quietly fail. Every step between a problem and an answer removes a share of the people who would have used it.

4. Which systems does it read from and write to, and in which direction?

Your ERP holds the commercial truth, your CRM holds the account and your FSM holds the dispatch. Ask specifically which of them is the master for which field, and what happens on a conflict. A vendor who has not thought about this will say "we integrate with everything", which means nothing. More on this in how an installed base layer sits next to Salesforce, Zendesk and an ERP.

5. What can you produce for a field safety corrective action, and how fast?

Make it concrete. "A notice affects units built between two dates with option B fitted. Show me the list, with current locations and contacts." How a vendor handles that is worth more than the whole feature list.

6. What does the regulatory record look like at unit level?

For EU manufacturers this now connects directly to EUDAMED and UDI obligations, which we covered in what manufacturers must do before November 2026. Ask whether service events are documented against the UDI, and whether that export exists today or is on a roadmap.

7. What is the deployment path, and what does month three look like?

Ask for the realistic time to first value, and what has to be true on your side for it. Six to twelve weeks is achievable for a device-level layer when the installed base data exists. When it does not, the data work is the project and no vendor can shorten it much.

The honest constraint nobody sells

Every tool in every one of the four categories depends on the same input: knowing what you have and where it is.

If that information does not exist in a usable form today, the first phase of any of these projects is building it. Reconciling shipment records against service history against what the sales team remembers. It is not exciting and it is not something software does for you.

The good news is that it only has to be done once, if the system you pick keeps itself current afterwards. The bad news is that a tool that requires manual updating to stay accurate will put you back where you started in two years.

That is why the second question in the list matters more than it looks.

What good looks like after a year

Three signs, from deployments that worked:

Cases arrive identified. The service desk no longer starts by establishing what the caller has. One US medtech distributor measured a 27% reduction in total service cost and a halving of resolution time.

Time to close drops sharply. A German laser systems manufacturer went from three to four hours per ticket to 41 minutes, with ticket creation at 78 seconds.

Regulatory questions turn into lookups. "Which units, where, in what configuration" is answered in the room rather than in a week.

A short checklist to take into evaluations

• The vendor's data model has the unit as its primary object
• Records stay current as a by-product of work, not through manual updates
• Point-of-use access requires no app and no login
• Integration direction is defined per field, with a named master system
• A field safety corrective action query can be demonstrated live
• Service events are documented against the UDI or equivalent identifier
• Realistic time to first value stated, with the data prerequisites named
• Model or usage costs, if any, disclosed before contract

Bring us your hardest serial number question and we will answer it in the demo. Book a slot.