Visitor Management: Who Is Inside Right Now?

A visitor management system records arrivals, permitted areas, and when access ends. Two important situations are badges that remain active after departure and accounting for people during evacuation. Access records provide an initial list; staff must reconcile it at the assembly point because people can leave through emergency exits or while devices are offline.

What does a visitor system actually have to do?

Four jobs, and printing a badge is the smallest of them.

Check identity at the gate. Hand out a card that opens the right doors and nothing else. Keep a live list of who is inside. Leave a record an auditor can read a year later.

A food-and-beverage plant in an industrial estate put its requirements into a formal specification document: 39 numbered requirements for visitor handling, and 64 for emergency evacuation. The emergency section was larger than the visitor section. Read that ratio twice, because it is the honest picture of where the risk sits. Registering a guest is a form. Knowing who is still inside a burning building is a system.

Most sites already own half the hardware. There is a turnstile at the main office — the waist-high rotating barrier that lets one person through per valid card — and an access-control panel behind it. What is missing is the layer that treats a visit as something with a beginning, a middle, and an end.

Why a guest badge needs a life cycle, not an on/off switch

Guest cards get reused. The same plastic card goes to a different person next week, which means the card is not the identity — the visit is. Model the visit as a sequence of states, each with one rule for moving to the next.

Three details in that diagram cost real money when they are wrong.

The card stays active across repeated entries and exits. A guest steps out for a phone call and comes back. If the card dies on the first exit tap, the guard post becomes a queue and the guards start propping doors open, which ends the security model faster than any attacker would.

Deactivation is not "end of day". The trigger is confirmed final checkout, or a time limit, whichever comes first. A temporary exit tap records a movement without ending the visit. If cards only expire at 22:00, a visitor who leaves at 14:00 carries a working badge for eight hours.

The card comes back where it was issued. If check-in happens at a guard post outside the turnstile, check-out has to happen there too. Physical layout decides the software rule, not the other way round. Get this backwards and you design a check-out counter that sits on the wrong side of a barrier the guest can no longer pass.

Then there is the category every design forgets: truck drivers, couriers, and the second and third person in a car. They do not pre-register, they arrive at a different gate, and they are inside the fence during an evacuation exactly like everyone else. Decide their flow explicitly or the guards will invent one.

Who approves a visit — and who decides which doors?

These are two separate decisions, and merging them is the most common design error in this category.

Approval answers "is this person allowed to come today". It belongs to the host — the employee being visited — and it usually lives in whatever pre- registration web form the company already runs, often built by a different vendor. Access rights answer "which readers will accept this card". That belongs to the access-control panel and to a visitor category agreed with security: contractor, auditor, driver, interviewee.

Keep the host's phone number and email in the employee master data, not in a field the guard types at the desk. A guard typing a host's mobile number at 07:40 will get it wrong often enough to matter, and that number is what the system uses to notify the host that their guest is waiting.

For the integration with a pre-registration site that someone else owns, ask for both directions:

• A webhook — the other system calling yours the moment a visit is approved — so the guard post sees today's list without waiting.
• A periodic pull over an API, running every few minutes, to catch the events the webhook dropped while your server was restarting.

One without the other is a design that works in the demo. Webhooks get lost; polling alone is slow. This is the same reconciliation discipline as any other event integration, and I covered the mechanics of getting events in and out of closed security products in integrating access control and VMS with your own systems.

Two more policies to settle in writing before development starts. Whether walk-in visitors exist at all — "everyone must pre-register" is a legitimate answer, but it is a business decision with a guard-post consequence, not a feature toggle. And how a temporary block works: a blacklist entry that never expires will eventually block a contractor everyone has forgotten about, so give every block an end date and an owner.

What happens when the fire alarm goes off?

This is where visitor management stops being a front-desk product.

When the fire panel triggers, four things have to happen without anyone remembering to do them. New check-ins freeze, so the inside-count stops moving. The dashboard switches to evacuation view. Readers at the assembly points — a safe location designated by the site safety team in the evacuation plan — start logging arrivals. Distance and capacity depend on site risks and applicable safety rules; this evacuation overview is an introduction rather than a site assessment. And someone gets a printable list of the people not yet accounted for.

The hard part is not the dashboard. It is defining the expected number.

"Who is inside" sounds obvious until you write the query. Is an employee inside because they tapped in this morning and never tapped out? What about the passenger in a car who never tapped anything? What about the visitor who tapped out at the turnstile but never returned their card at the post? Each answer is a policy, each policy has to be agreed with the safety team, and the number on the evacuation screen is only as honest as those definitions. Pick one rule and write it on the wall: at one plant the agreed rule was tapped in, not yet tapped out, with car passengers required to register themselves at the gate.

Two engineering rules make the difference between a screen that helps and one that hurts.

Assembly-point readers log, they never block. During an evacuation a reader that rejects a card is an obstacle in a crowd. The reader records the tap and opens nothing.

Say out loud what happens when the network dies. A fire that takes out a switch also takes out your live count. Some access-control panels buffer taps locally and send them when the link returns. Verify buffer capacity and persistence through both network and power loss; the live screen may be stale even when events can later be recovered. That gap belongs in the specification and in the drill procedure, with a manual roll call as the documented fallback — not discovered at 03:00 by a shift supervisor holding a dead tablet.

Drills need the same care. A scheduled drill produces the same taps and the same reports as a real event, so label the records as a drill at the moment it starts. Timestamps are the evidence base for everything that happened, which is why clock discipline across panels, cameras, and servers matters more than it looks — see when timestamps stop being evidence.

How do guest cards actually get switched on and off?

Three paths, in order of preference, and this order holds for most access-control platforms sold in Indonesia.

1. The vendor's official command channel over the network. EntryPass P1, common across factories and estates here, exposes one over XML-on-TCP for activating and deactivating a card, plus a separate stream that pushes access events out in real time. The xSocket module must be purchased and installed on P1 Professional. Your integration client can run on a separate machine, using the configured network access controls.
2. The official file import. The panel watches a folder and picks up drop files every few seconds. Slower, less elegant, but it is supported and it needs no extra licence.
3. Writing to the panel database directly. Emergency only, panel stopped first. Treat it as data recovery, not as an integration.

The trap sits in path one: that command channel is usually a paid add-on, not part of the base install. I have watched this turn into a scope argument more than once, because everyone assumed the licence was already there. Verify the licence before the proposal, not during commissioning.

The same plumbing solves a different problem for estate managers. One industrial estate wanted lift access cut off for units past due on their service charge and restored within five minutes of a confirmed payment. The integration was three weeks of work. The policy questions took longer: does a partial payment restore access, does the block hit every card in the unit or just one, how long is the grace period, who holds a permanent exemption, and how many weeks of notice come before the first block is switched on. Write those answers into the kick-off document. They are the project.

Where visitor data turns into a legal problem

A visitor record may contain a name, company, identity number, photo, or movement history. Treat these as personal data. UU 27/2022 addresses impact assessments for high-risk processing (Article 34), conditions for appointing a data protection officer (Article 53), and administrative sanctions (Article 57). Determine the assessment and officer requirements from the actual processing and its scale, rather than automatically from the label “visitor system”.

A commentary on PP 33/2026 previously informed this article. Its official text and effective date have not been verified in this update. Use the available PDP statute as the starting point and have legal counsel check the latest implementing rules before setting compliance deadlines.

Three design decisions you can make now:

• Collect the minimum. An ID number verified at the post does not have to be stored in full. Decide what the audit actually needs.
• Set a retention period and enforce it in code. Seven years of visit logs at a large plant is a modest database — its size depends on visit volume, record detail, and photos retained — and every row of it is personal data sitting there by default.
• Decide about photos deliberately. A webcam capture at check-in is easy to add and hard to justify later. At least one plant I worked with dropped it during design review.

Our piece on the 2026 changes to personal data fines covers the penalty side in more depth.

Questions to ask before you sign

1. When exactly does a guest card get deactivated — on the exit tap, on a time limit, or at end of day?
2. Can a guest enter and exit repeatedly on one card without a guard intervening?
3. Where is the card physically returned, and is that point inside or outside the barrier?
4. What is the agreed definition of "currently inside", for employees, visitors, and car passengers?
5. Does the evacuation screen keep working when the network drops, and what is the documented fallback?
6. Do assembly-point readers ever refuse a card?
7. Which licence does the access-control integration require, and who is buying it?
8. How do truck drivers and couriers get registered?
9. What is the retention period for visitor records, and who deletes them?
10. Can a drill be labelled as a drill in the reports?

A vendor who answers 1, 4, and 7 with specifics has built one of these before. Ask a vendor who says "the system handles that automatically" to demonstrate the behavior under failures, rather than accepting the statement alone.

The part worth remembering

As an illustration, the registration form is the visible 10% of a visitor system. The other 90% is a badge that turns itself off at the right moment, an initial evacuation list backed by tested power/network behavior and a manual muster count, and a set of policies written down before anyone opens an editor.

Ask any vendor who is inside the building right now. If the answer needs a phone call to the guard post, the system is a logbook with a screen.