Skip to content
LobbyExpress
Search

Guide

Rolling out visitor management across multiple sites

A practical plan for taking a visitor system from one building to many: choosing a pilot, deciding what is standard and what is local, setting up central reporting, training each role and phasing the go-lives.

By LobbyExpress Editorial

Putting a visitor system into one building is a project. Putting it into twenty is a programme, and the difference is not just scale. Every site has its own entrances, its own receptionist with their own way of doing things, its own contractors and its own idea of what “the process” is.

The organisations that roll out smoothly make two decisions early. They decide what must be the same everywhere and what each site may set for itself. And they treat the first site as a test of the plan, not just the first installation.

This guide sets out a sequence that works for most multi-site estates — offices, schools in a trust, clinics, depots or campuses — from inventory to steady state.

Start with an inventory, not a configuration

Before anyone opens the admin console, collect the same facts about every site. A short form sent to each site lead works, followed by a visit to anywhere unusual.

Ask each site Why it matters
Entrances used by visitors, and when each is staffed Drives hardware and fallback plans
Typical visitor mix: guests, contractors, deliveries, public, parents Drives visitor types and workflows
Current sign-in process and who owns it Shows what you are replacing and who to train
Local rules: inductions, permits, safeguarding checks Drives site-specific steps
Evacuation arrangements and who holds the list Roll-call must work from day one
Network and power at the reception position Hardware readiness

The inventory does two jobs. It gives you the information to configure the system, and it shows which sites are similar enough to share a configuration. Most estates turn out to have a handful of site types rather than twenty unique snowflakes.

Choose a pilot that teaches you something

A pilot site should be representative. If you pilot at the quietest, best-run office, everything will work and you will learn very little. If you pilot at the most complex, you may spend months solving problems no other site has.

Choosing a pilot siteAn illustrative two-by-two matrix. The horizontal axis is visitor volume, from low to high; the vertical axis is process complexity, covering contractors, safeguarding and security rules, from low to high. Six example sites, A to F, are plotted. The quadrant of low volume and low complexity is labelled “too easy to learn from”; high volume and high complexity is labelled “go later, with lessons learned”. A highlighted zone around the middle of the chart, containing sites C and D, is labelled “good pilot candidates”.ILLUSTRATIVEToo easy to learn fromGo later, with lessons learnedSpecialist: plan separatelyBusy but simple: early waveGood pilot candidatesABEFCDVisitor volumeProcess complexityLowHigh
Example sites only. A pilot near the middle of the estate exercises most of the workflows you will need, without the outliers that only one site has.

Give the pilot a fixed length and written success criteria agreed in advance: for example, that reception can complete sign-in without workarounds, that hosts receive notifications reliably, and that an evacuation drill produces a usable roll-call. Our guide to running an evacuation roll-call covers how to test the last one properly.

Keep a simple log during the pilot of every configuration change, every workaround and every question reception asked. That log becomes the training material and the standard configuration for the next wave.

Decide what is standard and what is local

This is the decision that most shapes a multi-site rollout. Too much central control and sites invent workarounds; too little and you end up with twenty different systems that happen to share a login page.

Three layers of configurationA layered stack of three bands. The bottom band, set centrally and fixed everywhere, covers data retention, privacy notice, security and sign-on settings, visitor type definitions, and reporting fields. The middle band, set per site type or country, covers languages, badge layouts, contractor workflow and safeguarding steps. The top band, set by each site, covers entrances and kiosks, host lists, evacuation points and local site rules. An arrow on the left indicates that the lower layers change least often and need central approval.More local, changes more oftenSiteOwned by the site leadSite type or countryOwned by the programmeOrganisation-wideFixed centrally, change byapproval onlyEntrances and kiosksHost listsEvacuation pointsLocal site rulesLanguagesBadge layoutsContractor workflowSafeguarding stepsRetention and privacy noticeSecurity and sign-onVisitor type definitionsReporting fields
The bottom layer is where consistency matters most: data protection, security and the definitions that make reporting comparable. The top layer is what only the site can know.

Fix centrally: data retention periods, the privacy notice shown at sign-in, single sign-on and administrator permissions, the list of visitor types and the fields that feed reporting. These are the settings your data protection officer and security team need to be able to vouch for at every site. Where sites span countries, ask your DPO or legal team whether any of them need different notices or retention periods; that becomes a site-type setting, not a local one.

Set by site type: languages, badge layouts, contractor and safeguarding workflows. A school in a trust and a head office have different needs, but every school in the trust probably has the same ones.

Leave to the site: which entrances and kiosks exist, who can host visitors, where people muster in an evacuation, and any genuinely local rules.

Write the split down and agree who can change what. The vendor’s administration model needs to support it: check, during procurement, whether site-level administrators can be restricted to their own sites and whether central settings can be locked. Our guide to writing a visitor management RFP explains how to put that kind of requirement into a tender.

Set up reporting before site two

Central reporting is a common reason for buying one system across the estate, and it only works if every site records the same things the same way. If one site logs contractors as “Visitor” and another as “Contractor”, the totals mean nothing.

Before the second site goes live, agree the visitor types, the site and entrance naming convention, and what “signed out” means when someone leaves without stopping at the desk. Decide who can see which sites’ data: a site manager usually needs only their own site, while the central team needs the estate. Then build the handful of reports people will actually use — visitors by site and type, sign-out completeness, contractor records — and check them against the pilot data.

Train by role, not by feature

A single training session for everyone tends to bore the hosts and under-prepare the receptionists. Train each role in what it does.

Role Needs to know
Reception Daily sign-in and sign-out, exceptions, printer and kiosk fixes, the fallback when the system is down
Hosts Pre-registering visitors, responding to arrival notifications, signing visitors out
Fire wardens Opening the roll-call on their device, marking people safe, what to do offline
Site lead Local configuration, adding hosts, running site reports
Central admin Standard settings, user management, change control, vendor contact

Record short videos or one-page guides from the pilot, using your own screens and your own terminology. Name a local champion at each site who can answer first-line questions, and make sure there is a printed fallback procedure at every reception.

Phase the go-lives

Roll out in waves, grouped by site type or by region, with a review gate between each. The gate is a short meeting with a simple question: did the last wave meet its success criteria, and has anything changed in the standard configuration?

A phased multi-site rolloutAn illustrative phased plan shown as horizontal bars. Preparation covers the site inventory and standard configuration. The pilot follows, then a review gate. Wave one covers similar sites, then another review gate. Wave two covers the remaining sites. A final band shows that sites move to steady state, under central ownership, as each wave goes live. Durations are not shown because they vary by estate.ILLUSTRATIVEPreparePilotWave 1Wave 2Steady stateInventory, standardsOne typical siteSimilar sitesRemaining sitesLive sites move to central ownershipReview gateReview gate
Illustrative sequence; durations depend on the size and variety of the estate. Each amber diamond is a review gate where the standard configuration is updated before the next wave; specialist sites may need a wave of their own.

Avoid scheduling go-lives in a site’s busiest period, and keep the old process available, in parallel, for the first days at each site. For each go-live, run through the same readiness check.

Site go-live readiness checklistA checklist of eight items to confirm before each site goes live: hardware installed and tested; host list loaded; local settings reviewed by the site lead; reception, hosts and wardens trained; roll-call tested in a drill or walk-through; privacy notice displayed at sign-in; paper fallback procedure printed at the desk; and a named local champion with a support contact.Before each site goes liveHardware installed and testedHost list loaded and checkedLocal settings signed off by site leadReception, hosts and wardens trainedRoll-call tested in a drillPrivacy notice shown at sign-inPaper fallback printed at the deskLocal champion and support contact
The same eight checks at every site. If any box is unticked, move the date rather than going live with a gap.

After the last site

A rollout ends, but the system does not. Name a central owner, keep a change log for the standard configuration, and review it at a set interval with a few site leads in the room. New sites should go through the same inventory and readiness check as the original ones.

Where to go next

If your estate uses door access control, plan the integration once, centrally — see integrating visitor management with access control. For the kit list, read choosing visitor sign-in hardware. If you are still deciding what kind of product to standardise on, our analysis of workplace platforms vs dedicated VMS sets out the trade-offs. Or browse the vendor directory by category.