Visitor Watchlist Screening
Quietly screen every visitor and contractor against your private do-not-admit watchlist, with fuzzy name matching, a silent alert to security, and a human approval gate before any badge is issued.
A locked-down internal screen that matches each arriving visitor against your watchlist, silently alerts security on a possible hit, and forces a person to approve "deny entry" or "clear false match" before anyone is admitted - every decision logged.
Before you start
- A watchlist you already keep somewhere (a spreadsheet is fine) with names and reasons
- A visitor/contractor check-in feed - a CSV, a Google Sheet, or an export from your visitor tool
- Free Vercel, Supabase, and Resend accounts (the runbook walks you through them)
The problem this kills
Your watchlist lives in someone's head, a locked spreadsheet, or a sticky note at the front desk. A flagged former employee, a banned individual, or a restricted vendor walks up to reception, gives a slightly different spelling of their name, and gets a badge before anyone connects the dots. By the time security hears about it, they're already inside.
Most visitor sign-in tools were built to be welcoming, not careful. They don't quietly cross-check arrivals against a private list, they don't catch "Jon" vs "John" or a maiden name, and they certainly don't make a trained person sign off before the door opens. So the screening either doesn't happen, or it depends on whoever is at the desk remembering a face.
This plan builds the missing screening layer - the discreet check that runs in the background and puts a human in charge of every match.
What you'll build
A small, login-only web app for your security and reception team:
- A private watchlist (name, reason, date added, severity) that only authorized people can ever see.
- A check-in screening feed that takes each arriving visitor and fuzzy-matches the name against the watchlist - catching spelling variants, nicknames, and aliases, not just exact matches.
- A silent alert: a possible match never tips off the visitor. Instead it quietly pings security by email and shows up in a review queue.
- A human approval gate: security reviews each possible match and chooses "deny entry" or "clear false match." No admission decision is ever automatic.
- An immutable log of every match and every decision - who, what, and when - because this is sensitive data and you'll want a clean record.
- A CSV export of screening decisions in the exact columns your existing system or report expects.
What's inside the Implementation Plan
- A discovery interview that runs first. Before it builds anything, the plan has the AI agent interview you about your real setup - how visitors check in today, where your watchlist lives, how names and reasons are written, your typical and peak arrival volumes, your exact deny/clear rules, and your messy edge cases (common names, contractors under a company name, VIPs). It reflects a short tailored spec back to you for a thumbs-up, then builds the tool around your answers instead of a generic template.
- Step-by-step build instructions, each ending in a ready-to-paste prompt for your AI coding agent.
- A data model shaped to your naming and severity conventions.
- Fuzzy/alias matching tuned so you catch variants without drowning in false alarms.
- The full governance layer (login, row-level security, audit log, approval gate, duplicate guards) wired in from the start.
- A "No API yet?" fallback so you can build and use this today from spreadsheets, with a clean CSV export - no integration required.
The governance it includes (this is the point)
This isn't a toy. The plan bakes in the controls a security tool actually needs:
- Login so only your team can open it.
- Row-level security so people only ever see their own organization's data - and the watchlist stays locked to authorized roles.
- A complete audit trail of every match raised and every decision made, time-stamped and attributed.
- A hard human-in-the-loop gate: the tool flags and drafts, a person decides deny or clear, and only then is the outcome committed.
- Duplicate guards so the same visitor and the same watchlist entry can't be processed or double-counted twice.
Who it's for
Physical security teams, reception and front-desk staff, and facilities/security admins who need to screen arrivals against a private do-not-admit list - quietly, consistently, and with a person making every call.
You've got this. Make a folder, start Claude Code, and paste the first prompt.