Meeting room availability display: how status works · Lobby

You walk up to a room with a laptop under your arm and thirty seconds before a call. There is a small screen by the door. It is green. You go in, sit down, and start talking. Two minutes later someone knocks, points at their phone, and says they booked it. The screen was still green because the person who booked it did so ninety seconds ago and the display had not caught up yet. Now two groups are standing in a doorway negotiating over a room that a piece of glass told both of them was free.

That little screen is a meeting room availability display, and the whole reason it exists is to answer one question from across a corridor: can I use this room right now? When it works, it saves the walk-up guessing and the passive-aggressive sticky notes. When it lies, it does more damage than no screen at all, because people trust it. This post is about how that green-or-red status actually gets computed, the specific ways it goes wrong, and what makes one readable from five metres instead of one.

What "available" and "in use" actually mean

A meeting room status display is not sensing the room. There is no motion detector deciding whether bodies are present (some products add that, but the base case does not). The display is reading a calendar and translating events into a colour. "Available" means the room's calendar has no event overlapping the current minute. "In use" means it does. That is the entire logic, and it is worth saying plainly because it explains almost every failure mode later: the display tells you what the calendar believes, not what is happening in the room.

In Google Workspace and Microsoft 365, a meeting room is a resource with its own calendar, the same way a person has one. When you invite the room to a meeting and it accepts, an event lands on that calendar. A conference room availability display subscribes to that calendar and renders the next few hours of it. Free means no current event. Booked means a current event. Most displays also show the obvious extras: the room name, who holds the current booking, and what is coming next so you know whether "free" means free for ten minutes or free for the afternoon.

How the display reads the calendar

The display authenticates to your calendar provider, usually through OAuth or a service account with read access to the room resource, and pulls events on a schedule. It asks a narrow question: give me events for this room between now and, say, end of day. The provider returns a list with start times, end times, organiser, and title. The display sorts them, finds the one overlapping the current time (if any), and paints the screen.

Two details matter here. First, the display polls; it is not usually told the instant something changes. It asks again every so often. Some systems use push notifications so the provider pokes the display when a calendar changes, which shortens the gap, but many run on a fixed interval. Second, the display renders in the room's time zone, which sounds trivial until a recurring meeting was created in a different one and daylight saving shifts it by an hour twice a year.

The polling interval is the single number that governs how honest the screen is. A conference room status display that refreshes every 60 seconds can be wrong for up to a minute. One that refreshes every 15 minutes can be wrong for a quarter of an hour, which is long enough for a whole stand-up to happen in a room the screen swears is booked. When you evaluate any display, the refresh cadence is the spec that actually decides the user experience, more than resolution or bezel.

Why status goes wrong (and the fixes)

Here are the edge cases that make "available" lie, in rough order of how often they bite.

The lag between the calendar and the glass

Someone books the room from their phone as they walk toward it. The calendar updates immediately. The display updates on its next poll. If those two events are thirty seconds apart, the screen is briefly wrong and a walk-up sees green on a room that is now taken. There is no clean fix for the physics of polling; the mitigation is a short interval and, ideally, push notifications so the gap is seconds rather than minutes. Accept that any interval-based display has a small window where it is stale, and tell people the display is a strong hint, not a lock on the door.

The 7am cancellation that never frees the room

A recurring meeting is on the calendar for 9am. At 7am the organiser cancels just today's instance, or simply does not show up, but the event still sits on the room's calendar. The display reads the calendar, sees an event, and shows the room as booked all morning while it stands empty. This is the most common complaint about these systems, and it is not the display's fault: the calendar says booked, so the display says booked. The fixes live in the booking layer, not the screen. Options include on-display "release" or check-in buttons that free the room if nobody confirms within a few minutes, and auto-release policies in Google or Microsoft that cancel un-confirmed room holds. We wrote more about this failure in the linked piece on rooms showing free when they are not, and its mirror image applies here too.

Recurring holds and phantom bookings

Someone books a room "every Tuesday for the quarter" to be safe, then uses it twice. For the other eleven Tuesdays the display shows red on an empty room, and everyone learns to ignore the screen, which defeats the point. The technical fix is check-in and auto-release. The cultural fix is discouraging defensive recurring holds. Both are needed; the screen alone cannot solve a booking-behaviour problem.

Permissions and the blank or wrong screen

If the account the display uses loses read access to the room resource, or an admin changes how resources are delegated, the display may show nothing, show stale data, or fail to update while looking perfectly normal. This is the quiet failure: the screen is confidently displaying yesterday. When a display disagrees with reality for more than one meeting, check the calendar connection and the resource permissions before you blame the hardware.

Private events hiding the details

A room can be genuinely booked while the organiser has marked the event private, so the display can read that the slot is busy but not who has it or what it is. That is correct behaviour, not a bug, but it surprises people who expect a name and see "Busy." Decide up front whether your displays should show titles and organisers at all; some teams prefer to show only free or busy for privacy reasons.

Making it readable across the room

A status display only works if someone can read it without walking up to it. The job is glanceability at four or five metres, in a corridor with variable light, for someone moving.

Colour and contrast do the heavy lifting. Green for free and red for busy is the convention for a reason: it reads before the words do. If your display is monochrome e-ink, lean on a large clear state word ("FREE" / "BUSY") and a bold layout, since you cannot rely on colour. Do not make people parse a timetable to learn the one thing they came for.
State first, detail second. The single most important pixel is the current status. Room name and next meeting are supporting information. If someone has to read three lines to work out whether they can walk in, the hierarchy is wrong.
Size the type for the distance. A good rule of thumb is roughly a centimetre of letter height for every three metres of viewing distance for comfortable reading. Test it by standing where an actual person would stand, not by admiring it up close.
Mount at eye level beside the door, on the latch side. Put it where a hand reaches for the handle, around 1.4 to 1.5 metres up, so the answer is next to the door it describes. A screen around the corner or above head height gets ignored.
Mind glare and power. Glossy screens wash out under corridor downlights; e-ink stays readable in bright light but refreshes slowly. A powered LCD or tablet is bright and instant but needs a cable and a nearby outlet, which constrains where you can put it.

Availability vs schedule vs booking

These three get conflated, and keeping them separate helps you buy the right thing. Availability is the at-a-glance now: free or booked, this minute, outside the door. That is what this whole post is about. A schedule display shows the day's agenda for the room, the list of who has it when, which is useful but answers a different question and needs more reading. Booking is the action of claiming the room, whether from the display itself, from Outlook or Google Calendar, or from a room-finder tool.

Plenty of displays do all three, and there is nothing wrong with that. But the availability layer is the one that has to be instant and glanceable, because it is consumed by someone in motion who has already decided they need a room. The schedule and booking layers are consumed by someone standing still who is willing to read and tap. If a product makes you tap twice to learn whether a room is free, it has optimised for the wrong user.

Where Lobby fits

This is the part where the product shows up, because a meeting room availability display is exactly what Lobby is. It syncs to your Google Calendar or Microsoft 365 room calendar and shows the room name, whether it is free or booked right now, who holds it, and what is next. You get three surfaces from the same calendar: a physical e-ink display (open-source TRMNL hardware, battery up to about 12 months, and you own the device), a virtual display that is just a browser tab on a spare tablet or TV, and an overview screen for a floor. Setup runs under ten minutes and there is no new booking app to learn; people keep booking the way they already do.

Be clear-eyed about the trade-offs, because they are the ones described above. The e-ink display refreshes on an interval, so it is not instant to the second; that is the cost of a screen that runs for months on a battery and stays readable in bright light. The virtual display is instant and bright but needs a powered screen that is always on. Lobby cannot fix a 7am ghost booking that nobody released, because no display can read minds; it can show status faithfully and support the check-in and release habits that keep the calendar honest. It is free for up to three displays and a flat fee for unlimited after that, so the buy decision is mostly about how many doors you have and whether you want e-ink, virtual, or both.

TL;DR

A meeting room availability display reads a room's calendar and paints free or booked; it does not sense the room.
It polls the calendar on an interval, so there is always a small window where the glass is stale. Refresh cadence matters more than resolution.
Most "available is lying" cases are calendar problems, not display problems: last-minute cancellations that never release the room, defensive recurring holds, and broken resource permissions.
Fix those in the booking layer with check-in and auto-release, plus a culture that discourages phantom holds.
For glanceability, put status first, use colour or a large state word, size type for the distance, and mount at eye level by the door handle.
Availability, schedule, and booking are three different jobs. The availability layer has to be instant and readable in motion.

Meeting room availability display (the green light that lies less often)