Site operations software usually fails in the hand-offs nobody wrote down. The only way we know to find them is to stand where they happen.
Large industrial sites look similar on an org chart: a gate, a guest house, a travel desk, a transport pool, housekeeping, facilities, safety. It is tempting to believe that one template could run all of them. In our experience it cannot, and the reason is not the desks themselves. It is the hand-offs between them, most of which exist only in people’s heads.
Every site has a procedure for receiving a visitor. Very few procedures say what happens when the visitor’s flight is delayed past midnight, the host is on leave, the guest house block is full because of a shutdown, and the security shift changed at ten. Those cases are not rare at a site that runs three shifts, seven days a week. They are the normal week.
The real process lives in workarounds: a security supervisor who keeps a private list of regular contractors, a housekeeping lead who walks the block before shift handover because the register cannot be trusted, a driver who is phoned directly because the pool booking never reaches him. If software ignores these, staff will keep the workarounds and the software becomes one more place to type the same thing.
For Sampark, developers are stationed at the site for 1.5 to 2 months before the build, shadowing real shifts. We are looking for specific things:
None of that can be collected in a requirements workshop held in a conference room in the head office. People describe what should happen. On the night shift, you see what does.
A packaged visitor or guest house product makes reasonable assumptions: one approver, one gate, rooms managed by one team. Industrial sites break these routinely. Facilities may be run by vendor-owners with their own staff and drivers. Access to a plant area may need a safety approval separate from the host’s. A township may have several guest houses in different blocks with different housekeeping contractors.
When software flattens all of that into a template, the site does one of two things. It bends its process to the tool and loses something that mattered, or it keeps the old process alongside the tool and gains nothing. We would rather model vendor-owners, rosters and VIP surges as they actually run.
Shadowing is not a reason to delay value. It shapes what goes first. The first wave is the visitor spine, because it is the flow that fails most visibly: AI intake, gate, rooms, travel, transport and housekeeping. Facilities and fleet come next, with facility tickets carrying SLAs and escalation, vehicle booking, vendor-owners and drivers. Events, catering, safety, health, onboarding and ERP integration follow, then hypercare.
| Stage | What it covers |
|---|---|
| On site first (weeks 1–8) | Shadowing real shifts and mapping hand-offs no SOP captures |
| Wave 1 | AI intake, gate, rooms, travel, transport, housekeeping |
| Wave 2 | Facility tickets with SLAs, vehicle booking, vendor-owners and drivers |
| Waves 3–4 | Events, catering, safety, health, onboarding, ERP integration, hypercare |
If the answers are vague, the software will be generic. For the problems the first wave tackles, see clearing the night queue at the site gate and visitor management for plants, mines and townships, or browse all Sampark guides.
Because the hand-offs that cause delays, such as who tells Security about a late guest, are rarely written in any SOP. Shadowing real shifts finds them.
Developers are stationed at the site for 1.5 to 2 months before the build, then delivery follows in four waves.
The visitor spine: AI intake, gate, rooms, travel, transport and housekeeping, because it is the flow that fails most visibly.
See it on your own data. Sampark — Every desk and guest, one spine. Book a 30-minute working session with an engineer.
