Visitor management solution: how to plan, implement and measure it

A visitor management solution combines people, process, software, hardware and integrations configured for your organisation. Implement it by agreeing requirements and owners, configuring the complete visitor journey, testing normal and failed operations, then launching against explicit acceptance criteria.

Recommended starting point: stand-alone sign-in is sufficient where staff can reliably manage approvals, host contact and departures without connected systems. Add integrations when requirements demand directory synchronisation, automated credentials or consolidated reporting—not simply because connections are available. For component detail, see the visitor management system decision guide.

ProtectUK’s access-control guidance, published 1 March 2022, recommends risk assessment and operational requirements before selection, supported by trained staff and clear procedures. This is UK security guidance, not Australian law.

Recommended planning sequence:

1. Requirements: map entrances, staffing hours, visitor types and peak demand. Separate launch must-haves from later improvements; give each must-have a pass/fail test.
2. Ownership: assign facilities service ownership, reception assistance, hosts visitor handoffs, security admission decisions, IT integrations, privacy data handling and procurement contracts. Name backups.
3. Journey: agree invitation, arrival, approval, host acknowledgement, escort, departure and exception closure. Record decision owners, required evidence and escalation timing.

Use the supplier comparison scorecard for selection rather than building an unrestricted feature wish list.

The OAIC’s APP 3 guidance, updated 13 May 2026, says covered organisations may collect personal information only where reasonably necessary for their functions or activities; sensitive information has additional conditions.

Recommended implementation: have the privacy owner approve each field’s purpose, collection notice, permitted viewers, hosting arrangements, retention and deletion rules. Do not import historical records merely because they exist.

Ask IT to verify supported devices, printer compatibility, power, network coverage, device management and replacement arrangements. Provide staffed assistance for visitors unable to use a kiosk or phone. Then configure visitor types, approvals, host backups and permissions.

Recommended integration agreement: for every directory, messaging, door-access or reporting connection, record technical and business owners, the authoritative system, permitted data, credentials, support contact and failure response.

Specify behaviour when a host leaves, an invitation is cancelled, access expires, an integration token is revoked or a message is retried. Test downstream credential removal separately from visitor sign-out, including whether recovery creates duplicate or stale access grants.

Use a locally approved outage route: assisted registration, alternative host contact, controlled records and reconciliation after recovery. Hold admissions if required checks cannot be completed. Adapt the outage and recovery procedure to your site.

ProtectUK recommends contingency arrangements, maintenance documentation and prompt responses to system failures.

The DTA’s Whole-of-Government Cloud Computing Policy, version 1, addresses accountability, migration, exit planning and transition and operating costs for APS entities. These are useful procurement considerations, not universal private-sector obligations.

Ask suppliers: which plan covers the tested configuration, what limits apply, and who resolves integration failures? Request compatibility documentation, assurance scope, incident arrangements, support commitments and witnessed export and deletion tests. Treat unconfirmed capabilities as unknown.

Request itemised costs for licences, modules, devices, installation, messaging, integrations, consumables, training, internal administration, support and exit assistance. Specify currency, tax, billing period, renewal terms and site allowances.

Before migration, test field mapping, timestamps, duplicates and export readability. Agree which records transfer, who reconciles them and when the old service retires.

Completed hypothetical two-site rollout: an office and warehouse followed an illustrative four-week sequence: design, configuration, pilot and staged launch. This is not a delivery promise or vendor result.

The Facilities Lead owned rollout; Reception Leads owned assistance and escalation; the IT Lead owned recovery and exports; the Security Lead owned revocation; the Privacy Lead owned permissions and deletion.

Their go/no-go tests required every scripted arrival to reach the correct decision owner, cancelled credentials to fail at the reader, outage records to reconcile without duplicates, and unauthorised record access to be denied. Any failed or unverified mandatory test blocked launch. Warehouse revocation initially failed: no-go. After correction and successful retesting, both sites launched.

Recommended handover: train every shift and backup on normal and exception journeys. Retain signed results, configuration versions, accepted limitations, support contacts and a rollback decision owner.

Recommended measures: set local targets and report by site and visitor type. Use the same reporting cohort and review time for each numerator and denominator; multiply ratios by 100 for percentages.

Exclude legitimate ongoing visits from both parts of the overdue-closure measure. Establish expected end times; report missing times separately. A delivered notification is not host acknowledgement. Show missing measurements and use “not applicable” for zero denominators.

Review exceptions daily and trends monthly, assigning corrective actions. Schedule device maintenance, permission reviews, retention checks and recovery drills. Repeat affected acceptance tests after material changes.