Matrix Booking

What can be booked and how easily: desks, meeting rooms, parking spaces and other resources (lockers, equipment, EV chargers), interactive floor plans per site and floor, desk attributes (monitor, standing desk, accessibility), neighbourhoods and zones, hot and assigned desks, recurring and multi-day bookings, booking for colleagues and guests, room booking synced both ways with Microsoft 365 or Google calendars, room displays, booking from the web, mobile apps, Outlook, Microsoft Teams and Slack, and several languages.

0 — Books nothing for an organisation's own staff; a customer appointment tool or a facility system without self-service booking.

3 — Desks can be booked from a list or a simple plan in a web app; rooms, parking, mobile apps and calendar integration are basic or not described.

5 — Desks, rooms and parking on interactive floor plans for several sites and floors, desk attributes and assigned desks, recurring bookings, booking on behalf of colleagues, mobile apps, room bookings synced with Microsoft 365 or Google calendars, and booking from Microsoft Teams or Slack.

8 — Neighbourhoods and zones per team, an Outlook add-in that books a room and a desk together, room displays with check-in, guest and visitor bookings linked to the host's desk, resources such as lockers and EV chargers, floor plans imported from CAD or drawn in an editor, accessibility of the apps stated, and the product in German and other languages.

10 — Booking that runs a multi-country estate: every resource type above on one plan, wayfinding to the booked desk, booking from every channel with parity documented, catering and equipment with the room, and the accessibility of web and apps documented to WCAG 2.1 AA.

How the booking is kept honest and fair: check-in by app, QR code, NFC, room display, Wi-Fi or sensor, auto-release of desks and rooms nobody checked in to, booking rules per site, area or group (how far ahead, how many days a week, maximum duration), approvals for restricted areas, assigned and permanent desks with release when the owner is away, fair allocation of scarce parking (lottery, rotation, priority for disabled or EV drivers), capacity limits per floor, and notifications and reminders.

0 — No rules at all; any booking stands whether or not anyone arrives.

3 — A booking can be cancelled by the user; check-in, auto-release and booking rules are basic or not described.

5 — Check-in by app or QR code, automatic release of unconfirmed desk and room bookings after a set time, booking windows and limits per site or group, restricted areas for named groups, assigned desks that their owner can release, and reminders before the booking.

8 — Check-in by room display, NFC, Wi-Fi or occupancy sensor, rules per area and user group with approvals, fair parking allocation by lottery or rotation with priority spaces, capacity limits per floor, permanent desks released automatically during absence synced from the HR system, and the no-show logic documented.

10 — Rules that run themselves across an estate: every check-in method above, automatic desk assignment from team and attendance plans, policy changes rolled out per country with an audit trail, and no-show and release rates reported per site with the method stated.

How people plan office days together: a weekly view of who will be in the office, home office and absence, favourite colleagues and teams, team days and anchor days, booking next to colleagues, office events, attendance planning and office policies (for example two office days a week) with nudges rather than enforcement, the planner inside Microsoft Teams, Outlook or Slack, sync with absence and HR systems, and visibility settings so employees decide who sees their plans.

0 — No view of colleagues or office days; booking only.

3 — A list of who has booked a desk on a day; team planning, policies and visibility settings are basic or not described.

5 — A weekly planner of office, home and absence days, favourite colleagues and teams, booking a desk next to a colleague, team days, the planner in Microsoft Teams or Slack, notifications when colleagues plan to come in, and a visibility setting per user.

8 — Anchor days and office policies per team with nudges, office events and invitations, sync with absence and HR systems, recommendations of the best office day for a team, delegation for assistants, and visibility and privacy options documented for employees and admins.

10 — Coordination that changes behaviour and is measured: team plans that book desks and rooms automatically, policy adherence shown only in aggregate, works council-ready configuration documented, and the effect on office attendance reported with the method stated.

What the data is worth for a real estate decision and how it treats the people it measures: utilisation per desk, room, zone, floor and site, booked against checked-in or measured use, peak days and times, no-show rates, room size against meeting size, occupancy sensors, badge, Wi-Fi or people counting data, scenario planning for consolidation, scheduled reports and export to Excel or BI tools, and on the other side aggregation, anonymisation and minimum group sizes, configurable retention and deletion of booking records, role-based access to personal data, and documentation a works council or data protection officer can work with.

0 — No reports of any kind; only the current bookings are shown.

3 — Booking counts or a utilisation chart per site; check-in data, export, retention and anonymisation are basic or not described.

5 — Utilisation per desk, room, floor and site over time, booked against checked-in use, no-show rates, peak days, CSV or Excel export, a retention period for booking data stated or configurable, and reports that can be limited to aggregates.

8 — Occupancy sensors or badge and Wi-Fi data combined with bookings, room size against attendance, scenario or consolidation planning, a BI connector or analytics API, anonymised reports with minimum group sizes, role-based access to personal booking data, deletion periods per data type, and material for a works council agreement published.

10 — Evidence a portfolio decision can rest on: measured and booked occupancy reconciled with the method stated, data quality and sensor accuracy documented, raw data exportable in an open format, privacy by design documented down to field level, and a sample works council agreement or DPIA published.

How the tool fits the company's systems and is run: Microsoft 365 and Exchange room mailboxes, Google Workspace, Microsoft Teams and Slack apps, single sign-on with Entra ID, Okta or Google (SAML or OIDC), SCIM user provisioning, HR system sync (Personio, SAP SuccessFactors, Workday), access control and badge systems, room displays and sensor hardware, a documented REST API and webhooks, several sites, countries and companies in one account, roles and delegated administration per site, audit logs, bulk import of users and resources, and implementation and support.

0 — No integrations, one admin login, users and desks entered only by hand.

3 — A calendar connection and a few admin roles; single sign-on, provisioning, API and multi-site administration are basic or not described.

5 — Microsoft 365 or Google Workspace calendar sync, Teams or Slack app, single sign-on with Entra ID, Okta or Google, user import or SCIM provisioning, a documented REST API, several sites with administrators per site, and bulk import of users and resources.

8 — SCIM provisioning with groups, HR system sync, access control or badge integration, webhooks, SAML and OIDC, granular roles and delegated administration per site and country, audit logs, room display and sensor hardware supported by named models, several companies or tenants in one account, and an implementation plan published.

10 — Administration that scales across a multinational estate: every setting reachable by API with parity stated, multi-tenant administration with separate data per company, audit logs exportable to a SIEM, an open hardware policy with documented device APIs, and a named support SLA per plan.

Who the contracting entity and the parent company are, where employee profiles, bookings (who sat where on which day), presence and absence plans, parking licence plates and sensor data are stored and processed, and who the subprocessors are (hosting, email and push notifications, maps, analytics, support and payment tools, hardware and sensor clouds). Independently sourced by the sovereignty pipeline. A calendar integration with Microsoft 365 or Google that the customer already runs is part of the customer's chain; the vendor's own hosting and subprocessors are what is judged.

0 — Non-EU vendor and contracting entity, hosting unstated, subprocessors unnamed, and no data processing agreement offered.

3 — A privacy policy and a data processing agreement exist, but hosting location is unstated or non-EU and the subprocessors are not listed.

5 — EU hosting available and an EU contracting entity or EU representative, but parts of the chain (email and push notifications, analytics, support, payment, sensor clouds) run through non-EU providers without a stated safeguard.

8 — EU hosting on named infrastructure, EU contracting entity, subprocessors listed with their locations, a data processing agreement published, and security certifications (ISO 27001, SOC 2) stated — or an on-premise edition documented that keeps every record on the customer's own servers.

10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor, or an on-premise edition with no call home, data export and deletion documented, and certifications published with their scope rather than implied.

Whether a buyer can compute the real annual cost from public pages alone: price per tier by user, desk, bookable resource, site or device, what rooms, parking and analytics cost on top, which features (SSO, SCIM, HR sync, sensors, room displays, visitor management, API) need a higher tier or an add-on, hardware prices and their licences, platform or setup fees, minimum users or minimum spend, the free tier and its limits, minimum term and VAT.

0 — No public prices at all; every customer is a sales call.

3 — A starting price or a free tier exists, but how cost scales with users, desks, rooms, sites or devices is unclear.

5 — Tiers are public with their price unit (per user, desk, resource or site) and main inclusions, but at least one commonly needed piece (room or parking booking, SSO, analytics, displays or sensors, setup) is unpriced or "on request".

8 — Every tier priced publicly with its scaling rule, add-ons and hardware licences priced, setup and platform fees stated, minimum users or spend stated, minimum term and VAT treatment stated.

10 — Complete price computability: annual cost derivable for a given number of users, desks, rooms, parking spaces and sites, with every add-on, hardware, support and implementation fee and the cancellation and data-return terms published.