Sell the benchmark only to the clients who supplied the data

IT services companies are under pressure to become data businesses. Analysts value recurring data revenue more highly than consulting hours, and every managed services provider holds years of operational data from running its clients' systems. My position is that products built from that data should be sold only to the clients who contribute to them, under disclosure rules as strict as those of a statistical office, and never to the software vendors, analysts or investors who would pay most for them. I hold it having given up about €6 million a year to apply it.

Whose data is an incident count?

At Lumivara the data in question is mostly not personal. It is the record of running other organisations' IT: how often their systems fail, how long security patches take to apply, what each workload costs to run in the cloud and how many tickets their staff raise. Across hundreds of comparable organisations in the Nordic and Baltic countries, it forms a picture nobody else can see, and our commercial team was right that it would sell.

Because so little of it identifies a person, data protection law says relatively little about it, and our contracts allowed us to use anonymised operational statistics to improve our services. Our chief commercial officer argued, fairly, that an aggregated index broke no rule. I agreed that it probably did not. My objection was about whose interests the product would serve. A bank's incident rate, a municipality's patch delays and a manufacturer's cloud costs are facts their owners would not choose to publish. A software vendor buying a benchmark of patch delays among Nordic municipalities is buying an account of its customers' weaknesses, which it will use in negotiations with them. The clients who generated that data paid us to run their systems, not to brief their suppliers.

I find it useful to ask whether the contract's authors would recognise the use. The clause on anonymised statistics was written so that we could improve capacity planning and tell clients how they compared with their peers. Nobody drafting it imagined a vendor intelligence product. When a use is lawful but would surprise the people whose activity produced the data, I think a provider should treat the surprise as the governing fact.

Rules that make a small country hard to benchmark

The benchmark launched in March 2024 on rules I borrowed from my first employer, a research institute that published statistics from linked administrative registers. Every published figure must rest on at least eight contributors. No single contributor may account for more than a quarter of any figure, so that a large client's numbers cannot be deduced by subtracting the rest. Only contributors may buy the product, and the smallest receive it free. A contributor that leaves has its data removed from the next quarterly release.

These rules are not novel. Official statisticians have used minimum cell sizes and dominance rules for decades, for precisely this reason: an aggregate can reveal an individual when the group is small or lopsided. What surprised me was how rarely commercial data products apply them. Many benchmarks I have seen publish figures for segments with three or four members, and anyone who knows the market can work out who they are.

The rules have costs, and I would rather describe them than pretend otherwise. At launch they suppressed 41% of our figures for Norway and Denmark, where we have fewer clients than in Finland and Sweden. Contributors there complained, reasonably, that they were paying for tables with holes in them. We responded by building Nordic regional comparisons, which are less precise for a Norwegian utility than a Norwegian comparison would be, but which it can actually see. I should have designed for this from the start. A disclosure rule that works in a large country can make a small one invisible, and Nordic markets are mostly small.

There is a further cost in the products we cannot build at all. A benchmark of cloud costs for hospital laboratory systems would be useful, but we run too few of them for any figure to pass the rules, so it does not exist. I accept that. A product that cannot be made safely is not a gap in the portfolio.

The revenue we did not take

Excluding vendors and investors cost us the larger part of the market our commercial team had sized. Their estimate of vendor and investor sales was about €6 million a year, and I have no reason to think it was inflated. The contributor-only product earned €8.4 million in 2025 from 212 clients, with 93% renewing. That is a reasonable business. It is not the business the original plan described.

What we gained is harder to put in a revenue line. Two clients told us the benchmark influenced their decisions to renew managed services contracts worth €31 million in total. Several have begun contributing data we did not previously receive, because they trust the rules governing its use. And when a public-sector client asks, during a tender, what Lumivara does with its operational data, we can answer in one paragraph.

The objection I hear most often is that this is a luxury only a profitable company can afford, and that a services firm under margin pressure should take the vendor revenue. I see the attraction. But a services company's most valuable asset is its clients' willingness to let it into their systems. Selling insight about those systems to their suppliers spends that asset to earn a modest data line, and in a small market the clients will find out.

My advice to a board considering a data product built from client operations is to ask three questions. Would the clients whose activity produced this data recognise the product from their contracts? Who is the buyer, and what will they do with what they learn about our clients? And what are the disclosure rules, written down, that stop a figure from identifying one organisation? If management has crisp answers to all three, the product is probably worth building. If the second answer names a client's suppliers, I would build something else.