Alex Birch
Co-Founder & CEO, XY Sense
The most common question I get from customers now isn’t about accuracy or coverage. It’s some version of: we have this rich, real-time occupancy data, what else can we do with it?
The answer that comes up most often is building control. Use the data to drive HVAC, ventilation and lighting rather than just report on how the space was used. It’s an obvious next step, and it’s where the conversation usually stalls, because connecting a cloud API into a building is a proposition many enterprise IT and OT teams won’t entertain.
That question is why I now spend my weeks with three groups of people who look at exactly the same building through completely different lenses.
For workplace teams, occupancy data is about understanding how people use the office. They want to improve daily workplace experience, redesign spaces for hybrid work, balance departmental space allocations, optimize portfolios and make better long-term investment decisions.
Building engineers are different. They want to know whether HVAC can respond to live demand instead of a calendar or how quickly occupancy data can reach a lighting system. They want to know what happens if internet connectivity is interrupted and whether the building continues operating as expected.
IT and security teams have their own concerns again. What can the sensor identify? Where is data processed? What leaves the building? How is it secured? What happens during an outage?
A few years ago, those conversations rarely overlapped. But, lately they have and I think that’s one of the most interesting changes happening in our industry.
For most of the last decade we’ve largely thought about occupancy as a reporting tool. The goal was visibility. Continuous sensing replaced manual utilization studies, workplace teams got evidence instead of assumptions to plan against, and integrating the data with booking and other workplace tools made the day to day experience better too.
That shift has been enormously valuable for both companies and their employees. But despite all the progress we’ve made measuring space performance and closing the loop on human behavioural-led design, most buildings still operate remarkably similarly to the way they did ten years ago:
- HVAC follows schedules.
- Cleaning isn’t triggered by actual use.
- Lights still require you wave your arms around after 5:30pm.
It’s because the two halves of the problem grew up in different industries.
Building engineers have been designing sensors to control buildings for decades, and they’re very good at what they were built for: detect presence, switch a light, trigger a damper, all on a protocol the BMS already speaks. What they were never designed to do is produce the accuracy, granularity or historical depth that workplace analytics needs. A PIR sensor can tell you a room is occupied when somebody moves. It can’t tell you that it was occupied by four people for twenty minutes.
Occupancy analytics platforms grew up solving the opposite problem and made the opposite trade. Rich data, cloud-scale processing, and no native way to speak to a building.
Two categories, each excellent at its own job, and almost no overlap between them.
Meanwhile, somewhere else in the technology stack sits a platform with incredibly rich occupancy data describing exactly what’s happening inside the building.
I think it’s about time we connected the dots and started treating occupancy data as a true operational signal, as infrastructure. This changes what we should expect from the technology underneath it.
Occupancy data started as a reporting tool, and if that’s all it ever needed to be, the technical bar is low. Latency is irrelevant when the output is a dashboard, and a thirty minute network outage impacting your sensors is inconvenient rather than operationally significant.
But that just isn’t where the use cases stopped.
First it was reporting. Then wayfinding and live displays, where a person is standing in a lobby looking at a screen that has to be right at that moment. Then cleaning triggered by actual use rather than a schedule. Then workplace applications wanted the data live: desk and room booking, no-show release, sensors telling the booking system a room is actually empty.
Every one of those steps raised the bar on the hardware underneath., because the tolerance for stale or approximate data kept dropping as the use case matured. What was acceptable for a quarterly report is useless for a display someone is looking at right now. That’s the progression that brought us (XY Sense) to two-second, ~99% accurate, mains-powered sensing. Each generation of use case demanded it.
Building automation is the next step in that same progression, and it raises the bar again. Now accuracy and latency become an operational requirement, and network and power resilience become critical (sorry, battery sensors). The workload has changed. And when the workload changes, the architecture usually needs to change with it.
Which brings me to why I’m writing this blog. It’s 2026 and I’m still spending a not insignificant amount of time discussing the merits of cloud versus on-premise deployments. I genuinely thought (aka hoped) we’d be past this by now.
Almost every month I find myself explaining why enterprise occupancy platforms still rely on cloud infrastructure (do you know how many servers you’d need to run to manage the millions of anonymous data points, an advanced sensing system like XY Sense generates in a single building), or why building engineers continue asking for local processing. Those conversations made perfect sense ten years ago….Today, they feel like they’re missing the point.
The question worth asking is what workload you’re trying to solve…
Cloud fundamentally changed what was possible for workplace technology.
It gave us effectively unlimited processing, portfolio-wide analytics, innovative features, integrations that make booking and finding spaces, continuous firmware updates, remote device management and the ability to maintain an accurate digital representation of buildings as they inevitably evolve. We capture over 400 billion anonymous data points every year, in real time, every two seconds. We can replay any moment in a building’s history. That kind of scale doesn’t happen on-premise.
Also, buildings aren’t static. Teams move, meeting rooms are reconfigured, furniture changes and floor plans evolve. Without the cloud continuously managing that digital model, even the best occupancy deployment gradually becomes less valuable over time.
It’s worth being clear about what the objection to cloud usually isn’t. Our sensors are anonymous by design, including during calibration and setup. No images leave the sensor and nothing we process can identify a person. In practice that means the data lands at a low classification level in almost every enterprise we work with, which removes most of the usual security objections to cloud hosting.
The reason building engineers still ask for local processing isn’t privacy. It’s resilience and it’s protocol. Which is a different problem entirely.
Building systems are designed around deterministic performance, operational resilience and local decision making. They need to communicate using protocols like BACnet that existing building management systems already understand. They need to continue operating when external connectivity is interrupted because buildings don’t simply stop functioning when the internet goes down.
Accurate occupancy data on its own doesn’t get you there. If you want a building to respond to it, that data needs to arrive in a language the building already understands. In most enterprise buildings that language is BACnet.
Neither architecture is better, they’re just optimised for different workloads.
That’s why I think the cloud versus on-prem debate has become too simplistic. Deciding where workloads should run is only half the battle. The harder part is making sure the output of those workloads can actually be consumed by the systems you’re trying to influence.
Buildings don’t consume occupancy dashboards, they consume protocols.
I often compare it to how modern electric vehicles are designed. Nobody questions whether navigation belongs in the cloud. Maps improve continuously, traffic data is shared globally and vehicles benefit from learning across millions of journeys. Equally, nobody expects steering, braking or battery management to depend on an internet connection. Those systems are safety-critical, so they have to keep working regardless of what’s happening outside the vehicle.
The interesting thing is that nobody describes this as a cloud versus on-board computing debate on cars anymore. It’s simply good systems architecture.
…Office buildings are heading in exactly the same direction.
As occupancy becomes operational infrastructure rather than simply workplace reporting, we’ll increasingly expect buildings to make critical decisions locally while continuously improving through cloud-scale intelligence. Each layer does the job it was designed to do.
That’s why I believe the future for IoT and occupancy sensing platforms is an architecture that puts the right workload in the right place. It also changes how we think about the role of occupancy data itself.
For years we’ve judged occupancy platforms by the coverage of the sensor, the visual quality of their dashboards, the number of integrations they enable and their ease of install. Those capabilities remain incredibly important, but they’re increasingly becoming table stakes.
The next generation of value comes from helping a building actually respond to what’s happening right now, rather than explaining how it was used last week. It sounds like a small distinction, but it changes who inside the organization cares about the system and what they need from it.
If you’re using occupancy to design a new floor or inform a lease renewal every five years, you’ve already realized much of the available value. If you’re using occupancy to continuously optimize HVAC, lighting, cleaning, workplace experiences and building operations every single day, you’re solving a completely different problem. One creates periodic strategic value and the other creates operational value every hour the building is occupied.
That’s why I don’t believe the conversation should be centred around cloud versus on-premise anymore. It should be about what organizations are actually trying to achieve.
-
-
- If the objective is portfolio analytics, cloud-native architectures make enormous sense.
- If the objective is resilient building automation, local processing becomes equally important.
-
These days, enterprise customers I talk to aren’t interested in choosing. They’re asking for and expecting both. Five years from now, I suspect we’ll no longer debate the distinction. Just as we expect electric vehicles to use cloud and on-board computing where each makes sense, buildings and occupancy platforms will simply use the right architecture for the right job.
That shift has shaped a lot of our own thinking at XY Sense over the last twelve months. It’s pushed us to think differently about where workloads belong, how enterprise buildings should integrate with operational technology and what role our sensors will play over the next decade.
The result is a product update we’ll be sharing publicly in September.
In the meantime, if this write-up has resonated with you, or you’re wrestling with similar questions about your own buildings, feel free to reach out. I’m always interested in comparing notes, and if you’re curious about what we’ve been building, I’m happy to give you an early preview.
