Skip to content
LobbyExpress
Search

Guide

Designing the visitor journey

From the invitation to the follow-up, a visit is a chain of small handovers between host, visitor, reception and system. How to map each step, find the friction and fix the weak link most sites ignore: signing out.

By LobbyExpress Editorial

Ask someone to describe their visitor process and they will usually describe the sign-in screen. But a visit starts days earlier, when a host sends an invitation, and it ends some time after the visitor leaves, when their record is finally deleted. Sign-in is one step in the middle.

Each step in between is a handover: from host to visitor, from visitor to reception, from reception to host, and back again. Most of the friction visitors feel, and most of the gaps security teams worry about, sit in those handovers rather than in any one screen.

This guide walks through the journey stage by stage, with the common failure at each point and what to do about it.

Map the journey before you configure it

Write the journey down as a sequence of stages and, under each, who does the work. Seven stages cover most organisations.

The seven stages of a visitA left-to-right journey of seven numbered stages: invite, owned by the host; pre-register, owned by the visitor; arrive, owned by the visitor and reception or kiosk; notify host, owned by the system; on site, owned by the host; sign out, owned by the visitor and reception; and follow up, owned by the system and the data owner. Stages one and two happen before the visit day, stages three to six on the day, and stage seven afterwards.BEFORE THE DAYON THE DAYAFTER1234567InvitePre-registerArriveNotify hostOn siteSign outFollow upHostVisitorVisitor,receptionSystem,hostHostVisitor,receptionSystem,data ownerThe stage most journeys get wrong
Seven stages, each with an owner. The names under each stage are the people to involve when you design it, and to train when it changes.

Two things usually come out of this exercise. First, some stages have no clear owner — most often sign-out and follow-up. Second, the same information gets asked for twice, once in the invitation and again at the desk. Both are fixable once they are written down.

Common friction points and fixesA three-column grid listing six journey stages with a common friction point and a fix for each. Invite: no directions or entrance details; fix with a template including route, entrance and parking. Pre-register: long forms abandoned halfway; ask only what the visit needs. Arrive: visitors cannot find where to sign in; make sign-in visible from the door. Notify host: the host misses the message; add a delegate and reception fallback. Sign out: visitors leave without signing out; put sign-out in the path out. Follow up: records kept indefinitely; delete automatically on schedule.StageCommon frictionFixInviteNo directions or entrance detailsTemplate with route, entrance, parkingPre-registerLong forms, abandoned halfwayAsk only what the visit needsArriveVisitors cannot find where to sign inSign-in visible from the doorNotify hostHost misses the messageDelegate and reception fallbackSign outVisitors leave without signing outPut sign-out in the path outFollow upRecords kept indefinitelyAutomatic deletion on schedule
Six recurring problems, one per stage. Most of the fixes are configuration and wording, not new hardware.

Invite and pre-register

The invitation is the visitor’s first contact with your building. It should tell them where to go, which entrance to use, where to park or how to arrive by public transport, what to bring and who to ask for. If you have accessibility information, include it here, along with a way for the visitor to tell you about any adjustments they need.

Pre-registration moves work out of the lobby. A visitor who has already given their name, company and arrival time can be signed in with a scan or a tap. Contractors can upload insurance and qualifications before they set off rather than at the desk; our guide to contractor management covers what to check.

Resist the temptation to ask for everything in advance. Every extra field is a reason for the visitor not to finish, and every field you collect is data you must protect, justify and eventually delete. Our guide to GDPR and visitor data explains how to decide what is necessary.

Arrival

Arrival is where visitors judge you. They should be able to find the entrance, see where to sign in, and complete sign-in without having to ask how. If they do have to ask, someone should be there to answer.

Walk the route from the car park, the station and the street. Check that signs point to the visitor entrance, not just the building. Make sure the sign-in point is the first thing visible inside the door. If pre-registered visitors can sign in faster — with a code from their invitation, for example — make that route obvious, so they do not queue behind walk-ins. For the hardware side of this stage, see choosing visitor sign-in hardware.

Notify the host — and plan for silence

Most visitor systems tell the host the moment their visitor signs in, by email, text message, a workplace chat app or a phone call. The weak point is not the message; it is what happens when nobody reads it.

Host notification with a fallbackA flow diagram. When the visitor signs in, the host is notified. If the host responds within a time you set, they collect the visitor. If not, a named delegate is notified. If the delegate responds, they collect the visitor. If not, reception is alerted and phones the host’s team, and the visitor is told what is happening.Visitorsigns inNotifyhostNotifydelegateAlertreceptionNo replyNo replyRepliesRepliesHost collectsvisitorDelegate collectsvisitorReception phonesthe teamYou set the wait at each step. Whatever happens, someone tells the visitor what is going on.
The escalation timings are yours to set. What matters is that a visitor never waits indefinitely because one notification went unread.

Let hosts name a delegate — a colleague, a team inbox, an assistant — who is notified if they do not respond. Give reception a live view of visitors who are waiting and for how long, so they can step in. And tell the visitor what is happening: “Your host has been notified; if no one has arrived shortly, please speak to reception” is a small sentence that saves a lot of awkward standing around.

On site

Once collected, the visitor is the host’s responsibility. Hosts should know what that means at your site: whether visitors must be escorted, which areas they may enter, and what to do in an alarm. The visitor should receive the essentials — Wi-Fi details, where the toilets are, what to do if the alarm sounds — without having to ask.

The badge does some of this work, and its design matters more than it seems; see visitor badges: printed, QR, NFC and mobile.

Visitors are diligent about signing in, because they cannot get through the door otherwise. They are much less diligent about signing out, because nothing stops them leaving. The result is a visitor log that says people are still in the building hours after they have gone home — which is exactly the list a fire warden will be holding in an evacuation.

Sign-out methods comparedAn illustrative two-by-two chart of our assessment. The horizontal axis is effort for the visitor, from low to high; the vertical axis is how reliable the resulting record is, from low to high. Automatic sign-out at a fixed time is low effort but low reliability. Returning a card at a turnstile or reader that records it is low effort and high reliability. Scanning a code at the exit and the host signing the visitor out are in the middle. Stopping at a kiosk by the exit is higher effort, with middling reliability unless it is in the path out.ILLUSTRATIVE ASSESSMENTEffort for the visitorReliability of the recordLowHighAIM HERECard back at arecording readerScan code at exitHost signs them outStop at a kioskby the exitAutomatic at afixed time
Our assessment, not measured data. Methods that fit into the act of leaving produce better records. Automatic sign-out keeps the list tidy but tells you nothing about who actually left.

The fixes are mostly about putting sign-out in the path out of the building. A card that has to be returned at a turnstile or reader that records it signs the visitor out as they leave. A code on the badge, scanned at the exit, is nearly as easy. Asking hosts to sign visitors out when they walk them to the door works where escorting is the norm.

Be careful with automatic sign-out at a fixed time. It tidies the list, but it records an assumption, not an event — and in an evacuation, the difference matters. If you use it, make sure your roll-call process treats auto-signed-out visitors as unknown, not safe. Our guide to running an evacuation roll-call covers this in more detail.

Follow-up and the end of the record

The visit is not over when the visitor leaves. Some organisations send a thank-you or a short feedback request; that is optional. What is not optional is the end of the record: the visitor’s data should be deleted or anonymised when your retention period ends, automatically, without anyone having to remember. Check that the system does this, and that it includes photos, ID scans and documents, not just the sign-in line.

Test it by walking it

The best test of a visitor journey is to be a visitor. Ask a colleague from another site, or someone new, to receive an invitation, follow it, arrive, wait, be collected and leave — and to write down every moment they were unsure what to do. Repeat it at different times of day and at each entrance. It is cheap, quick and more revealing than any review of the settings.

Where to go next

To track whether the journey is working over time, see measuring whether your visitor system works, which covers sign-out completeness and host response time. For the bigger picture of what a visitor system is for, start with what a visitor management system actually does, or browse the vendor directory.