Tomas LaurentChief Product Officer · Essays & perspective
← All essays

Pricing for landlords5 min read

Per-sensor pricing punishes the landlords who measure most

Building software is often priced per connected data point or as a share of the energy it is said to save. Both models charge landlords for the behaviour the product ought to encourage. Pricing by floor area is less elegant and more honest.

Pricing is usually treated as a commercial question, settled by finance and sales after the product has been designed. In building software I think it is one of the most important product decisions a company makes, because the price determines how much of the building a customer is willing to connect, and the software is only as good as what it can see.

Our industry uses three common models. Some vendors charge for each connected data point: a meter channel, a sensor, a valve position, an alarm. Some take a share of the energy savings their software is said to produce. And some charge by the size of the building, usually per square metre of lettable or gross floor area. At Lindevaart we used the first model until 2023 and now use the third. I want to explain why, because the arguments for the first two are respectable and the third has faults I do not hide.

What per-point pricing teaches a customer

The case for charging by data point is that it follows cost. Each point must be mapped, stored, checked for quality and analysed, and a building with ten thousand points does cost more to serve than one with five hundred. Early customers found it intuitive, and it let us start small in a building and grow from there.

The trouble is what it teaches. When we examined our own usage in 2022, the median office on our platform exposed about 3,000 points from its controllers and meters, and our customers were connecting about 900. They were being rational. Every sub-meter, room sensor and valve position they added raised the bill, so their finance teams asked them to connect the minimum. The points they left out were precisely the ones our fault detection needed: the valve that never closes, the room heated and cooled at the same time, the tenant's sub-meter that runs all night. We were charging customers for letting the product do its job.

Per-point pricing also made bills unpredictable. An installer who added a dozen sensors during a refurbishment changed the invoice, and the landlord's accounts-payable team, which had never heard of us, would query it. In tenders, procurement teams could not compare our price with anyone else's without first estimating the number of points, and they usually estimated low.

Why shared savings invite an argument

The second model has an obvious appeal. If the software saves energy, let the vendor take a share of the savings, so that the customer pays only for results. Several of our competitors offer it, and landlords' investment committees like the sound of it.

I have watched these arrangements in practice, and most of the effort goes into an argument about the baseline. Savings are measured against what the building would have consumed without the software, which nobody can observe. Weather has to be corrected for, occupancy changes, tenants arrive and leave, and the landlord replaces a heat pump in the same year. Each correction becomes a negotiation, and the vendor has a reason to prefer the corrections that enlarge its share. The customer, sensing that, begins to treat the vendor as a counterparty rather than a partner.

There is a deeper problem. Shared savings reward the vendor for reductions it can attribute to itself, and the reductions that matter most in a multi-let building, a tenant changing its hours or a landlord insulating a roof, are hard to attribute to anyone's software. A vendor paid on savings has little reason to help with them, and some reason to argue that they would have happened anyway.

Floor area, with its faults admitted

We moved to pricing by lettable floor area, with a rate per square metre that depends on the type of building and the modules a customer uses, and a minimum fee for each building. A full office subscription costs about €2.80 per square metre a year; a logistics building on the basic module costs about €0.70. The price no longer changes when points are added, and within eighteen months connected points per building had more than doubled. Fault detection is now active in 71 per cent of the buildings on our platform, against 38 per cent before the change.

The model has faults, and I would rather list them than have a customer find them. It does not follow our costs closely: a heavily instrumented laboratory building costs us far more to serve than a warehouse of the same size, and we absorb the difference. It removed about €2.3 million of annual recurring revenue from customers who had connected many points and paid less afterwards, a reduction our chief financial officer argued against with good reason. And the minimum fee priced out about sixty small logistics buildings whose owners wanted little more than a monthly meter reading; we lost them before we built a lighter product for that market.

The transition needed care of its own. We moved customers at renewal rather than all at once, and before each renewal we sent the landlord a comparison of what its portfolio would have cost under both models over the previous year. Most customers paid somewhat more per building and connected far more of it; forty-one paid less. Publishing the rate card also removed a habit our sales team valued, the freedom to negotiate each deal from a blank page, and two senior account managers left within the year partly because of it.

I still think it is the right model, for one reason. It ties what the customer pays to something the customer already understands and controls, the size of its portfolio, and it removes any reason to hide part of the building from the software. A landlord can budget for it, a procurement team can compare it, and a sustainability manager can connect every meter without asking anyone's permission. Net revenue retention, the measure investors watch most closely in our business, has risen since the change rather than fallen, because customers add buildings and modules they would previously have rationed.

For anyone buying building software, I would ask a vendor one question before discussing the number: will this pricing ever make me want to connect less of my building? If the honest answer is yes, the vendor has priced its product against its own purpose, and the landlord will pay for that in the faults nobody finds.