Desk Booking System: What It Does and Who Needs One

A desk booking system is a reservation layer sitting on top of a list of desks. It knows every desk in the building, shows them on a floor plan, lets a person claim one for a day or a morning, and records whether they turned up. Every other feature in the category is built on those four things.

Nobody buys one because they wanted a floor plan. They buy one because a lease renewal is coming and somebody has to defend how much of the floor is used, or because two people walked in on a Tuesday and found one free desk between them. Those are different problems, and they lead to different purchases.

What follows is what the software actually contains, how the pricing models work and how fast they compound, and the honest version of who needs one. That last part matters more than the feature list, because the usual outcome of a badly chosen desk booking rollout is not a visible failure. It is quiet non-use. The licences renew, someone opens the dashboard once a quarter, and nobody has booked anything since the launch email.

What a desk booking system actually contains

Strip the marketing and there are eight components. Almost every vendor has all eight. The differences are in how well each one works, not whether it appears on the datasheet.

Desk inventory

A record of every desk with an identifier, a location, and attributes: monitor count, sit-stand or fixed, dock type, step-free access, quiet zone, permanently assigned or bookable. This is the boring part and it is where most implementations stall, because a person has to walk the floor and write down what is physically on each desk. Budget most of a day per hundred desks and do it once, properly. Attributes you do not record are attributes nobody can ever filter on, and "desk with two monitors and a Thunderbolt dock" is the single most requested filter in every deployment I have seen described.

Floor plans

An image of the floor with desk pins placed on it. Two questions matter. Can you upload your own plan and place the pins yourself, or does the vendor charge a professional services fee to do it for you. And what happens when you knock a wall through and re-lay the floor, which offices do far more often than they plan for. If re-drawing a floor means raising a ticket, you will stop re-drawing it and the map will slowly stop matching the building.

Reservations and booking rules

Claiming a desk for a day, a half day, or a run of days, plus the rules around it: how far ahead people can book, how many days a week, whether recurring bookings are allowed, whether anyone can hold a desk permanently.

The booking horizon causes more arguments than any other setting. Set it to 90 days and a small number of organised people will quietly lock the best desks for the quarter. Set it to two days and nobody can arrange childcare around their office days. Most offices land between 14 and 30 days, and the ones that work usually pair a long horizon with a cap on how many future days one person can hold.

Neighbourhoods and zones

A block of desks allocated to a team or a function. People book within their own block, so engineering ends up near engineering without anybody owning a specific chair. For a large number of offices this is the feature that does the real work, and it is worth understanding before you buy, because in some cases it removes the need for individual booking entirely.

Colleague finder

Search for a person and see where they are sitting today, or which days they intend to be in. This is the feature employees genuinely use, and it is the one that needs a privacy decision before launch rather than after the first complaint. Decide two things up front: whether a person can hide their location from peers, and whether managers see more than peers do. If the answer to the second is yes, say so publicly. Discovering it later is what turns a scheduling tool into a surveillance story.

Check-in and auto-release

A booking nobody claims should go back into the pool. Check-in can be a tap in an app, a QR code stuck to the desk, a badge swipe at the door, a wifi association, or an agent on the laptop. Auto-release cancels the booking when no check-in arrives within a window, typically 30 to 120 minutes after the booking starts.

Without auto-release the system reports 90% booked while the floor is visibly half empty, which is the same failure that automatic release fixes for meeting rooms. The failure mode is specific and it looks like success: the dashboard is green, the utilisation number is high, and the number is measuring intent rather than presence.

Utilisation reporting

Bookings over time, split by floor, team and day of week. Two numbers get confused constantly. Desks booked is not desks occupied. A system with reliable check-in can report both. A system without it can only report the first, and the first is always the larger number. If you are buying the software specifically to make a real estate decision, the check-in mechanism is the product, and everything else is packaging around it. This is the same distinction as occupancy sensors versus calendar data in the meeting room world, and it plays out the same way.

Integrations

Four that matter. Calendar, so a desk booking shows up in Outlook or Google Calendar rather than living in a separate app. Identity, so accounts provision and deprovision from Entra ID or Google Workspace, ideally over SCIM. Chat, so people can book from Slack or Teams. And access control, so badge events can act as the check-in signal, or the booking can grant door access at a site people do not normally visit.

The badge integration is the one that quietly decides whether your data is worth anything, because it is the only check-in method that costs the employee nothing. Any system worth buying handles calendar and identity properly. If a vendor cannot show you the access control integration working in a demo, against a badge system that resembles yours, treat it as a roadmap item rather than a feature.

How the pricing works, and how fast it compounds

There are four models in this category and vendors mix them. Every price below was read from the vendor's own public pricing page on 11 August 2026, and pricing pages change, so check before you quote anyone.

Per active user per month. deskbird lists its Business plan at USD 3.75 per active user per month billed annually, or USD 4.75 monthly (EUR 2.75 and EUR 3.50 respectively), with its Professional and Enterprise tiers shown as custom pricing.
Per bookable resource per month. Envoy lists its Reservations module, which covers desks, rooms and parking, at USD 5 per bookable resource per month billed annually on the Standard tier. The same page states that this figure excludes the platform fee that every Envoy plan starts with, so the module price is not the whole bill.
Per user, at the lighter end. Officely lists Basic at USD 2.50 per user per month billed annually (USD 3.00 monthly) and Premium at USD 3.50 (USD 4.50 monthly), with a free tier up to 5 users, and meeting rooms and parking sold as separate per space products.
Per space with a plan floor. Skedda publishes Starter from USD 99 per month billed annually with 15 spaces included, Plus from USD 149 with 20 and Premier from USD 199 with 25, priced per space above the included allocation. Small deployments pay the floor regardless of how few desks they have.
On request. Robin does not publish prices and directs you to a demo. Its own pricing page states that all subscriptions are billed annually and that the platform is designed for companies with 500 employees or more, with at least a third of them using the office regularly.

Where each of these fits

Pricing shape is not the same as fit. These five are aimed at different buyers, so the useful question is which one matches your estate rather than which number is lowest.

deskbird. Best for European mid-market organisations that want a published starting price, EU hosting and booking inside Microsoft Teams. Not for estates needing on-premises deployment or asset and maintenance management, and its Professional and Enterprise tiers are custom priced, so the published figure is a starting point rather than a final bill.
Envoy. Best for offices where reception and visitor sign-in is already the anchor problem and desks are the second thing you need, since desks, rooms and parking sit in one module alongside the lobby products. Not for buyers who want desks alone at the lowest line item, because each module is priced separately and sits on top of a platform fee.
Officely. Best for Slack-first and Teams-first companies where adoption is the risk rather than capability. Not for complex estates needing floor plan management across many buildings, badge-driven check-in or enterprise identity governance, and its pricing page notes that some features are not currently available on Microsoft Teams.
Skedda. Best for mixed-use space where the booking rules are the hard part: co-working, studios, university space and shared buildings with several tenant groups. Not for very small deployments, because a 15 desk office pays the same monthly floor as one several times its size.
Robin. Best for larger hybrid organisations that want desks, rooms and analytics in one platform across several buildings. Not for small or single-purpose deployments: its own pricing page says the platform is designed for companies of 500 employees or more, and that a point solution may suit you better.

The per resource model dominates the enterprise end for a simple reason: it scales with the thing the vendor is managing, and it is easy to audit. It also has a property that works in your favour and is rarely pointed out.

The arithmetic, with the working shown

Take 150 people and 105 bookable desks, a ratio of 0.7. At USD 5 per bookable resource per month, that is 105 x 5 = USD 525 per month, USD 6,300 a year, USD 18,900 over a three year term, before the platform fee that Envoy's pricing page says sits underneath every module. At USD 3.75 per active user per month with all 150 people provisioned, it is 150 x 3.75 = USD 562.50 per month, USD 6,750 a year. Close enough to look like a coin toss.

Now assume the project works. You use a year of data, hand back a floor, and end up with 75 desks for the same 150 people. Per resource pricing falls to 75 x 5 = USD 375 per month, USD 4,500 a year, a drop of roughly 29%. Per user pricing does not move at all, because your headcount did not change. The model that looks expensive at signature is the one that rewards you for succeeding.

Two traps to check in the contract. First, the definition of "active user": some vendors bill every provisioned account, some bill only accounts that booked in the period, and the gap between those two numbers in a hybrid office is large. Get the definition in writing. Second, term length and the uplift at renewal. Annual billing is close to universal in this category, and a 36 month term signed before you know your real attendance pattern is a bet you are making with no data.

The hardware line nobody quotes for

A desk panel at every desk is the fastest way to make a desk booking project cost more than the space it saves. Room displays make sense because there are ten rooms. There are 105 desks, and a panel per desk means a per desk capital cost plus batteries or cabling plus a device to manage. Most offices do not need one. A printed QR label with the desk number costs pennies and does the same job, and a wifi or badge based check-in removes the need for anything on the desk at all. If a vendor's proposal leads with desk hardware, ask what breaks if you delete that line.

Who actually needs one

Two conditions have to be true together. Neither is sufficient on its own.

Condition one: your desk ratio is below roughly 1.0. Count bookable desks, divide by the number of people who could plausibly come in on a given day. Not headcount including the fully remote team in another country. People with a reason to be in the building.

Condition two: attendance is not predictable by team. If marketing is in on Tuesdays and Wednesdays every week without fail, the demand is knowable in advance and you can solve it with allocation rather than reservation.

Run the ratio and read off the answer:

1.0 or above. Everyone who comes in can sit down. You do not need this. Buying it here is how you end up with a dead feature and a live invoice.
0.9 to 1.0. A clear desk rule and first come first served handles it. The occasional bad Tuesday is cheaper than the software and the behaviour change it demands.
0.6 to 0.9 with predictable attendance. Neighbourhoods on a floor plan, plus anchor days to make demand legible, will usually beat individual booking. Teams get a zone, they sort out seats among themselves, and nobody has to open an app.
Below roughly 0.6, or unpredictable attendance at any ratio below 1.0. This is where reservations earn their keep. People need to know before they travel that there is a seat.

Three independent triggers override the ratio. Multiple floors or multiple sites, where "walk around and look" stops scaling. Specialised desks that only some people can use, such as step-free access, dual monitor or standing setups, where first come first served produces a genuinely unfair outcome. And a compliance or security requirement for a record of who sat where on a given date, which some regulated environments have and most offices do not.

The uncomfortable version of all this: the ratio that justifies the software is usually the ratio you created by cutting desks, and the software is then how you manage the consequences of that decision. That is a legitimate trade, but it is worth saying out loud internally rather than presenting the tool as a perk.

Who does not need one, and what to do instead

If everybody has an assigned desk, stop here. There is no reservation problem to solve, and a desk booking rollout in an assigned-desk office reliably dies in the first month because the product is answering a question nobody is asking. This is the most common mis-buy in the category, and it usually happens because desks got bundled into a purchase that was really about meeting rooms. The two are separate decisions with separate triggers, which is the whole argument in desk booking versus room booking.

If your ratio is close to 1.0 and you have one floor, the no-software patterns are genuinely adequate for longer than vendors will tell you. A numbered floor plan on the wall, a clear desk rule, and team zones will carry a single-floor office a long way. There is a full treatment of where each of those patterns breaks in hot desking without software.

And if the contested resource is not actually desks, buy for the thing that is contested. In a lot of offices the real scarcity is quiet space rather than seats, in which case booking phone booths and focus pods is the problem to solve first.

The failure mode: utilisation data becomes an attendance record

This is the one that damages things you cannot easily repair, and it follows a predictable sequence.

You buy the system to answer a space question. It produces per person, per day booking records as a by-product, because it has to in order to work. Six months later someone senior asks for attendance by team, because the data is sitting there and the question is easy to ask. The tool that was introduced as "so you can find a desk" is now the source for a compliance report on office days.

Two things happen next, both bad. People start booking desks they do not use, or badging in and leaving, because the metric now has consequences. That corrupts the utilisation data, which is what you paid for in the first place. And the tool acquires a reputation. Adoption of anything optional you introduce afterwards gets harder, because the pattern has been established that voluntary tools become mandatory records.

The mechanism is not subtle. A measurement that carries consequences stops being a measurement and becomes a game. If you want data you can trust for a real estate decision, the data has to be worthless as a stick.

There is a legal dimension too, not just a cultural one. Under the GDPR, personal data collected for one purpose cannot simply be repurposed for an unrelated one, and you are expected to be specific about the purpose up front rather than retrofitting it. Booking records tied to named individuals are personal data. If attendance monitoring is a genuine purpose, name it in the privacy notice before launch, and expect to justify why individual level data is necessary when aggregated floor level data would answer the space question. The UK ICO's guidance on monitoring workers is a readable summary of the reasoning, and the same logic applies to GDPR and meeting room booking data.

The practical mitigation is boring and effective. Aggregate by default, set a short retention period for individual booking records (30 to 90 days covers almost every operational need), restrict who can query by person, and write down which questions the system will be used to answer. If your return-to-office conversation is already tense, read how return to office pressure lands on shared space before you add another data source to it.

What to make a vendor show you in the demo

Roughly in order of how often the answer disappoints:

Book a desk without opening the app. From Slack, Teams or the calendar. If the only path is a mobile app, expect the adoption curve described in why desk booking adoption dies in week three.
Check in without a tap. Wifi, badge or laptop agent. Ask what the false positive rate looks like when someone walks past a desk they did not book.
Move a wall. Ask them to re-draw a floor plan live, with you watching, and see whether it needs a support ticket.
Show occupancy and bookings side by side. If the reporting only shows bookings, say so in the internal business case rather than letting the board read it as occupancy.
Deprovision a leaver. Watch their bookings and their access rights disappear together.
Export everything. Raw booking data, in a file, without asking support. If you cannot get your own data out, the switching cost at renewal is higher than the price difference between any two vendors on your list.

TL;DR

A desk booking system is desk inventory, a floor plan, reservations with rules, neighbourhoods, colleague finder, check-in with auto-release, utilisation reporting, and integrations into calendar, identity, chat and access control. Everything else is packaging.
The trigger to buy is two conditions together: desk ratio below roughly 1.0, and attendance that is not predictable by team. One without the other is not enough.
At 1.0 or above, everyone who comes in can sit down and you do not need this. In an assigned-desk office it will be dead within a month.
Between 0.6 and 0.9 with predictable attendance, team neighbourhoods plus anchor days usually beat individual booking, and cost nothing per desk.
Published pricing takes four shapes: per active user (deskbird lists USD 3.75 billed annually for Business), per bookable resource (Envoy lists USD 5 for Reservations, excluding its platform fee), per user at the light end (Officely lists USD 2.50 for Basic), and per space with a plan floor (Skedda's Starter begins at USD 99 per month with 15 spaces). Robin publishes no price and bills annually.
Per resource pricing falls when you actually cut desks. Per user pricing does not. At 105 desks and 150 people, USD 5 per resource is USD 6,300 a year before the platform fee, and it drops to USD 4,500 if you get to 75 desks.
Desks booked is not desks occupied. If the check-in mechanism is weak, your utilisation number is a measure of intent and should not be used to hand back a floor.
A panel on every desk is the fastest way to spend more than the space saves. A printed QR label plus wifi or badge check-in does the same job.
The failure mode that costs the most is utilisation data turning into an attendance record. People then game it, the data becomes useless, and the trust does not come back. Aggregate by default, keep individual records for 30 to 90 days, and state the purpose before launch.

Sources

Prices verified 11 August 2026. Tier-based and quote-based pricing changes, so confirm directly with each vendor.

deskbird pricing page: published per active user pricing for the Business plan, currency options, and custom pricing for Professional and Enterprise.
Envoy pricing page: published per bookable resource pricing for the Reservations module, billed annually, and the statement that module prices exclude the platform fee.
Officely pricing page: published per user pricing, the free tier up to 5 users, and separately priced meeting room and parking products.
Skedda pricing page: published plan floors with bundled space allocations and per space pricing above them.
Robin pricing page: pricing on request, annual billing, and the stated fit for organisations of 500 employees or more.
Directive 2006/114/EC on misleading and comparative advertising: the rules this comparison is written to, namely objective comparison of verifiable, materially relevant features.
Regulation (EU) 2016/679 (GDPR): purpose limitation and data minimisation in Article 5.
ICO, monitoring workers: regulator guidance on transparency and necessity when monitoring employees.
Microsoft Places overview: Microsoft's own desk and space booking layer, worth checking before buying a third party tool.
Google Workspace Admin Help, buildings, features and calendar resources: how buildings, floors and bookable resources are modelled in Workspace.

Desk Booking System: What It Does, What It Costs, and Who Actually Needs One