Who is on site right now? Start with sign-in.
Who is on site right now sounds like a request for a number. Usually it is a request to trust a list. Visitors arrive through reception, contractors come for a particular job and crews start their day on a project. A useful answer begins with how those arrivals and departures are recorded.
Decide what each list is for
Panora provides a visitor and contractor kiosk for site arrivals, along with crew sign-in for enabled projects. These are related records, but they describe different things. The visitor record captures a visit to a site. The daily crew sheet captures someone signing on to a job for a particular day. Neither should be described as automatic detection of everyone inside the fence.
Start by walking through your entry points. Ask where a visitor reports, where a contractor crew arrives and what happens when someone changes jobs during the day. Agree which record your process expects in each situation. This is a site operating decision. A person can appear in more than one workflow, so simply adding displayed counts is not a reliable way to produce a unique site total.
Name the person responsible for checking the exceptions. A missing company, a departure that was not recorded or an unfamiliar name needs someone to follow up. The purpose of the digital list is to give that person a usable record. It does not remove the need to talk to the host, supervisor or individual when the record is unclear.
Make the visitor's arrival and departure clear
With visitor sign-in enabled, the site's kiosk provides fields for a visitor's name, company, host and mobile number. The site is associated with the record. Someone leaving can use the kiosk's sign-out action, which records a departure time. That makes leaving part of the process as well as arriving, rather than an assumption made at the end of a shift.
The signed-in Visitors page groups today's recorded arrivals by site. Authorized staff can read the name, company, host, arrival time and whether a sign-out was recorded. A missing company or host is shown as not given. Those details give the person reviewing the list a starting point for a question instead of a number with no explanation.
Read On site as the state of the sign-in record: no departure has been entered for that visit. It is not a sensor report or a guarantee of physical presence. Agree how hosts will help visitors complete sign-out, and what staff should do when someone has left without recording it. Include visits that cross a date boundary in your pilot review.
Give the crew the right project entry point
Crew sign-in needs the account capability, an enabled project and a configured project access code. The crew opens the project's page and enters that code before using sign-in. The form asks for a name and company. It also provides sign-off. Crew members do not need a manager account to record their own participation through this configured entry point.
The project page displays daily sign-on and sign-off counts. Those counts are useful for reviewing activity on that job, but a count of people who signed on today is not the same thing as a confirmed current headcount. Before using either count in an operational decision, be clear about the question it answers and how departures are being recorded.
The crew sheet is filed using the site's local day. Authorized staff can choose a date on the Crew sign-in page and review the named records by project. This supports looking back at the day's activity without putting the full crew list on the project entry page. Keep the job and the date in view when discussing a particular record.
A sign-in list describes what was recorded. A reliable site process also checks what may be missing.
Keep access and identity in perspective
The project sign-in panel returns a person's own submitted name and aggregate counts rather than a named roster. The named crew sheet is behind signed-in access for the roles allowed to review it. The visitor kiosk shortens displayed names for the departure list, while authorized staff can inspect the fuller visitor record in the workspace.
These are different access arrangements for different jobs. Include the actual kiosk placement, project code distribution and staff permissions in your setup review. A shared project code enables a field workflow; it is not proof that a typed name belongs to the person holding the phone. Do not treat sign-in alone as verified identity, training approval or permission to perform a task.
Review the records your team needs and the people who should see them. Panora's security and implementation pages provide a starting point for that conversation. Keep the pilot practical: ask a crew member to use the entry page and ask an authorized reviewer to find the resulting record. Confirm both experiences before widening access.
Connect sign-in to the next operational question
A contractor company record and an individual sign-in answer different questions. Company prequalification and expiry information provide background on the organization. A person's arrival records participation at a site or job. A crew signature on a configured permit is another record again. Review the relevant evidence instead of allowing one completed step to imply that every other step is complete.
Emergency accountability is a separate workflow with its own check-in status. Do not assume that a visitor entry or daily project sign-in automatically proves someone reached an assembly point, or that every name on those lists is automatically on an event board. During implementation, walk through who your emergency process expects to account for and where that list comes from.
For the next site review, choose an arrival, a recorded departure and a case where the record is incomplete. Ask what each tells you, what remains unknown and who can resolve it. The same habit applies to any shared tracker: an unanswered question should remain visible. A useful list helps the team investigate uncertainty before a reassuring total hides it.