Occupancy data has moved from being a reporting output to being a live input to building systems. When occupancy drives HVAC sequencing, ventilation rates, lighting and space release, it stops behaving like an analytics product and starts behaving like infrastructure. That changes the requirements: accuracy, latency and availability become operational constraints rather than nice-to-haves.
Most enterprise occupancy deployments were bought as analytics. The business case was portfolio optimization: measure how space is used, right-size the footprint, save on lease costs. That case was sound and it paid off.
But something has changed in what buyers are asking for, and the change is structural rather than incremental.
The question being asked now is whether the building can act on the data as it changes, rather than what the floor plate looked like last quarter.
The four stages of occupancy maturity
Across mature enterprise deployments, the same progression shows up. Each stage generates more return than the last, and each demands more of the underlying data.
Stage one: reporting
Utilization dashboards inform lease renewals, footprint decisions and workplace strategy. People read the data periodically and use it to support decisions rather than to make them. Accuracy only has to hold up on average: a reading that is wrong on Tuesday washes out across a quarter.
Stage two: workplace integrations
Occupancy feeds space planning tools, IWMS platforms and booking systems. Neighborhood planning uses real utilization, desk allocation reflects actual attendance, and the data starts driving workflow rather than informing it. Errors now surface as a wrong recommendation inside a system somebody acts on.
Stage three: displays and wayfinding
Live availability appears on floor displays and in employee apps.
This is the step where latency becomes visible to the people using the building, and it is unforgiving. A display showing a room as free when somebody is sitting in it does not read as a data quality issue. It reads as a broken system, and once a workforce stops believing the screens they stop looking at them.
Stage four: building automation
Occupancy drives HVAC and ventilation sequencing. Lighting responds to rooms going empty rather than to a timer. Booked rooms nobody turned up to release themselves automatically.
Every requirement tightens at once here. The data becomes an input to plant control, so it has to be right at the moment of reading, arrive in seconds, and stay available whether or not anything upstream is working.
Most enterprise deployments today sit at stage one or two. The returns concentrate at stage four.
What changes when data becomes infrastructure
The word infrastructure is doing real work here, and it is not a marketing flourish. It describes a specific change in requirements.
Accuracy stops being an average. Analytics tolerates error because error averages out across a reporting period. Control does not. A ventilation sequence acts on one value at one moment. If that value is wrong, the response is wrong for as long as the error lasts.
Latency becomes a design constraint. A dashboard refreshing every fifteen minutes is fine. A control loop inheriting a fifteen-minute lag is not a control loop. This is the requirement that most cleanly separates sensing technologies, because update interval is a hardware decision made years before anyone thinks about integration.
Availability becomes an operational requirement. When a dashboard is unavailable, someone looks at it later. When a control input is unavailable, the building falls back to a fixed schedule, which is exactly the behavior occupancy-driven control was bought to replace.
Delivery format becomes non-negotiable. Analytics is consumed through a dashboard or an API. Infrastructure is consumed through building protocols: BACnet/IP for the BMS, UDMI for a smart building platform. A REST API is not a substitute, because the BMS cannot call one.
Security review changes character. An analytics platform is reviewed as a SaaS application. A system feeding building control is reviewed as operational technology, by a different team, against different standards. IEC 62443 and IEEE 802.1x enter the conversation. So does the question of whether automation-critical data has to leave the building to be usable.
The gap this exposes
Here is the structural problem, stated plainly.
Occupancy platforms were built cloud-first, because they were built to be analytics products. That was the right architecture for the job.
Building management systems were built on-premise, protocol-based and deterministic, because they were built to control plant. Also the right architecture for that job.
Neither was designed to meet the other. The result is a category of enterprise deployment where the sensing is excellent, the analytics are excellent, and the last mile to automation simply is not there. The customer has bought the data and cannot act on it.
This is not a small population. It includes some of the largest and most sophisticated occupancy deployments in the market, where the sensor investment was sound and the return is still capped by an architectural boundary nobody specified around.
What to ask when specifying
If you are specifying occupancy technology for a building where the data may eventually drive automation, and it will, the questions are different from the ones that get asked in an analytics evaluation.
— What is the update interval at the sensor, in seconds? Not the dashboard refresh rate. The sensor.
— What is the accuracy at the space level, and how was it measured?
— Which building protocols are native? BACnet/IP and UDMI from an on-premise occupancy gateway, or an API that needs a middleware layer.
— What happens to the building integration during an internet outage?
— What does the security posture look like against IEC 62443 and IEEE 802.1x?
— Is the on-premise component a managed appliance or a server you maintain?
— How many vendors and contracts sit between the sensor and the BMS?
That last question is worth more attention than it usually gets. Sensor vendor, integration platform, systems integrator and BMS contractor is four support boundaries for one data path. When occupancy stops updating in the BMS, the diagnostic conversation crosses all four.
Frequently asked questions
What is occupancy intelligence?
The combination of sensing hardware, data processing and delivery that turns physical presence in a building into information systems can use. It covers utilization analytics for workplace teams and live occupancy signals for building automation. The second use case has stricter requirements than the first.
How is occupancy data used in building automation?
As a direct input to control sequences. Occupancy status, headcount and percent occupied are published to the building management system as readable points, usually over BACnet/IP. Control sequences then use those values to modulate ventilation, adjust setpoints, manage lighting and release unused bookings.
What accuracy do occupancy sensors need for building control?
Materially higher than for reporting. A utilization report averages error out over weeks. A control sequence acts on a single reading. Accuracy at the space level in the high nineties, with update intervals in seconds rather than minutes, is the practical threshold.
Can existing occupancy sensors be used for building automation?
Sometimes, and it depends on two things: whether the sensor updates fast enough, and whether the platform can deliver into building protocols. Battery-powered sensors with multi-minute reporting intervals generally cannot support real-time control regardless of what sits above them. Platforms that only expose a cloud API need a middleware layer to reach the BMS.
Why does occupancy data need to reach the BMS rather than an API?
Because a building management system cannot call a REST API. It reads BACnet objects on its local network. Occupancy data that only exists in a cloud platform is data the building cannot act on, no matter how accurate it is.
