How to Release a Meeting Room Automatically · Lobby

Almost every meeting room horror story starts the same way. Someone booked the room. Nobody turned up. The room sat empty for an hour while three other people walked past, saw "Booked" on the display, and went looking for somewhere else. By the time the original organiser remembered they cancelled the meeting yesterday, the day was over.

The fix everyone reaches for first is "make the room release itself if no one shows up". Reasonable instinct. The problem is that what people imagine "auto-release" does, and what the two big calendar platforms actually offer, are not the same thing.

This post walks through what Microsoft 365 and Google Workspace can really do on their own, where the gap is, and how to close it without a six-figure procurement project.

What "auto-release" should mean

If you ask an office manager what auto-release means, the answer is usually some version of:

A meeting is booked.
Five or ten minutes after the start time, the room checks whether anyone is there.
If not, the room marks itself free, sends the organiser a polite note, and goes back into the available pool.

That is a perfectly reasonable mental model. It is also not what Microsoft 365 or Google Workspace do out of the box. Both platforms can decline a meeting before it ever reaches the calendar (conflict, too long, outside booking window). Neither will cancel an accepted meeting based on whether anyone showed up, because the calendar itself does not know whether anyone showed up.

What Microsoft 365 actually does

The Microsoft 365 room mailbox is configured through calendar processing rules. The relevant settings live in Exchange Online PowerShell as part of Set-CalendarProcessing. The ones people most often confuse for auto-release are:

AutomateProcessing. Set to AutoAccept on most rooms. This means the room will auto-respond to invites. It does not mean it will release after the fact.
AllowConflicts. When false, the room declines anything that overlaps with another booking. Useful for hygiene, not for ghost meetings.
BookingWindowInDays and MaximumDurationInMinutes. Decline-on-arrival policies. The room will say no to a 14-hour booking three months out, but if you book a normal one-hour slot for tomorrow and never turn up, the room is yours for that hour.

What M365 does not do natively: detect that the meeting did not happen. There is no "release if nobody checks in" toggle anywhere in Exchange.

The half-step Microsoft does offer is the Outlook desktop reminder a few minutes before a meeting starts, which prompts the organiser to either join or end. If they hit "end early", the room is freed. In practice almost nobody does this, because the prompt is small and easy to dismiss.

What Google Workspace actually does

Google Calendar has the same gap. The resource calendar will accept or decline based on availability, capacity and the booking window. It does not track whether the meeting happens.

Google does have one feature worth mentioning. In Workspace Enterprise plans with Google Meet hardware in the room, the "Release unused Calendar meeting rooms" admin setting will free a room if no one joins the in-room Meet device within a configurable grace period. That is the closest to true auto-release any major calendar vendor ships natively. It only works for rooms with a Google Meet hardware kit, which is a USD 1,000 to USD 3,000 per room investment, and it does not help for in-person-only meetings.

For the other 99 percent of rooms, you need something on top of Google Workspace.

The bit that actually works: check-in plus display

The pattern that works across every office size, every calendar platform, and every budget is the same.

A display outside the room that shows the booking status pulled from Google Calendar or M365.
A check-in action at the display (tap, badge, or QR), required within a short window after the meeting starts.
An auto-release rule: if no check-in happens by X minutes past the start, the booking is cancelled, the calendar entry is removed, and the organiser is told.

The reason this works and pure-calendar approaches do not is simple. The calendar does not know what is happening in the physical room. A display platform sitting between the calendar and the door does. That platform can write a cancellation back to M365 or Google Calendar when the check-in window expires, and the room becomes available everywhere else (Outlook, Google Calendar mobile, the next person walking past the door).

This is the pattern Lobby uses, and it is also what Joan, Robin and Envoy do at the high end. It is not unique to any one vendor. The shape of the solution is the same.

The four-step rollout

If you want to get auto-release working without a major project, here is the sequence that works for offices under 150 people.

Step one: clean up the room mailbox or resource calendar. Set sensible decline policies (no recurring meetings beyond 90 days, max meeting length 8 hours, no conflict overrides). The M365 Room Mailboxes checklist covers this for Microsoft tenants. The Google Workspace Room Resources checklist is the Google equivalent.
Step two: pick a check-in mechanism. Most teams pick a tap-on-display approach because the display is already there. If you do not have a display yet, you can use a QR sticker on the door that opens a check-in page on a phone. Lobby supports both.
Step three: set the grace period. Ten minutes is the most common choice for under-30-minute meetings. Fifteen for longer ones. Below five minutes is too aggressive and people complain. Above twenty and the rooms stay blocked too long. Start at ten and adjust.
Step four: communicate the rule, once, clearly. One short email, one Slack pin, then leave it. The display does the rest. Within a week or two it becomes normal behaviour and nobody thinks about it.

What changes for the office, week by week

In our experience watching teams roll this out, the curve looks like this.

Week 1. Three or four no-shows release automatically. One person sends a confused note about a meeting that "got cancelled by itself". You explain the rule. They get it.
Weeks 2 to 4. Check-in becomes habitual. People start cancelling proactively because the cost of forgetting is now visible.
Month 2. Real utilization rises by 8 to 15 percent. The "is the room actually free" question stops coming up. The booking-to-occupancy ratio (covered in our utilization benchmarks post) tightens by 0.1 to 0.2.

The behavioural change is the bigger deal than the technology. The technology is the lever that makes the change cheap.

A few things to skip

If you are going down this road, save yourself some time and avoid these dead ends.

Building it in PowerShell or Apps Script. Yes you can write a script that scans calendars and cancels meetings missing a check-in. It will work for two weeks and then break when someone has a sick day, the script throttles, or the API quota trips. Use a tool with an SLA.
Sensors as the only check. Motion sensors are great as a supplement. They are not a primary signal. A person walking past or a delivery happens often enough that sensor-only auto-release ends up confusing.
Aggressive grace windows. Five minutes feels productive. It is also enough to release the room of someone who is two minutes late getting coffee. Ten minutes is the friendly default.

TL;DR

Neither Microsoft 365 nor Google Workspace can truly release a room automatically based on whether anyone shows up. The calendar does not know what is happening in the room. The reliable pattern is a display outside the room, a quick check-in, and a rule that releases the booking if no check-in arrives within ten minutes. Set the room mailbox decline policies cleanly first, then add the display layer on top. The full rollout takes a week.

How to Release a Meeting Room Automatically (in M365, Google Calendar, and the Bit That Actually Works)