Small multi-site commercial buildings cannot be managed site by site

Small hotel, restaurant, coffee shop, residence, agency, service business… on paper, these sites seem simple to operate. But as soon as you go from managing 1 site to managing a portfolio of 20, 50, or < 100 commercial sites, the nature of the challenge completely changes.

The real problem is no longer the size of the building, it's that each site ends up developing its own operating logic. A changed setting, extended hours, an exception kept "out of habit," a setting left on manual "because it works better that way." Taken separately, these choices are often understandable. But at the portfolio level, they end up producing the opposite of what we're looking for: less consistency, less visibility, more wasted time, and a technical service that reacts more than it proactively manages.

In small multi-site commercial properties, the issue is therefore not just about energy. It's also operational.

Usage patterns more dynamic than one might think

A small site is not a "simple" site in the sense that its operation would be linear.

A building doesn't operate at the same pace all day long

Let's take a hotel. The need for heating or air conditioning is not the same at 6 AM, during cleaning, at check-in time, then in the evening when some rooms are occupied and others are not. In a restaurant, it's the same: the building doesn't operate the same way before service, during peak hours, or during off-peak hours.

And yet, many settings continue to be conceived as if the site always followed the same scenario.

Small local adjustments eventually lead to deviation

So, on-site, people adapt. They extend hours "just in case." They raise a setpoint because there was a complaint. They don't shut it down completely because "otherwise it takes too long to get back up."

It's human nature. It's often even done with common sense.

But technically, this results in a system that no longer truly follows the site's actual usage. And when this type of adjustment is repeated across several sites, the portfolio starts to drift without anyone truly having control over this deviation.

When each site addresses its issues independently, the portfolio loses its consistency

The second issue is fragmentation, a portfolio doesn't go out of control all at once.

In most cases, there isn't one big, visible problem everywhere. Instead, it's a sum of small, local decisions:

• here, a time slot was changed;
• there, an old schedule was kept;
• elsewhere, equipment was left in manual mode;
• at another site, a setting was adjusted without aligning the rest.

Taken one by one, these discrepancies seem minor.

But across 20 or 50 sites, you're no longer managing a standard. You're managing a collection of exceptions.

What really complicates the life of a technical department

is that everything becomes more cumbersome when each issue is managed locally, without an overall view. It's hard to compare sites, understand discrepancies, and deploy improvements in a scalable way — it's on a case-by-case basis, and it's cumbersome. In fact, all the efficiency of the technical department is lost in value-added projects that are difficult to replicate across a set of sites & buildings.

A high-performing portfolio is not one where everything is identical. That would be unrealistic.

It's a portfolio where differences are visible, acknowledged, and managed within a common framework.

Without centralized visibility, we treat symptoms more than causes

This is often where maintenance loses the most time; problems are discovered too late. When each site operates somewhat independently, problems often surface from the field:

• a room that's too cold,
• a room not reaching temperature
• a team complaining,
• a ticket piling up.

Two highly useful indicators, even if you're not an expert

There are two simple concepts that greatly help in better understanding a portfolio and the effectiveness of associated services:

MTTR: How long does it really take to react?

The MTTR refers to the average time between an incident's occurrence and its effective resolution.

In other words: an alarm goes off on Friday at 3:42 PM. When is the problem actually addressed? If the answer is "Monday morning," then the site potentially operated in degraded mode all weekend.

And that's often where hidden additional costs, discomfort, and customer review complaints lie.

MTBF: Are we really fixing the problem?

The MTBF measures the average time of normal operation between two failures.

It's a very concrete way to answer a simple question:

have we resolved the issue, or does it regularly reappear in another form?

For example, if several sites report comfort complaints in comparable areas every month, these might not be three small, isolated incidents. It might be the same problem recurring without being recognized as a common pattern.

Beyond a certain number of sites, what needs to be industrialized is the management

The right approach is not to add more local logic

With 3 sites, many things can still be managed through on-site experience and local adjustments. At 15, it starts to strain the teams. At 50, it's no longer a method; it's a mental burden.

The challenge, therefore, is not to further reinforce isolated approaches at each site.

The challenge is to maintain an on-site connector, as close as possible to the equipment and the actual site, while centralizing the control intelligence in a decentralized BMS, capable of managing the entire portfolio with a consistent logic.

Specifically, this allows for:

• retaining local specificities without losing the overall perspective;
• harmonizing operating rules;
• comparing site behaviors;
• detecting deviations faster;
• correcting at scale instead of starting over site by site.

In other words, we don't remove flexibility from operations. We simply prevent this flexibility from turning into fragmentation.

Regaining control without burdening operations

In small multi-site commercial buildings, the real challenge isn't operating a small building. It's operating an entire portfolio when each site operates according to its own logic.

That's why a purely local approach eventually shows its limitations.

The right answer isn't more complexity. It's a clearer architecture: an on-site connector, common supervision, consistent rules, and the ability to manage the portfolio as a whole.

Because ultimately, a portfolio doesn't become difficult to manage because its sites are small. It becomes difficult when their management is fragmented.

‍