Case study · Active

Building an enterprise visitor management system for Saudi operations

Five roles, one visit. How the data model and the interfaces were separated so a receptionist, a guard, a host and a supervisor could each do their own job from the same record.

Role: Founder · Product · Engineering
Published: 16 August 2026
Reading time: 1 min

Role-based accessArabic / RTLVisitor workflows

Context

Organisations with a controlled site have a front desk that is doing security work while looking like hospitality. The receptionist greets, the guard verifies, the host receives, the supervisor answers for it afterwards. In most places these four jobs share a paper book and a phone.

Problem

The obvious approach — one visitor screen with permissions layered on — fails quickly. The receptionist's task is speed under pressure. The guard's is certainty at a gate. The host's is a notification. The supervisor's is a record after the fact. A single interface serving all four serves none of them well, and the one that suffers most is reception, which is the one that determines whether the system gets used at all.

Constraints

The desk sets the pace: If registering a visitor is slower than writing a name in a book, the book wins. This is not a preference — it is the constraint the whole design answers to.
Arabic and English, equally: The interface has to work in both languages, in both directions, for staff who may work primarily in either.
Guards are not at a desk: Verification happens standing up, outdoors, often in bright light and often quickly. That rules out interfaces that assume a seated user with time.
The record has to survive scrutiny: Presence data gets examined after incidents. It has to be complete and attributable, which constrains what can be edited and by whom.

Approach

I separated the model from the interfaces. One visit object carries the visitor, the host, the type, the vehicle, the pass and the timeline. Each role then gets an interface I designed around its own task, reading and writing the parts of that object it is responsible for. The result is that the roles share truth without sharing a screen.

Architecture

RegistrationReception and self-service entry points creating the visit record.

Visit recordThe shared object — visitor, host, type, vehicle, pass, timeline.

Role interfacesReception, security portal, host notification, supervisor reporting.

Reporting and auditThe durable trail, derived from the record rather than maintained separately.

Solution

Registration flows differ by what is arriving — an individual, a group, a vehicle — because those are genuinely different tasks at a desk. Visitor categories including VIP and client visits carry different handling. Passes with scan indicators give guards a fast verification signal. Blacklist workflows provide a controlled way to bar entry with the reasoning attached. Reporting is derived from the same record rather than compiled separately, which is what keeps it trustworthy.

Why this is a data-modelling problem

The instinct with multi-role software is to start from screens: design the receptionist's view, then the guard's, then the supervisor's. That produces three products that disagree about what a visit is.

Starting from the object instead — what is a visit, what does it carry, what states can it be in — means the interfaces become views over agreed truth. The disagreements surface once, at the model, where they are cheap to resolve.

The thing that nearly always gets skipped

Group arrivals. Every visitor management design handles one person arriving. Then a coach of forty turns up for a site tour and the desk falls back to paper, permanently, because the software made the common exception harder than the workaround.

Lessons

01Role-based UX is a data-modelling decision before it is an interface decision. Get the shared object right and the interfaces become straightforward; get it wrong and no amount of screen design rescues it.
02The busiest minute of the month is the design target. Systems that are pleasant at 11am and unusable at 8am get abandoned, and the abandonment is permanent.
03A visitor category is not a label. VIP and client visits imply different handling, and encoding that in the model prevents staff inventing workarounds.
04Blacklisting is a governance feature, not a technical one. The value is the recorded reason and author, not the block itself.

Stack

What it runs on

Roles: ReceptionSecurityHostSupervisorAdmin
Visit types: IndividualGroupVehicleVIPClient

ShareX LinkedIn Threads

The project

01Aahlan

SYSTEM NOTEBuilding software for receptionists, guards, hosts and admins at the same time FOUNDER NOTEWhat building visitor management software taught me about physical operations

All case studies