Visitor management software records who comes into a building or site, whom they visit, when they enter and leave, and which badge they carry. The short answer: its job is not to digitise the paper logbook but to tell you, at any moment and with certainty, who is inside. Three things make that possible: pre-registration, verification at the entrance, and treating check-out as just as mandatory as check-in.
What does visitor management software do?
A paper visitor book records arrivals but rarely departures. During a fire drill or a real evacuation, security holds a list of who came today, not a list of who is inside now. Handwriting is hard to read, the same person writes their details again on every visit, and finding a past visit means turning pages. Visitor management software solves all three at once: records become searchable, returning visitors are recognised, and the evacuation list is one click away.
- Pre-registration: the host employee enters the guest in advance, and the guest receives an invitation with date and time.
- Check-in: security or reception verifies identity, the privacy notice is acknowledged and a badge number is linked to the visit.
- Notification: when the guest arrives the host gets an instant message or email, so nobody waits in the lobby.
- Check-out: the badge is returned and the exit time recorded; an unreturned badge stays open and is reported at the end of the day.
- Reporting: who is inside right now, visits by date range, a deny list and frequent suppliers.
The core record is the visit, not the visitor
A common mistake is to build the system as a list of visitors. The same person may come dozens of times a year, and every visit has a different host, purpose, badge and duration. The right model is two tables: the person (name, company, phone) is stored once, and each arrival is a separate visit row. The visit row links to the host employee, check-in and check-out times, the badge number and the staff member who registered it. Then a question such as "who from this supplier came last month, and how often" is a single query.
A visitor system without check-out records is useless during an evacuation. Check-out must be designed as a step as mandatory as check-in, and visits left open must be reported automatically at the end of the day.
What information should be collected at check-in?
The rule here is "the least data that does the job". Name, company, the person being visited and a phone number are enough for most businesses. ID numbers, photos or ID card scans should only be requested when there is a real reason, such as a high security area. Every field you collect brings a duty to store and protect it, so show the privacy notice at the entrance, define a retention period and delete or anonymise expired records with a scheduled job. For the web side of the same topic, see our data protection compliant website article. This is not legal advice; agree the retention period with your own legal adviser.
Visitor badges and the live who is inside list
Once the badge number belongs to the visit, two rules apply by themselves: the same badge cannot be used in two visits at once, and a visit cannot close until the badge is returned. If there is a turnstile or access control system, the visitor badge is valid only for that day and only for permitted areas. Employee attendance is a separate topic; for that side, our staff attendance tracking (PDKS) article fits better. The example below shows how the evacuation list and the end of day report come from the same record:
type Visit = {
id: string;
visitorName: string;
hostEmployeeId: string;
checkInAt: Date;
checkOutAt: Date | null;
badgeNo: string | null;
};
// Evacuation list: everyone who is still inside right now.
function stillInside(visits: Visit[]): Visit[] {
return visits.filter((v) => v.checkOutAt === null);
}
// Badges not returned at the end of the day are flagged, not silently closed.
function openAtEndOfDay(visits: Visit[], dayEnd: Date): Visit[] {
return visits.filter((v) => v.checkOutAt === null && v.checkInAt < dayEnd);
}Who should see what?
Reception sees today's list, the security manager searches history, employees see only their own guests, and only an authorised manager edits the deny list. If this separation is not built on roles from the start, either everyone sees everything or nobody can do their job; we explain the approach in user roles and authorisation (RBAC). If invitations require phone verification, SMS OTP verification can be added to the same flow.
Off the shelf product or custom software?
For an office with a single entrance, a ready made tablet product is often enough. Custom development makes more sense when you have several buildings and gates, turnstile integration, separate rules for contractors and suppliers, a safety induction acknowledgement, or a shared user list with your existing HR system. Ask two questions before deciding: how many minutes does it take today to answer who is inside, and which other systems must the visit data talk to?
Conclusion
Good visitor management software treats the visit as the core record, makes check-out mandatory, collects the least data and enforces retention on its own. If you would like to design a visitor and access flow for your site together, see our corporate solutions page or write to us through the get a quote form.