LOBBY
Guides· 9 min read

Room Booking System Requirements: A One-Page Spec You Can Send to Vendors

Vendors send you a feature matrix. The document that actually works is the one you send them. Here is a one-page room booking system requirements spec, split into seven areas, with the specific questions that expose weak products. Including the ones Lobby answers badly.

Vendors send you a feature matrix. It is written to make their product look complete, every row has a tick in it, and it is the wrong document to be reading. The document that actually decides the purchase is the one you send them.

What follows is that document. Seven areas: calendar integration, display support, booking and release behaviour, admin and permissions, security and data residency, pricing model, and support. Each has a short list of mandatory requirements, a shorter list of nice-to-haves, and one question that separates the products that work from the ones that demo well.

Copy it, delete the lines that do not apply to you, send it. A vendor who answers all of it in writing within two working days is worth a demo. A vendor who insists on a discovery call before answering a single line has told you something useful too.

Two rules that make the spec work

Mark every line M or N before you send it. Mandatory means you will walk away if the answer is no. Nice-to-have means you will pay a little more for it but not much. If you send an undifferentiated list of forty requirements, you will get back forty ticks and learn nothing. If you send eleven M lines, you will find out in about a day which vendors are actually in the running.

Ask for written answers, not a demo. Demos are run by people who know exactly which screen to avoid. A written answer is something you can put in the contract, and a vendor who will not put an answer in writing has answered.

One more thing before the list. Be clear in your own head whether you are buying panels, software, or both. Those get quoted as one thing and invoiced as two, which is covered in the difference between a meeting room display and room booking software. Write the spec for the software. Hardware is a separate line and a separate decision.

1. Calendar integration

Mandatory

  • Native integration with our calendar platform, which is [Google Workspace / Microsoft 365 / Exchange Server on-premises]. State which, and state whether the others are supported by the same codebase or a different one.
  • Rooms are read from our existing room resources (Google Calendar resources, or Exchange room mailboxes). We will not maintain a separate room list inside your product.
  • Changes made in the calendar appear on the display within a stated number of seconds. Give us the number, not "in real time".
  • Recurring series are handled correctly, including a single cancelled occurrence inside an otherwise live series.
  • The permission scopes you request are documented by name. For Microsoft 365 that means the Microsoft Graph scope (for example Calendars.Read versus Calendars.ReadWrite) and whether it is delegated or application permission. For Google Workspace that means whether you use domain-wide delegation or per-resource sharing.

Nice to have

  • More than one tenant or domain under one admin account.
  • Exchange hybrid support without a connector server on our side.
  • Handling of tentative and delegate-approved rooms without a manual step.

The question

Does a booking made on the wall create a real event in our calendar, or a record in your database that you then try to keep in sync with ours?

This is the single highest-value question in the spec. A product that keeps its own booking table and syncs it to your calendar has two sources of truth, and two sources of truth drift. The failure mode is not an error message. It is a panel showing green outside a room with six people in it, because the sync job failed forty minutes ago and nothing surfaced that. We wrote about that specific symptom in why meeting rooms show free when they are not.

Ask them to open Outlook or Google Calendar during the demo, on a screen you can see, and show you the event appearing. Then ask what the panel does when their service is unreachable.

2. Display support

Mandatory

  • A list of the exact hardware you support, by model name. Not "any tablet".
  • A statement on whether we can use hardware we already own, and which of our existing devices qualify.
  • Power and network requirements per device: PoE, USB-C, mains, battery. If battery, state the expected life and at what refresh rate.
  • Network requirements stated as outbound hostnames and ports, so our IT can review them before purchase, not after.
  • What the display shows when it loses connectivity, and how quickly that state is visible.

Nice to have

  • A single overview board showing every room, for a reception or lift lobby.
  • An e-ink option for rooms with no power near the door.
  • Custom templates and our own logo.

The question

Can we use hardware we already own, and if the answer is a tablet in kiosk mode, who manages the operating system updates?

Plenty of products will happily run on an iPad you already have. That is a genuine saving on day one and a genuine liability on day four hundred, because somebody has to keep those devices patched, enrolled and awake. Get the answer to "who owns MDM for these" before you buy, not after. The trade-offs between panel types are laid out in e-ink versus tablet versus TV, and the network side is in meeting room display network requirements.

The other half of this question is the reverse: if the vendor only supports their own panel, the licence and the hardware are locked together, and the exit cost is the hardware you already bought.

3. Booking and release behaviour

Mandatory

  • Book the room for the current or next slot from the display itself, or state plainly that you do not support this.
  • Extend a running meeting, and end it early, from the display.
  • Automatic release of no-shows after a configurable number of minutes, with a per-room override. Fifteen minutes is a common default and it is wrong for at least one room in every office.
  • Released time returns to the room calendar as genuinely free, immediately, and is bookable by anyone.
  • An audit record of every automated release: which event, when, and on what trigger.

Nice to have

  • Check-in by QR code as well as by tapping the panel.
  • Booking from Slack or Teams.
  • A "find me the nearest free room" action.

The question

When your system releases a no-show, what exactly happens to the event, and who does the email come from?

There are three possible behaviours and they are not equivalent. The event can be deleted, declined by the room, or shortened to the time already elapsed. Deletion removes the record from the organiser's calendar and generates a support ticket the first week you turn it on. Declining leaves the organiser holding a meeting with no room. Shortening is usually the least disruptive and is the least commonly implemented.

Then ask about the notification. If the release email arrives from a vendor domain nobody recognises, half your staff will report it as phishing. The mechanics are covered in how to release a meeting room automatically.

4. Admin and permissions

Mandatory

  • We can add, rename and remove a room ourselves, without raising a ticket with you.
  • At least three roles: full admin, room manager, read-only.
  • A stated answer on who can see meeting titles and organiser names on a panel, and a setting to hide both. Some rooms face a corridor that clients walk down.
  • Configuration is exportable in a machine-readable format.
  • Setup does not require a service account with more access than the panels need.

Nice to have

  • SAML SSO for the admin console.
  • SCIM user provisioning.
  • Per-site admin scoping for multiple offices.

The question

Which calendars do you write to, with what permission scope, and can we restrict that to a subset of rooms?

Ask to see the OAuth consent screen or the Azure app registration during the demo, before you consent to anything. The consent screen is the honest version of the integration documentation. If a product asks for read and write on every calendar in the tenant in order to run a display outside one meeting room, that is worth a conversation with your security lead. Our platform checklists are here for Microsoft 365 room mailboxes and Google Workspace room resources.

Note that admin console layouts on both platforms change, so verify the current setting names against vendor documentation rather than against a screenshot in a PDF from 2023.

5. Security and data residency

Mandatory

  • The region your production data sits in. A country or a region, not a cloud provider name. "AWS" is not an answer to "where".
  • A current subprocessor list, and how we are notified when it changes.
  • A data processing agreement we can sign, referencing GDPR Article 28 obligations.
  • Retention period for meeting metadata, and whether it is configurable.
  • What happens to our data if we cancel: deleted, exported, or retained, and within how many days.
  • Whether meeting titles or attendee names are cached on the physical device.
  • Encryption in transit, and your breach notification commitment in hours.

Nice to have

  • EU-only hosting with no transfer outside the EEA.
  • A summary of the most recent penetration test.
  • ISO 27001 or SOC 2 report, if your risk process requires one.

The question

What happens to our data if we cancel, and where is it hosted?

Room booking data looks harmless until you look at it properly. It is a record of who met whom, when, and often what about, for every employee in the building. Under GDPR that is personal data and you are the controller. The detail is in GDPR and meeting room booking data, and the device-level controls are in the sysadmin checklist for securing room displays.

6. Pricing model

Mandatory

  • The unit of pricing, stated as one of: per room, per user, per display, or flat.
  • The full list price in writing, including every tier, not a quote for our current size.
  • What happens when we add a room in month four: pro-rated, next renewal, or a new contract.
  • Minimum term, minimum room count, minimum seat count.
  • Renewal uplift, with a cap in the contract if there is one.
  • Hardware priced as a separate line, with a clear statement of whether we own it outright or lease it.
  • Whether there is a one-off onboarding, implementation or professional services fee, and whether it is optional.

Nice to have

  • Monthly billing without a large penalty against the annual rate.
  • A free tier, or an evaluation period that does not require a card.

The question

Is pricing per room, per user, per display or flat, and is there a professional services fee?

Ask for both in one written line, because they are frequently separated in the proposal so that the recurring number looks small. The unit matters more than the number: per user pricing on a room product means your bill tracks headcount, which has nothing to do with how many rooms you have. We have taken the models apart with worked arithmetic in room booking software pricing compared and looked specifically at the per-room default in meeting room display pricing per room.

If a vendor will not publish a price at all, that is not automatically disqualifying, but write it in your notes as "pricing gated" rather than guessing a number, and expect the first quote to be a function of your headcount rather than your room count.

7. Support

Mandatory

  • Support hours with a time zone attached.
  • A response target for a panel-down incident, distinct from the general target.
  • The support channel: email, portal, chat. And whether it is included or a paid tier.
  • A public status page with incident history.
  • Notice period before breaking changes to any API or integration we depend on.

Nice to have

  • Spare hardware held for advance replacement.
  • A named contact for a rollout of our size.

The question

Is any part of the setup only possible with your professional services team?

If the answer is yes, that fee is not optional regardless of how the proposal presents it, and it recurs every time you open a new office. Rollout sequencing is covered in the meeting room display rollout plan.

The email you can paste

Trim to taste. The bracketed parts are the ones you have to fill in.

Subject: Room booking requirements, [Company name], [n] rooms

Hello,

We are evaluating room booking systems for [n] meeting rooms across [n] sites, on [Google Workspace / Microsoft 365]. Before we book a demo, could you answer the following in writing. Where the answer is "on the roadmap", please say so and give a date rather than a tick.

  1. Does a booking made on the display create a real event in our calendar, or a record in your system that syncs to ours?
  2. Which calendars do you read from and write to, and with exactly what permission scopes? Can we scope that to a subset of rooms?
  3. Can we use hardware we already own? Please list supported models. If tablets, who is responsible for OS updates and MDM?
  4. When you auto-release a no-show, is the event deleted, declined or shortened, and what notification is sent, from which sending domain?
  5. Is pricing per room, per user, per display or flat? Please send the full price list, the minimum term, and the renewal uplift.
  6. Is there a one-off onboarding, implementation or professional services fee, and is it optional?
  7. Where is our data hosted, by region, and what happens to it if we cancel, within how many days?

We would also like your subprocessor list and a DPA in advance of any evaluation. Thank you.

Seven questions, and the answers will sort a shortlist of eight down to three inside a week.

Where Lobby fits

Lobby answers some of these lines well and some of them badly, and it is more useful to you if we say which. The good ones: pricing is flat, published, and never per room, per user or per display. Free forever up to 3 active displays with no card, Unlimited at USD 30/month billed yearly (USD 360/year) or USD 50 month to month, Pro Unlimited at USD 60/month billed yearly (USD 720/year) or USD 100 month to month. There is no onboarding fee, no professional services team to pay, and no sales call. Setup is under ten minutes, self-serve. Hardware is a separate capital line you buy direct from the manufacturer, at USD 69 per room for 1 to 9 units, dropping to USD 62.99 at 10 or more, owned outright with no markup from us. On question three, you can also point a virtual display at any tablet, TV or monitor you already own, because it is just a URL in a browser tab, and a room overview board counts as one display rather than one per room.

Now the lines Lobby answers badly. Our calendar access to Google Workspace and Microsoft 365 room resources is read-only, and we never write to your calendar. If your mandatory line is that a tap on the wall must itself create the event, weigh that carefully rather than discovering it in week two. There is no enterprise SSO or SCIM at scale, so the SAML SSO and SCIM nice-to-haves in the admin section are a no. There is no MDM on the e-ink hardware. On-premises Exchange is not supported without a hybrid setup. Platform hosting is in the EU on every plan. Lobby-hosted e-ink screens, rendered and served in the EU, are a Pro Unlimited feature, so if EU-only rendering of the screen images is an M line for you, it sets your tier. And there is no desk booking or visitor management in the rooms product, no room automation or AV control, no occupancy sensors, no floor plans or wayfinding, no digital signage playlists or video, and no mobile app, so if any of those are in your spec, we are not on your shortlist and you should cross us off now rather than after you have already mounted the displays.

The reason to send the spec anyway is that it costs you an email and it tells you which vendors will commit to an answer. Ours are above, in public, which is the only reason we are comfortable telling you to demand the same from everyone else.

TL;DR

  • Send vendors a spec instead of reading their feature matrix. Mark every line M or N first, because an undifferentiated list of forty requirements gets you forty ticks and no information.
  • The highest-value question is whether a booking made on the panel creates a real event in your calendar or a record in the vendor's database. Two sources of truth drift, and the failure mode is a green panel outside a full room.
  • Ask which permission scopes the product requests by name, and look at the OAuth consent screen or Azure app registration during the demo rather than after you consent.
  • Auto-release has three possible behaviours: delete the event, decline it, or shorten it. They are not equivalent, and the one you get decides how many support tickets week one produces.
  • "Can we use hardware we already own" has a follow-up that matters more: if the answer is tablets in kiosk mode, establish who owns OS patching and MDM before you buy.
  • Ask for a hosting region, not a cloud provider name, and get the deletion timeline after cancellation in writing along with the subprocessor list.
  • Get the pricing unit and the professional services fee in the same written line, because separating them is how the recurring number is made to look small.
  • Where a vendor gates pricing behind a sales call, record it as gated rather than guessing, and expect the first quote to track your headcount rather than your room count.

Related reading

Sources

Try Lobby — free forever up to 3 displays

Room booking that just works.

Get started →