When building data and workplace data finally share a platform
Most commercial buildings run two data worlds that never meet. One lives in the building management system: temperature, ventilation, energy, setpoints. The other lives in workplace tools: room bookings, presence sensors, occupancy events. Facilities teams work from the first. Workplace teams work from the second. Neither sees the other’s picture, so both end up guessing at things the combined data could simply show.
Bringing OT and IT data into one platform does not just add a data source. It lets you cross-reference questions that were previously unanswerable, because the two halves of the answer were sitting in separate systems.
This is the layer ProptechOS is built to provide: a single platform, built on the open RealEstateCore data model, that connects building systems and workplace tools instead of leaving them in separate systems.
Two data streams, one building
Building systems generate a steady, house-wide picture: room temperature every 30 to 35 minutes, ventilation flow and pressure at the plant level, heating and cooling loads. This data is comprehensive but coarse — it tells you what the system is doing, not what people are experiencing.
Workplace data tells the opposite story. Presence sensors report occupancy in near real time, often room by room. Booking systems show intent. Together they capture how space is actually used, but on their own they say nothing about comfort or building performance.
Put the two together in a single platform, and each stream starts correcting the other’s blind spot.
What becomes possible once the data is joined
A real utilization picture. With a few months of presence history, patterns emerge that headcount reports never show: rooms that are booked constantly but rarely occupied, others that sit empty every Friday, floors that peak at 10am and empty out by 3. That picture is the starting point for any conversation about right-sizing space or getting people back into the office — not opinions about which floor “feels” busy, but a record of what actually happened.
Climate complaints weighted by who is actually in the room. A temperature complaint from a room booked three hours a week is not the same problem as one from a room that is full every day. Once occupancy and climate data sit in the same platform, facilities teams can prioritize by actual impact instead of by who complained loudest or first.
Comfort you can verify, not just measure. Buildings often have two independent readings for the same room: an occupancy sensor’s ambient reading, and the setpoint the building’s own control loop is working from. When those two disagree while the room is occupied, that is not a hypothesis — it is a specific, actionable finding you can hand to a maintenance provider instead of a vague “room 412 is too warm” ticket.
Demand patterns you can explain. Cross-referencing presence with calendar events, weather, and day of week starts to answer a harder question: not just which rooms are used, but why. That turns a utilization dashboard into something closer to a forecast.
From insight to action
The same combined data, running on ProptechOS, supports a further step: agents that reason over it and act directly, within defined limits, instead of waiting for a person to close the loop.
Everything above still ends the same way: a dashboard, a prioritized list, a ticket someone reviews and acts on. That’s real value, but it’s also where most building analytics stops — insight handed to a person, who still has to notice it, judge it, and act on it.
The same combined data supports a further step: agents that reason over it and act directly, within defined limits, instead of waiting for a person to close the loop.
- Ventilation that follows presence, not a schedule. Rather than a quarterly report showing which rooms sit empty on Fridays, an agent can read the same presence data continuously and adjust ventilation and setpoints as occupancy actually shifts through the day — closer to how the Eufemia fix worked, but running as a standing behavior instead of a one-time correction.
- Work orders that filter themselves. Instead of a prioritized list a facilities manager still has to work through, an agent can cross-reference the same occupancy and climate signals to decide whether a complaint reflects a real problem before it ever reaches a person — escalating only the cases the data actually supports, rather than every complaint that gets logged.
- Comfort logic that survives a bad sensor. The comfort-verification use case above assumes the presence sensor is working. When it isn’t, an agent can reason its way to a substitute — inferring occupancy from CO₂ trends or booking data instead — and keep the underlying logic running, rather than the whole use case going dark because one input dropped out.
None of this replaces the judgment calls that genuinely need a person. It changes which calls those are: fewer routine ones, more of the kind where context actually matters.
Where this depends on a decision, not just a data pipeline
Not everything here is purely technical. Some of the most valuable use cases — headcount instead of simple occupied/vacant status, for instance — depend on a governance choice about what the organization is comfortable measuring, not on whether the hardware can deliver it. The honest answer in many buildings is: the data exists, the decision to use it does not, yet. That is worth surfacing early, because it changes what “quick win” actually means for a given portfolio.
The same is true of scope. Ventilation systems, for example, are frequently shared across many floors rather than dedicated to one tenant or one zone. Any use case built on that data will necessarily operate at building level, not floor level — a constraint worth stating plainly rather than discovering later.
Start with the use case that already has data behind it
The pattern that works best is not “connect everything and see what happens.” It is picking one question the combined data can already answer — usage, comfort, maintenance prioritization — and proving it before adding the next source.
At KLP Eiendom’s Eufemia building in Oslo, this played out directly. The building’s ventilation system already had demand-controlled features built in — the kind that should scale air processing down when a floor is empty. They had quietly stopped working, and standard BMS dashboards never flagged it. Analytics on the building’s existing data caught what the dashboard couldn’t: the system was processing air at near-maximum rates through nights and weekends, when occupancy was at its lowest. Reactivating and recalibrating the existing controls — no new hardware — cut off-peak air processing by 31 percent and saved an estimated €60,000 a year.
The fix didn’t require a new sensor or a new integration. It required looking at data the building was already generating and asking one specific question: is this system doing what it’s supposed to do, right now. Every additional system a building adds — access control, elevators, solar shading — only pays off once there is a use case waiting for the data it produces, not before.
The building systems most operators already have, paired with the workplace data most tenants already generate, cover more ground than either team tends to assume. The step that unlocks it is not new hardware. It is putting both streams on the same platform and asking one specific, answerable question first.
Explore how ProptechOS agents work across building systems to see what a first use case could look like for your portfolio.
