The short version
- Roll out desk booking in three phases, each closed by a go/no-go gate that IT and facilities both sign
- Phase 1 is core booking with SSO and directory provisioning. It exists to remove password, “how do I” and no-show tickets before anyone else joins
- Phase 2 adds visitors and parking on the same accounts and floor plans, so it adds almost no new admin for IT
- Phase 3 covers anything beyond standard set-up. It is scoped with you and quoted before work starts. Custom API and third-party integrations are on Enterprise
A desk booking implementation rarely fails because the software breaks. It fails because the tickets never stop. People need resets for yet another login, ask IT to “book me a desk”, argue over desks booked and never used, and wait for floor plan edits only IT can make. A phased rollout fixes this with one rule: no new scope until the current phase runs without IT in the loop.
The plan below has three phases. For each one it sets out who does what in IT and facilities, the gate you sign before moving on, and the tickets to expect.
Why phase a desk booking rollout
Phasing limits how many people hit a problem before you can fix it. The GOV.UK Service Manual runs government services through discovery, alpha, beta and live phases, and the manual sets out what a team needs to be confident of before it moves from one phase to the next. A desk booking rollout is far smaller, but the logic transfers. Prove each layer with a small group, then widen.
The people side matters just as much. Prosci’s ADKAR model describes five outcomes a person needs before a change sticks: Awareness, Desire, Knowledge, Ability and Reinforcement. Most “how do I book” tickets are a Knowledge or Ability gap. Putting bookings, reminders and approvals into tools people already open every day closes much of that gap without a training programme.
Gates are what make phasing real. A gate is a short list of checks that IT and facilities both sign before the next phase starts. If a check fails, you fix it inside the current phase. You do not carry it into a bigger one.
The phased rollout plan at a glance
| Phase | Scope | Gate to move on |
|---|
| 1. Core booking | Desks, floor plans, SSO, directory provisioning, auto-release, Outlook calendar sync and Teams notifications | The pilot group books without help and account tickets have stopped |
| 2. Visitors and parking | Visitor pre-registration and check-in, parking bays including accessible bays | Reception and parking run without IT, with no new ticket category |
| 3. Scoped extras | Anything beyond standard set-up, scoped and quoted first. Custom API and third-party integrations on Enterprise | Written scope, named owners on both sides, tested before production |
Phase 1: core desk booking with SSO and directory provisioning
Phase 1 removes account tickets before they exist. Connect single sign-on to your identity provider so nobody has a booking password. Then turn on directory provisioning so accounts appear when people join and close when they leave. HybridHero supports SAML 2.0 and OIDC single sign-on with Azure AD, Okta and Google. It offers SCIM 2.0 provisioning with Okta, and user provisioning and deprovisioning with Microsoft Entra ID. SSO and Active Directory sit on the Professional and Enterprise plans.
Keep the pilot to one floor and one team. Put bookings where people already look. With calendar integration, desk bookings made in HybridHero show up in Outlook, and booking confirmations, check-in reminders and approval prompts arrive in Microsoft Teams. iOS and Android apps cover the person booking from the train. Every client you leave out becomes a workaround, and workarounds become tickets.
Split ownership now, in writing. IT owns identity and integrations. Facilities owns the furniture. With role-based permissions scoped to their site, the office manager moves desks, blocks off areas and settles seating questions without raising a ticket.
| Phase 1 | What happens |
|---|
| IT | Connects SSO and provisioning, scopes admin roles by location, sets how far ahead people can book, configures auto-release, and tests that a leaver loses access |
| Facilities | Owns the floor plan, maps team neighbourhoods and amenities, briefs the pilot team, and handles seating requests |
| Go/no-go gate | Pilot users book without asking anyone. A test leaver is deprovisioned. No account tickets in the final pilot week. Facilities edits the floor plan without IT |
| Ticket risks | Password resets, “book me near my team” requests, booked-but-empty desks, floor plan change requests |
| How they shrink | SSO removes passwords. The interactive floor plan lets people pick their own desk, and team leads can book on behalf of their team. Auto-release returns unclaimed desks to the pool after a missed check-in, so nobody polices no-shows by hand |
Phase 2: visitors and parking
Phase 2 adds the two areas where a failure is visible the moment someone arrives. Start it only after Phase 1 has passed its gate, because visitors and parking reuse the same accounts, roles and floor plans. That reuse is why this phase adds little work for IT.
For visitors, hosts pre-register guests, who then receive arrival instructions and a personal QR code for faster check-in. The host gets an alert by email, SMS or app push when the visitor checks in, and branded badges print with the visitor’s name, host and visit details. For parking, bays sit on the same map as desks. Accessible bays carry permission controls, so approved users see those options first.
| Phase 2 | What happens |
|---|
| IT | Extends roles to reception and parking admins, checks visitor data handling against your retention policy, and confirms host alerts arrive |
| Facilities | Sets up reception check-in and badge printing, maps standard and accessible bays, and writes the visitor arrival message |
| Go/no-go gate | Reception checks in visitors without calling IT. Hosts receive arrival alerts. Parking runs a full working week with no manual reassignment by IT |
| Ticket risks | “My visitor is stuck at reception”, parking disputes, bays held by people who never arrived |
| How they shrink | Pre-registration puts visitor details in place before arrival. Auto-release frees unused bookings. Facilities owns parking rules, so disputes go to them, and the platform logs every action, so the record settles who booked what |
Phase 3 covers anything beyond standard set-up, and it starts with a scope, not code. Every extra is scoped with you and quoted before work starts. Custom API and third-party integrations are on the Enterprise plan. Timing is agreed as part of that scope, never promised before it exists.
Check configuration before you scope anything. Much of what teams first ask for is a setting, not custom work. Our guide on how to configure HybridHero to fit the way you work covers what standard set-up already handles.
The ticket risk in this phase is different. Extras rarely fail on day one. They fail months later, after an update on either side, when nobody remembers who owns them. So this gate is about ownership and testing. HybridHero’s developer documentation starts integration work with a read-only request in an approved test environment, which keeps early testing away from live bookings.
| Phase 3 | What happens |
|---|
| IT | Documents the system involved, the data that moves, who maintains the link, and how it is tested |
| Facilities | Confirms the business need and who will use the result day to day |
| Go/no-go gate | Written scope and quote approved. A named owner on both sides. Tested outside production before go-live |
| Ticket risks | Integrations nobody owns, and breakages after an update on either side |
| How they shrink | A scoped, tested extra with a named owner has someone to call who is not your help desk |
Migrating from another desk booking system
If you are replacing a tool, run the same phases and treat the migration as the first step of Phase 1. Import users and desks by CSV, then run both systems side by side on the pilot floor only. Keep that overlap short, because people booking in two places is its own source of tickets.
For eligible Enterprise customers, the Switch Programme covers the move. It starts with a 15-minute switch assessment call and produces a one-page migration plan, with contract guidance (not legal advice). The Switch Programme page says most organisations are live within 30 days. That covers the standard migration. Scoped extras in Phase 3 are timed on their own scope.
Enterprise also includes tailored implementation and rollout, plus a dedicated customer success representative. That matters most when the phases run across several sites at once. See enterprise deployment at scale for how multi-site rollouts are run.
What a finished Phase 1 looks like
Judge a desk booking implementation by the ticket queue, not the launch date. After Phase 1, accounts manage themselves and bookings sit in calendars. Facilities runs the map, and no-shows clear on their own. IT reviews the activity log instead of the inbox. That is the operating model behind HybridHero for IT teams.
Frequently asked questions
How long should each phase of a desk booking rollout take?
Run each phase until its gate passes, not to a calendar date. A sensible minimum for the pilot is one full working week, so you see a normal week of bookings before widening. Scoped extras in Phase 3 are timed as part of their scope.
Do we need SSO before launching desk booking?
Yes, if you want to avoid password tickets. Adding SSO after launch means moving every user onto it later. In HybridHero, SSO and Active Directory are on the Professional and Enterprise plans.
Who should own the floor plan?
Facilities or the office manager, not IT. Give them role-based access scoped to their site so they can move desks and block off areas without raising a ticket. IT keeps ownership of identity and integrations.
Can we move our data from our current desk booking system?
Users and desks can be imported by CSV. Eligible Enterprise customers can use the Switch Programme, which includes an assessment call and a one-page migration plan.
What counts as a scoped extra?
Anything beyond standard set-up, such as connecting booking data to another system you run. It is scoped with you and quoted before work starts. Custom API and third-party integrations are on the Enterprise plan.