Double-booked meeting rooms. A scheduling spreadsheet that three people edit at once. A room blocked out all morning by a meeting nobody turned up to. Resources sitting idle in one building while another runs short. Most organisations reach for booking software at a recognisable moment: a hybrid-work rollout, an office move or a second site, a failed audit, a lease renewal where finance wants proof of how the space is used, or the point where the spreadsheet stops being maintainable.
I build facility booking software for organisations that have outgrown the generic answer. It is shaped around how you allocate space, it connects to the systems you already run, and you own it outright.
When off-the-shelf booking software is enough
Plenty of organisations are well served by off-the-shelf booking software, and I’ll say so. If your booking is first-come-first-served with simple capacity limits, the integrations you need are the common ones, and your reporting needs are utilisation percentages and booking trends, a SaaS product such as Skedda or Yarooms will do the job for a modest monthly fee.
A custom build earns its place when the standard tools start to fight your reality:
- Your booking rules carry real business logic. Weighted allocation by seniority, priority pools, member tiers, cost-centre budget caps, or executive override. SaaS rule engines model the simple cases well and become brittle past them.
- Approval is more than one manager clicking yes. Multi-level sign-off, delegated authority, and conditional routing tend to need code, not configuration.
- Per-user or per-room pricing punishes your scale. At several hundred users or a large estate of bookable spaces, subscription fees climb steadily, and visitor management or advanced reporting usually sit behind paid add-ons.
- Access control has to be reliable. Generic integrations cover the happy path. A door that fails to open, backup authentication, and timeout handling are exactly where users lose faith and revert to email.
- Data has to feed other systems. When booking data must reach ERP cost centres, project billing or departmental budgets, SaaS tools tend to export a CSV or lean on Zapier glue.
- Compliance or data residency rules a hosted product out. Regulated sectors may need UK-only, private-cloud or on-premise hosting with audit logs and retention under your control.
If none of that applies, buy off the shelf. If several do, the maths and the day-to-day friction both start pointing the other way.
Where off-the-shelf booking software falls short
Even when a SaaS tool is broadly the right fit, the same gaps come up:
- The workflow was designed for someone else’s business, so your team works around the software instead of with it.
- Per-space and per-user pricing looks cheap at first and scales quietly. Add visitor management or analytics tiers and the annual figure drifts well past the headline.
- Industry-specific rules and one-off requirements often cannot be accommodated, so they fall back to spreadsheets and email alongside the system.
- Integrations are limited to a vendor’s catalogue. Legacy CAFM tools, bespoke room management systems and older ERPs usually are not in it, which leaves data silos and manual re-entry.
- Calendar sync is frequently one-way or laggy, so a room shows free in the system and busy in a personal calendar, and double bookings happen anyway.
- Over-customising a SaaS product to bend it your way risks breaking on the next vendor update.
The licence fee is the smaller part of the cost. The bigger part is the hours people spend keeping incompatible systems in sync, and the bookings that go wrong despite the software.
What you get with a custom build
I map your existing workflows first, then build around the parts that already work rather than replacing them wholesale. Corporate meeting rooms, university labs, clinic consulting rooms, sports courts, council chambers, whatever you are scheduling, the system is shaped to it and to the way you allocate it.
The system is built around the entities your operation runs on: spaces and their attributes (type, capacity, amenities, building and floor), users and their roles, bookings and recurring series, approval steps, no-show events, access control events, and an immutable audit log of who changed what and when.
Integration is treated as core, not an afterthought. Two-way calendar sync with Microsoft 365 and Google Workspace, Slack and Teams notifications, meeting links from Zoom or Teams, access control hardware such as Kisi, Salto and HID, and accounting tools like Xero, QuickBooks and Sage. The API layer comes first, so connections to in-house or legacy systems are designed in rather than bolted on later.
UK GDPR is built in from the start, with data subject access and deletion, encryption in transit and at rest, and configurable retention, so there is no expensive retrofit. The architecture scales in phases: start with core booking, then add approval workflows, access control, cost allocation or hardware displays as you need them.
Meeting rooms: the rules that decide whether people use it
Meeting rooms are where most booking systems are judged, and where generic tools break first. The details that matter:
- Booking from where people already are. A Teams booking action or a Slack command, so staff grab a room without opening another app.
- Rules per room. Minimum notice, maximum duration, buffer time for AV setup or cleaning, and daily or weekly quotas per person, enforced by the system instead of a policy email.
- Check-in before release. A reminder, a check-in step and, where you have them, occupancy sensors, so a room held for a cancelled call goes back into the pool. No-show counts per person if you want to enforce the policy.
- Confidential rooms. A client suite or interview room can be visible only to the roles allowed to book it, with attendees and visitors logged against the booking.
- Conditional approval. Boardroom bookings go to an executive assistant, bookings tagged to a project go to finance, and conditions can depend on attendee count or duration.
Features I typically build
The exact set depends on what you need, but most projects draw from:
- A booking interface with calendar, list and floor-plan views, and drag-and-drop scheduling for rooms, desks, equipment and other resources.
- Real-time availability and double-booking prevention across every site and resource type.
- Recurring bookings and booking series for standing meetings, classes and maintenance, with one instance editable or cancellable without touching the series.
- Multi-level approval workflows with delegation, cost-centre checks and override authority for high-value or restricted spaces.
- No-show detection with configurable auto-release, so unused bookings free the room rather than blocking it.
- Two-way calendar sync with Outlook and Google, plus Slack and Teams notifications and automatic video-conference links.
- Role-based permissions and SSO (Azure AD, Okta, SAML) so admins, department heads, guests and general staff each see what they should.
- Configurable email and SMS reminders for staff and visitors to cut no-shows.
- Utilisation reporting: occupancy percentages, peak hours, no-show rates, booking frequency by room, user and department, with CSV and PDF export.
- Cost allocation and chargeback that maps bookings to cost centres and feeds your finance system.
- Access control integration so booked rooms open on time, with a fallback when hardware does not respond.
- Room display tablets, visitor management and equipment co-booking (projectors, parking, minibuses) where the operation calls for them.
- Responsive browser access first, with native mobile apps as a later phase if booking on the move matters.
- UK-hosted, private-cloud or on-premise deployment with encryption and audit logging.
How the project runs
First Gear (5 days). I talk to the people who will use the system, work through current processes, booking rules and integration needs, and build a working prototype with your own data, plus a build plan with a fixed price. Room data, capacity and amenity cleanup usually starts here, since it tends to drive the timeline.
Development (within a month). I build it, shipping core booking first so it is usable early, with regular check-ins so you see progress and can steer it as it takes shape. Calendar sync and access control are tested with real users rather than left to launch day.
Testing and deployment. Quality assurance plus user acceptance testing with your team. Where a multi-site rollout is involved, a pilot validates core workflows before going wider.
Training and support (ongoing). Training sessions and documentation so people adopt it without friction, with support packages available for later changes. You decide when the system evolves, not a vendor roadmap.
What it costs, and what you own
A custom build needs money upfront where SaaS spreads it monthly, so the comparison is about total cost over three to five years, not the first invoice.
Most builds cost £2k to £10k and go live within a month, with the price fixed at the end of First Gear, a £495 prototype of your core booking flow. A focused build covering one or two sites and core booking sits at the lower end; several sites with approval workflows, access control and cost allocation are split into fixed-price phases. Remember the extras on the SaaS side too: floor-plan setup fees, door display hardware licences, visitor management and premium support tiers. For scale, Skedda’s published plans for Europe start at $99 a month, billed annually, for 15 spaces, with each extra space charged on top (checked October 2026). Add up what your rooms, desks and add-ons cost across every site and set that against a one-off build.
What ownership buys you:
- A fixed scope and price, with no surprise increases and no features moving behind a higher tier.
- Software you own outright rather than rent indefinitely, and no vendor lock-in.
- Predictable maintenance costs instead of pricing tied to a vendor’s roadmap.
- A system that changes as the business changes, instead of capping what you can do.
Once I understand your sites, your booking rules and what has to integrate, you get a fixed price, or a plain answer that SaaS is the better call.
Who uses this kind of software
- Corporate offices managing meeting rooms, hot desks, parking and AV kit through a hybrid-work programme.
- Schools and universities scheduling classrooms, computer suites, science labs and sports halls, including bookings by external community users.
- Healthcare providers coordinating consulting rooms, diagnostic equipment and practitioner availability with strict audit needs.
- Sports and recreation venues booking courts, pitches and classes, with membership rules and per-period booking limits.
- Hospitality and events venues managing event spaces, catering and setup coordination, often with customer-facing, branded booking.
- Legal and professional services booking confidential client suites with matter-specific access, and room time and costs allocated to the right matter.
- Councils and public facilities allocating chambers, community halls and assets with published schedules and subsidised or group pricing.
- Co-working spaces handling member desk bookings, meeting room billing, guest access and amenities across multiple sites.
- Manufacturers scheduling production areas, test labs and equipment maintenance windows.
Common Questions About Custom Facility Booking Software
When is off-the-shelf booking software the better choice? ›
Often it is. If your booking is first-come-first-served, your integrations are the standard ones (Microsoft 365, Google Workspace, Slack, Teams), and your reporting needs are utilisation percentages and booking trends, a SaaS tool like Skedda or Yarooms will do the job for less effort. Custom makes sense when your approval logic, allocation rules, access control, or cost reporting are specific enough that a SaaS rules engine can't model them, when per-user or per-room pricing climbs hard at your scale, or when data residency rules a hosted product out.
How does a custom build compare on cost to a subscription? ›
A build is paid once: most cost £2k to £10k at a fixed price, against a subscription that charges per room or per user every month and grows as you add sites. For a single office with a handful of rooms, SaaS is usually cheaper. Across several sites, with approval rules and add-ons for visitor management or reporting, the subscription total over three to five years is the number to compare against. Send me your current bill and room count and I'll tell you which side you're on.
What's a realistic development timeline? ›
A focused build covering core booking, calendar sync and basic reporting typically goes live within a month. Several sites, approval workflows, access control integration, cost allocation and hardware displays are added in later phases, each about a month long with its own fixed price. I ship core booking first so it is in use early, then add the rest in phases.
Will it sync properly with Outlook and Google Calendar? ›
Yes, and getting the sync right is most of the work in a meeting room build. It runs both ways: booking a room creates the calendar invite, and a meeting booked straight into someone's Outlook or Google calendar marks the room as taken. Recurring series, a single cancelled instance and duplicate invites are tested with real users before launch, because a room that shows free while it's busy is how people stop trusting a booking tool.
Can you integrate with access control and finance systems? ›
Yes. I connect access control hardware such as Kisi, Salto and HID where a booking should open the door, and accounting tools like Xero, QuickBooks and Sage for cost allocation. An API layer comes first, so legacy or in-house systems can connect rather than being left as manual re-entry.
What about data security and compliance? ›
Booking systems hold personal data such as names, emails and booking history, so UK GDPR applies. I build in data subject access and deletion, encryption in transit and at rest, audit logging and configurable retention. UK-based hosting is available, and for regulated sectors I can deploy to a private cloud or on-premise where data residency or ISO 27001 expectations require it.
What stops a booking system from being ignored after launch? ›
Most failed rollouts come down to weak change management, unreliable calendar sync, or a door that doesn't open when the booking says it should. I test calendar sync with real users early, treat door access as a critical path with fallbacks, and run a pilot with training and documentation before a wider rollout. Booking through the system has to be easier than sending an email.