Appearance
Meeting Room
Booking, plus the thing booking systems never know: whether anyone is actually in the room.
That pairing is the whole point. A calendar can tell you a room is booked from two until three. Only a sensor can tell you nobody turned up — and a room that is booked solid and empty half the time is the most expensive kind of room there is.
Who it is for
| Anyone booking a room | The booking screen, or their own Google / Microsoft calendar |
| Whoever owns the rooms | The dashboard, the trends, and the settings |
| A screen outside the door | The kiosk view |
Before it is useful
A zone for each room. The app works on zones, so a meeting room that is not drawn on a floor plan is not a bookable room. Draw it, then tick it in the app's settings.
A capacity on that zone. Set on the zone, not in the app — there is deliberately one place for it, so a room cannot end up with two capacities. Nothing stops you booking a nine-person meeting into a six-person room; the app tells you it is over, and you decide.
Something that counts people in the room, if you want any of the presence-aware behaviour. A radar counts everyone. BLE tags count only people carrying one, which is enough for auto check-in if your staff wear badges and useless for spotting an unbooked meeting of visitors. Which number is which matters here more than anywhere.
A calendar connection, only if people book in Google or Microsoft rather than in Omaya.
Setting it up
There are two settings screens, and it is worth knowing which is which.
Your Apps → Meeting Room, on the admin side, is where the behaviours are switched. Everything below is on by default; switch off what you do not want:
| Setting | What it does |
|---|---|
| Ghost release | Frees a booking nobody showed up for, after a number of minutes you set (ten by default) |
| Auto-release on no-show | A booking that reaches its end time with nobody ever checked in — by hand, at the kiosk or by presence — is marked a no-show, so Trends counts it even in a room with no sensor |
| Auto check-in / check-out | Checks a booking in when a tagged attendee arrives, and out a few minutes (five by default) after the last one leaves |
| Kiosk | The door-panel view |
| Attendee emails | Sends a confirmation when a booking is made |
| Default attendee capacity | What the "expected attendees" box is pre-filled with on a new booking |
| Environmental data on bookings | The live people / temperature / humidity / CO₂ card on a booking's page, where sensors are bound to the room |
| Trends | The usage history tab |
| Create bookings from the calendar | A synced calendar event becomes an Omaya booking |
| Cancel bookings when the event is deleted | And the reverse |
Inside the app, a user with the configure permission has an admin tab with two things: which zones are rooms — tick them, and say per room whether unbooked use should be recorded — and the calendar connection.
What people actually do with it
Booking a room
The booking screen shows the rooms, when they are free, and — if you have sensors — whether they are occupied right now, which is not the same question. A room with a calibrated radar shows a live mini-map of where people are in it. Attendees are picked from a directory that spans your app users, your administrators and any free-form external addresses you type in, so inviting the caterer does not require creating an account for them.
A booking's page shows the room's latest temperature, humidity and people count alongside it, from the sensors in that zone.
If attendee emails are on, everyone gets a confirmation. That send is best-effort by design: a mis-configured SMTP connector will not stop a booking being made, it just means nobody was emailed. If confirmations stop arriving, the connector is where to look, not the booking.
Ghost meetings
A booking starts, and nobody comes. Every five minutes the app looks at each booking that has been running for longer than the threshold without being checked in, asks whether anyone is in the room, and hands the slot back if not.
"Anyone in the room" is asked of the best evidence available, in order: a radar; a presence sensor; a people counter that has reported in the last ten minutes; and last, tags seen in the room in the last five. Nothing older counts, so a room that was busy an hour ago and is empty now reads as empty, which is what you want.
A room the app cannot see is never released. If there is no sensor and no tag has ever been seen in that room, "no tag here" proves nothing, and the booking stands. Ghost release only works where it has something to go on.
Set the threshold to something longer than your worst-case lateness. Ten minutes is about right for an office; a site where people walk five minutes between buildings should be more generous. The failure mode of too short is worse than too long, because it releases a room somebody is on their way to.
Auto check-in and check-out
If your people carry tags and those tags are linked to their app user accounts, the app checks a meeting in when the first attendee's tag is in the room, and out a few minutes after the last one's has gone. It runs every minute.
This needs the whole chain in place: an app user with a linked entity, and that entity with a tag — see people and assets. Without it the feature is silent rather than broken — which is the commonest "it isn't working" report on this app, and it is a setup gap.
Ad-hoc meetings
People use rooms without booking them. When a people counter in the room says it is occupied and no booking matches, the app records it as in use (ad-hoc) rather than pretending the room is free, and closes the record when the count drops to zero. It is per room — the tick on the zones tab — and it is worked out every minute in the background (and again whenever the dashboard is opened), so it is current whether or not anyone is watching.
Two things follow. The dashboard stops lying about availability, and your usage figures start including the meetings nobody wrote down — usually a large share of them, and always the ones that surprise people.
The kiosk
A panel view for a screen outside the door, at the room's own address, with no login: what is in the room now, what is next, and whether it is free.
Trends
How much each room is used, and how much of that was booked versus walked into; no-show rates and the peak hour. Rolled up hourly, so it lags by up to an hour. This is the tab to open before anyone argues about needing more rooms — the answer is often that the rooms are fine and the booking behaviour is not.
Calendars
Omaya reads Google Calendar and Microsoft 365, and normalises Microsoft into the same shape, so the rest of the app does not care which you use.
Three things worth knowing:
The OAuth app is per organisation. You register your own app with Google or Microsoft and enter its client details on the calendar tab. Nothing is shared with other organisations on the same platform.
The connection is one calendar account, and rooms are matched by name. Every five minutes the app reads that account's events for the last week and the next month and matches each event's title and location against your room names — the longest match wins, so "Main Meeting Room" beats "Meeting". A matching event becomes an Omaya booking; an event that clashes with an existing booking is left for a person to resolve; a deleted event cancels its booking. Name your rooms the way people write them in invitations.
It is one-way. Calendar events become bookings; a booking made in Omaya is not written back to the calendar.
Where the app shows up elsewhere
- Reports → Meeting Room — the usage report, in the normal reporting UI alongside every other report.
- Rules — room occupancy metrics are ordinary rule metrics, so "tell me when a booked room has been empty for ten minutes" is a rule you can write yourself rather than a feature you wait for.
- Space Utilisation — meeting rooms are zones, so they appear in the portfolio view with everything else.
- Visitor Management — an external attendee on a booking is pre-registered as a guest for the meeting's time, hosted by whoever booked, and gets the QR by email; cancelling the booking cancels the visit. On by default once both apps are enabled; the switch is on the Visitor settings page.
- Facility — a room's people counter that has been silent for four hours raises a work order on its own, once, so a dead sensor is a job rather than a month of rooms that read empty.
When it disappoints
Every room reads zero. Nothing counts people in it. A room with gateways but no radar counts tags, and in an office where nobody wears one that is honestly zero all day.
Ghost release never fires. Either the room has no presence source and no tag has ever been seen in it — so the app declines to guess — or the threshold is longer than the meetings.
Auto check-in never fires. The app user is not linked to an entity, or the entity has no tag.
The usage numbers look too low. Ad-hoc detection needs a people counter and the per-room tick. Without them the app only knows about meetings somebody booked.
Calendar bookings land in the wrong room, or none. The event's title or location does not contain a room's name, or contains two. Rename the room or the invitation.