Microsoft Just Made Your Meeting Room a Data Source. Is Your AV Ready?

Your client’s IT manager calls. They want to know whether the ten meeting rooms you installed last year can support Microsoft Places auto-release. The feature drops a booked room when nobody shows up, freeing it for someone else — exactly what their real estate team has been asking for. You look at the system you commissioned. Camera. Display. Audio. Control panel. The room works perfectly. It just cannot tell Microsoft whether anyone is in it.

That call is happening across enterprises in Germany, the UK, and the Nordics right now. On 1 April 2026, Microsoft shifted Places to a per-space licensing model. Auto-release and the advanced occupancy analytics in Places now both require a Teams Shared Space licence attached to each room. 

That licence only delivers its value — the utilisation reports, the automated room release, the space optimisation data the FM team wants — when the room produces a real presence signal. Booking records alone gives you a baseline. They do not tell you how many people were in the room, whether anyone showed up, or how long the space was genuinely occupied.

Most enterprise AV deployments were not designed with that in mind. The gap between what the room does and what the platform now needs is a conversation integrators must start having at design stage, before hardware is selected and certainly before a client commits to Places space licences and then discovers the rooms cannot support them.

Microsoft Places is an AI-powered workplace coordination platform embedded in Teams and Outlook. The April 2026 licensing update made core features like Places Finder, Places Explorer, and room booking available to most standard M365 licences without any add-ons. The advanced layer, the one that makes Places commercially compelling to real estate and facilities management teams, still sits behind a space licence: auto-release policies for rooms and desks, and the occupancy and utilisation analytics that tell you how space is actually being used.

Here is the detail that changes the AV design conversation. Basic analytics in Places can run on Exchange booking data alone — it will tell you which rooms are being booked and when. But auto-release requires a presence signal from the room, so if nobody is detected after a defined period, the booking drops. Richer utilisation analytics, including actual headcount, real occupancy versus booked capacity, and usage patterns that support or challenge the room portfolio, require sensor telemetry to be fed into the Microsoft Graph workplace sensor API. Without that telemetry, the licence is active and the room is managed, but the data remains limited.

Microsoft Places ingests sensor data via Graph. Device types include dedicated IoT occupancy sensors, Microsoft Teams Rooms hardware with people-counting enabled, and third-party devices registered via the workplace sensor device API. Wi-Fi-based check-in is also on the public roadmap. In each case, the data has to be configured, the device has to be registered in Entra, and the telemetry has to flow on a consistent cadence. None of that happens automatically from a standard room install. It requires deliberate design work that most current AV specifications have not included.

A room designed in 2022 or 2023 was almost certainly specified around the meeting experience: camera framing quality, audio pickup, sharing simplicity, display performance. Occupancy telemetry was not a line item because nobody was paying for a Places space licence that depended on it. The camera may have person detection built in for auto-framing, but that signal stays inside the codec. It does not feed Graph. The control processor may know the room is active because a source is running, but active source is not presence, and presence is not headcount.

The integration gap sits at the API layer. For auto-release and sensor-based analytics to work, the room’s presence or occupancy device must be registered in Entra, the correct Microsoft Graph permissions must be configured, and telemetry must push to the workplace sensor endpoint. That is not complicated engineering, but it is deliberate engineering. It does not emerge from a standard Teams Rooms deployment. 

AVIXA Xchange’s review of key AV industry shifts in 2025 flagged occupancy detection and presence-based system activation as rising design requirements. The Places licensing change converts that from a design aspiration into more of a functional dependency for enterprises running M365 at scale.

The installed base problem is real. Large enterprises in Germany, the UK, and the Nordics have rolled out hundreds of meeting rooms on Teams Rooms or comparable platforms over the past three years. Many of those rooms can book, display, and communicate. But not all can report. The integrators who delivered them are going to receive calls asking whether the rooms can support Places analytics. - In many cases, the answer will be that additional work is required.

Cisco is a prominent example of how the AV and building intelligence worlds are converging to address this problem. The Cisco Smart Spaces Stack — front-and-centre at ISE 2026 in Barcelona and Cisco Live Amsterdam in February 2026 — integrates Wi-Fi, 7 access points, managed switches, collaboration devices, and the Cisco Spaces software platform to turn Cisco network and room infrastructure into an occupancy sensor layer. For a Cisco-heavy enterprise, the collab device in the room contributes presence and headcount data via Spaces without a separate sensor purchase. The architecture is coherent, but it requires the room to have been specified with Cisco hardware and the Spaces software stack active. Again, deliberate design.

For non-Cisco environments, dedicated IoT sensors from vendors such as Verkada, Density, and Butlr can provide presence and headcount data via API integrations into Microsoft Places or Cisco Spaces. Room panels from Neat, Logitech, and Poly carry varying degrees of built-in occupancy detection, but data export capabilities differ significantly by platform and firmware version. The integrator’s job is to know which pieces talk to which platforms, specify the right device, configure the integration, and scope all of that before the project starts — not discover the gaps during commissioning when the client is already paying for space licences.

Every enterprise AV design for an M365 environment now needs a data layer question answered before hardware is selected: what sensor data does this room need to produce, which platform will consume it, and how does the telemetry get there? AVIXA’s guidance on smart space design makes the dependency clear: actionable occupancy analytics require sensor infrastructure to be designed in from the start. Retro-fitting a sensor layer into a fully installed and commissioned room is typically expensive, disruptive, and very difficult to price as a change order without a contract dispute.

At discovery, that means four questions, asked before a spec goes out: 

• Is the client running Microsoft Places, and do they have, or plan to have, space licences active on meeting rooms? 

• If yes, which features do they need — basic booking analytics, auto-release, or true occupancy headcount? 

• Does the proposed AV hardware export presence or occupancy data via an API, and to what destination? 

• And if the AV hardware cannot supply the data, what dedicated sensor is going into the room, how is it powered, and who owns the integration after handover?

These are not technically demanding questions. They are easy to skip when the brief says “install a Teams Room” and the client has not yet connected that brief to their Places rollout. The integrator who raises the data layer question early protects the project. The one who does not will be back on site after handover doing integration work that was never in the scope and is impossible to invoice cleanly.

The commercial argument for getting this right is not just defensive. When room sensor data flows cleanly into Places analytics, the AV system becomes part of the evidence base the client’s real estate team uses to justify its office portfolio. A room that produces reliable utilisation data is demonstrably more valuable than one that does not. AVIXA’s webinar  on leveraging meeting space data analytics makes this point directly: utilisation data is increasingly the metric that determines whether a room gets kept, reconfigured, or cut in the next lease cycle.

Room data is not a one-time deliverable. Presence sensors need monitoring. Graph integrations need maintenance when Microsoft updates the Places API. Analytics configurations need adjusting when the client reorganises floors or changes hybrid policy. The sensor layer that auto-release depends on represents an ongoing operational commitment, not a commissioning checkbox.

Integrators who frame this correctly can build a managed service around room data health: sensor uptime monitoring, telemetry continuity checks, quarterly analytics reviews, and integration maintenance when Places or Cisco Spaces pushes a platform change. The workplace intelligence article on AVIXA Xchange notes that fragmentation across workplace platforms creates exactly the ongoing integration complexity that benefits from a single accountable party. That party should be the integrator, not the client’s FM team trying to manage a Microsoft Graph API relationship alongside everything else.

The pricing conversation is easier than it sounds once the client understands the dependency. A space licence that runs without reliable sensor data produces analytics the real estate team cannot act on and an auto-release feature that never fires. Paying a managed service fee to keep the data layer clean and continuous is a straightforward cost-benefit.. It is also a recurring revenue stream attached to every room in the estate.

The Microsoft Places licensing change on 1 April 2026 is not a software story. It is an AV infrastructure story. Auto-release needs a presence signal. Meaningful occupancy analytics need headcount data. Both require sensor telemetry from the room, and most rooms installed in the last three years cannot produce it, because nobody asked the question at design stage.

Add the data layer question to every enterprise AV discovery call from this point forward. Ask which workplace intelligence platform is running, whether Places space licences are active or planned, and what occupancy data the room is expected to produce. If the AV hardware cannot supply it, design the sensor solution in now. Do not leave it as a note in the handover pack that IT will “follow up on later.” Later is when the licence is running and the analytics are empty.

The integrators who move on this will find managed services opportunities that did not exist two years ago and will be positioned as the party that shapes the brief rather than cleans up after it. The ones who keep speccing meeting rooms without asking the data question will keep getting called back to fix integrations that were never scoped. One of those is a business model. The other is overhead.