Visitor management
For the helpdesk teamVisitor management
Section titled “Visitor management”Two screens, one workflow.
Visitors index
Section titled “Visitors index”Reception’s daily surface. Shows everyone currently on-site (signed in but not yet signed out), plus the most recent sign-outs and any flagged matches against the banned-list.
When a visitor signs in at the kiosk, their row appears here within a second. If the soft-match query against the banned-list hits, the row carries a BANNED MATCH chip. Reception staff are trained to escalate immediately to the DSL; the visitor is not automatically refused entry — the chip is a flag for a human decision.
Banned-list matches also write a tamper-signed audit row tagged safeguarding,visitor-match. The DSL can pull these via the audit log.
Managing the banned list
Section titled “Managing the banned list”The same screen has a banned-list management section (requires the estates::admin permission — typically the DSL or premises lead). Entries take name, optional aliases, optional date-of-birth, and a reason. The soft-match is name + DOB when DOB is present, name only when DOB is absent.
Add an entry when you have specific safeguarding intelligence — a court order, an exclusion, a known disqualified individual. Don’t pre-emptively ban based on rumour. The audit log records who added each entry and when.
Invitations
Section titled “Invitations”Creating and managing invitations requires the estates::admin permission. Schools create invitations for expected visitors — parents for an evening, a contractor for next Tuesday morning, a guest speaker for assembly. Each invitation:
- Has a recipient email (the contractor/parent).
- A valid-from and valid-until window.
- Carries an invitation token (QR + link).
The invitation is emailed to the recipient. On arrival, they scan the QR or visit the link — this opens the kiosk pre-filled with their details and a one-tap Confirm and enter. Faster than retyping name, host, reason.
The invitations index shows pending, used, and expired invitations across the trust. Useful for “did Mr Patel show up yesterday?”
Gotchas
Section titled “Gotchas”- Banned-list soft-match is fuzzy on names — case-insensitive and ignores accents but is not a full phonetic match. Tracey and Tracy both match. McEwan and Mcewen match. Two genuinely different people with similar names will collide — that’s the trade-off vs. missing a match entirely.
- Invitations are scoped to a single school. A trust-wide event needs one invitation per school.
- The kiosk URL contains the school’s
kiosk_token— treat it as a credential, even though it’s public. If a tablet is lost, rotate the token.