Visitor Management: Who Is Inside Right Now?

Visitor Management: Who Is Inside Right Now?

A visitor management system earns its keep in two moments, and neither is the registration desk. The first is when someone walks out still holding a working badge. The second is when the fire alarm sounds and the plant manager needs a headcount — the number of people inside the fence — in under fifteen minutes.

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 last year: 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 the recorded exit tap, or a time limit, whichever comes first. End-of-day deactivation means anyone who leaves at 14:00 carries a working badge for nine 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 — the open area where everyone gathers, which Permen PUPR No. 14/2017 requires to sit at least 20 metres from the building — start logging arrivals. 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. Access-control panels buffer taps locally and hand them over when the link returns, so the data survives while the live screen does not. 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. Nothing gets installed on the panel server; you connect from your own machine and the panel whitelists your IP address.
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 holds a name, a company, a national ID or passport number, sometimes a photo, and a movement history. Under Indonesia's personal data law that is regulated material, and the rules just got specific.

Government Regulation No. 33/2026, the implementing regulation for the 2022 personal data protection law, was enacted on 16 July 2026 and takes effect on 16 January 2027 — six months after enactment, per Article 223. It requires an impact assessment before large-scale or systematic monitoring of personal data (Articles 120–122), sets out when an organisation must appoint a data protection officer (Articles 142–147), and details the administrative sanctions, which reach 2% of annual revenue (Articles 184–185).

Systematic monitoring of movement, at scale, using ID numbers, is a fair description of a factory visitor system. Three practical consequences:

• 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 — one sizing exercise put it near 50 GB without photos and around 250 GB with them — 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. A vendor who says "the system handles that automatically" has not.

The part worth remembering

The registration form is the visible 10% of a visitor system, and it is the part every demo shows you. The other 90% is a badge that turns itself off at the right moment, a count of people that survives a power cut, 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.