Three months ago, a contractor completed renovation work on the 12th floor. The guardhouse logbook shows his name, his IC number, and a check-in time. There is no check-out time. There is no record of whether he acknowledged the building’s renovation rules before entering. There is nothing that distinguishes his entry from the guest who visited the unit next door the same morning.
Now another contractor is at the gate. Different company. Same visitor form.
This is not a guard discipline problem. It is a structural problem: one check-in process, designed for the most common case, being applied to every visitor type that walks through the gate. For guests, that works. For contractors, it leaves gaps that only become visible after something goes wrong.
Contractor Access Management in Strata: Why One Flow Isn’t Enough
Guest, delivery rider, contractor — the categories are familiar but the implications are not treated equally.
A guest visiting a resident is a low-risk, expected arrival. The host knows who is coming. The visit has a natural endpoint. If something goes wrong, the resident is the first accountability point.
A delivery rider needs speed. The record needs to show who arrived, at what time, and for which unit. Anything beyond that is friction without security value.
A contractor is a different problem entirely. They may be accessing a unit without the owner present. They may be working in common areas with no resident to vouch for them. They may be on site for hours — or return across multiple days. Before they enter, a management office needs to know: Has renovation notice been served? Have they acknowledged the building’s permitted hours, noise restrictions, and debris disposal rules? And when they leave — have they actually left?
A single visitor form answers none of these questions correctly for two of the three cases. The guard fills in the same fields regardless. The management office receives the same record regardless. The system treats all three arrivals as equivalent, because it has no concept of purpose.
What Purpose-Specific Workflows Actually Change
The problem with most visitor management setups in residential strata is not the technology. It is the assumption that one workflow is flexible enough to serve every scenario. It is not.
iNeighbour addresses this through a Flow Builder — a system that allows management offices to define distinct visitor workflows per visit purpose. Each purpose triggers only the steps that purpose requires.
A contractor workflow can be configured as: Registration → Management Approval → Acknowledgement of building rules → Check-in → Check-out. The guard cannot complete the check-in until the acknowledgement step is confirmed. The contractor cannot proceed until approval has been granted. Both conditions are enforced by the system — not by a guard remembering the procedure on a busy Saturday morning.
A delivery workflow removes the approval and acknowledgement steps entirely. Registration and check-in happen in one motion. Fast for the rider, complete for the record.
A guest workflow runs on resident-initiated pre-registration. The resident creates the invitation through the app; the guard scans the visitor’s QR code at the gate, and check-in. No guard data entry. No friction for a low-risk arrival.
Each flow is configured once by the management office. Guards follow the steps the system surfaces at the gate — they do not carry different mental checklists for different visitor types. Consistency is built into the workflow, not dependent on the individual on duty.
When a Contractor Returns — and Why It Matters
The second visit is where single-flow systems show their limits most clearly.
When every visitor is an entry in a shared logbook, there is no institutional memory. A contractor who violated renovation hours last month, damaged a common area, or was involved in a security incident is indistinguishable from a first-time arrival. The guard on the next shift has no basis to escalate or refuse without a direct instruction from management — and that instruction is rarely written down in a form the gate can act on.
A purpose-specific system builds visitor profiles across visits. A contractor flagged as a Restricted Visitor carries that tag into every subsequent check-in attempt. The guard sees the flag at the point of access — before the contractor is inside the building — and knows to hold and escalate rather than proceed.
For management offices handling active renovation periods — often five to fifteen simultaneous projects in a mid-size development — this distinction is the difference between reactive incident response and proactive access control.
The data layer extends this further. Visitor records across time surface patterns that manual logs never could — peak contractor activity windows, recurring overstays, and access requests that cluster around specific units in ways worth scrutinizing.