Complete gids voor een bezoekers­registratie-app

De directe aanleiding voor bezoekers­registratie is bijna altijd veiligheid. Als het alarm afgaat en het gebouw wordt ontruimd, moet de bedrij­fshulp­verlening weten hoeveel mensen er binnen waren en of ze allemaal buiten staan. Medewerkers zijn daarvoor bekend, bezoekers niet, en precies daar zit het gat.

Daaromheen zitten wensen die makkelijker te verkopen zijn maar minder zwaar wegen. Een nettere ontvangst met een scherm in plaats van een schrift. Minder onderbrekingen aan de balie doordat de gastheer automatisch bericht krijgt. Inzicht in wie er vaak komt en van welke leveranciers. Dat is allemaal waardevol, maar het is aanvulling.

Die volgorde is niet academisch. Hij bepaalt welke keuzes u maakt als er iets moet wijken. Een fraai aanmeldscherm dat twee minuten kost, is slechter dan een lelijk scherm dat in tien seconden klaar is, omdat het eerste ertoe leidt dat mensen doorlopen zonder zich te melden. En dan klopt de lijst niet.

Er zijn twee manieren om een bezoeker te registreren, en de meeste organisaties gebruiken ze naast elkaar. Bij de balie meldt de bezoeker zichzelf aan op een scherm of tablet: naam, bedrijf, bij wie hij komt. Dat werkt altijd en vraagt niets vooraf, maar het kost tijd op het moment dat de bezoeker er staat.

Vooraf aanmelden draait dat om. De medewerker die iemand uitnodigt, meldt het bezoek van tevoren aan. De bezoeker krijgt een bericht met de afspraak en soms een code, en hoeft bij aankomst alleen die code te tonen of te scannen. De ontvangst duurt daarmee seconden en de gastheer weet precies wanneer zijn gast er is.

De prijs van vooraf aanmelden is dat medewerkers het moeten doen, en dat gebeurt alleen als het eenvoudiger is dan het niet doen. Een aanmelding die vijf velden vraagt terwijl er al een agenda-afspraak staat, wordt overgeslagen. Koppelen aan de agenda of aan één knop in een bestaand systeem is daarom geen luxe maar de voorwaarde waaronder dit werkt.

• Houd het aanmeldscherm kort. Naam, bedrijf en gastheer volstaan meestal. Elk extra veld kost tijd bij iemand die al binnen staat.
• Maak vooraf aanmelden eenvoudiger dan niet aanmelden. Eén knop vanuit de agenda werkt; een apart portaal met inloggen niet.
• Regel bezoek zonder afspraak. Leveranciers en pakketbezorgers komen onaangekondigd. Zonder route daarvoor lopen ze langs uw systeem heen.
• Denk aan groepen. Twintig mensen die tegelijk voor een bijeenkomst komen, moeten niet twintig keer hetzelfde invullen.
• Houd een papieren terugval achter de hand. Bij storing of stroomuitval moet de lijst alsnog te maken zijn.

Elk bezoekers­registratie­systeem heeft hetzelfde zwakke punt. Aanmelden gebeurt, want de bezoeker moet ergens naar binnen en staat toch al bij de balie. Afmelden gebeurt niet, want iemand die weggaat loopt gewoon naar buiten. Het gevolg is een lijst die na een week vol staat met mensen die allang thuis zijn.

Er zijn een paar manieren om dat op te lossen, geen ervan volledig. Een automatische afmelding aan het eind van de dag houdt de lijst schoon maar helpt niet bij een ontruiming om vier uur. Een poortje dat registreert bij uitgaan werkt wel, maar vraagt hardware. Een herinnering naar de gastheer werkt bij vaste relaties en niet bij eenmalig bezoek.

De meeste organisaties komen uit op een combinatie: automatisch afmelden na een ingestelde tijd, een duidelijke uitche­ckmoge­lijkheid bij de balie, en bij een ontruiming de lijst met een markering van wie waarschijnlijk al weg is. Dat laatste is eerlijker dan doen alsof de lijst klopt, en het is voor de bedrij­fshulp­verlening bruikbaarder.

Een bezoekers­registratie verwerkt persoons­gegevens: naam, bedrijf, aankomsttijd en vaak een telefoonnummer of e-mailadres. Daarvoor hebt u een grondslag nodig onder de AVG, en die is er meestal ook: veiligheid van personen in het gebouw is een gerechtvaardigd belang dat zich goed laat uitleggen.

Wat daarbij hoort is terugh­oudendheid. Vraag niet meer dan u nodig hebt voor dat doel. Een kenteken is nuttig als u een terrein met slagbomen hebt en verder niet. Een kopie van een identi­teitsbewijs is vrijwel nooit nodig en brengt onnodig risico mee. En een foto van de bezoeker vraagt een duidelijker reden dan dat het er professioneel uitziet.

Bewaartermijnen zijn het punt waarop de meeste systemen tekortschieten. Bezoekers­gegevens hebt u nodig zolang iemand in het gebouw is en daarna kort voor incidenten en beveiliging. Weken of maanden bewaren zonder reden is moeilijk te verantwoorden. Leg een termijn vast, laat het systeem automatisch opschonen en controleer of dat ook werkelijk gebeurt.

Zodra er toegan­gspoortjes of elektronische sloten zijn, verandert het project. De registratie kan dan sluitend worden: de bezoeker krijgt een pas die hem binnenlaat, en het moment waarop hij uitgaat wordt vastgelegd door de poort in plaats van door zijn eigen gedrag. Dat lost het uitche­ckprobleem grotendeels op.

De prijs is een koppeling met het toegangs­controle­systeem, en dat zijn vaak gesloten systemen van een installateur. Wat er mogelijk is en tegen welke voorwaarden, verschilt sterk per leverancier. Zoek dat uit voordat u de app laat ontwerpen, want het bepaalt of de koppeling een week of een kwartaal kost.

Een tweede complicatie is een terrein met meerdere gebouwen of afdelingen met eigen regels. Dan is de vraag niet alleen wie er binnen is maar waar precies, en wie waar mag komen. Dat is te bouwen, maar het maakt zowel het model als de bediening zwaarder, en het is zelden nodig in de eerste versie.

Er zijn goede standa­ardpak­ketten voor bezoekers­registratie, vaak met een tablet bij de balie en een abonnement per locatie. Voor een kantoor met een receptie en gewone bezoekers is zo'n pakket vrijwel altijd de verstandigste keuze: het is er morgen en het doet wat het moet doen.

Maatwerk loont als er procedures aan vastzitten die specifiek voor u gelden. Een veilig­heidsi­nstructie die een bezoeker moet doorlopen en aftekenen voordat hij het terrein op mag. Een geheim­houdin­gsverk­laring die per bezoek getekend wordt. Een keuring of certificaat dat een aannemer moet tonen. Dat soort stappen laat zich zelden in een standaardpakket persen.

De tweede reden is koppeling met uw eigen systemen. Als bezoek moet aansluiten op uw agenda, uw leveranciers­administratie of uw toegangs­controle, en als het aantal locaties groeit, dan wordt het abonnement per locatie duur en de beperkingen knellend. Op dat punt kantelt de rekensom richting eigen software.

1. Begin bij de ontrui­mingslijstWie moet die kunnen opvragen, waar en hoe snel. Dat is het doel waaraan alles ondergeschikt is.
2. Bepaal hoe mensen zich aanmeldenBij de balie, vooraf of allebei, en wat er gebeurt bij bezoek zonder afspraak.
3. Los uitchecken zo goed mogelijk opAutomatisch afmelden, een zichtbare uitche­ckmoge­lijkheid en eerlijk markeren wat onzeker is.
4. Leg vast wat u vraagt en waaromZo min mogelijk velden, met een grondslag en een bewaartermijn die u kunt uitleggen.
5. Regel de berichten naar de gastheerZodat de balie niet hoeft te bellen en de bezoeker niet hoeft te wachten.
6. Voeg uw eigen procedures toeVeilig­heidsi­nstructie, verklaring of certificaat, als onderdeel van het aanmelden en niet ernaast.
7. Kijk pas daarna naar poortjesEen koppeling met toegangs­controle is waardevol maar afhankelijk van uw installateur.
8. Test een ontruimingVraag de lijst op tijdens een oefening en kijk of hij bruikbaar is. Dat is de enige echte toets.

Bij een standaardpakket rekent u meestal per locatie per maand, en dat is overzichtelijk. Bij maatwerk zijn er drie factoren. Het aantal eigen procedures dat u inbouwt, want elke instructie of verklaring is een eigen stroom met een eigen scherm. De koppelingen, waarvan toegangs­controle de duurste en meest onvoorspelbare is. En het aantal locaties, omdat meerdere gebouwen het model zwaarder maken.

Daarnaast is er hardware. Een tablet bij de balie, eventueel een pasprinter, en bij poortjes de kaarten zelf. Dat is geen ontwikkelkost maar het hoort in de vergelijking, inclusief wie de tablet oplaadt en vervangt als hij stukgaat.

Wat vaak wordt onderschat is het beheerwerk erna. Medewerkers die weggaan moeten uit het systeem, nieuwe gastheren erin, en de lijst met veelvoorkomende bezoekers vraagt af en toe opschoning. Reken op een kleine maar terugkerende inspanning en wijs iemand aan die hem doet.

Vraag als eerste hoe de ontrui­mingslijst eruitziet en hoe die te krijgen is als er geen stroom en geen netwerk is. Dat klinkt overdreven en het is precies de situatie waarvoor het systeem bestaat. Een goede partij heeft daar een antwoord op, bijvoorbeeld een lijst die op een telefoon lokaal beschikbaar blijft of automatisch naar de bedrij­fshulp­verlening wordt gestuurd.

Vraag daarnaast hoe het systeem omgaat met onzekerheid. Een lijst die stellig beweert dat er veertien bezoekers binnen zijn terwijl de helft allang weg is, brengt de bedrij­fshulp­verlening op het verkeerde been. Een lijst die aangeeft welke registraties waarschijnlijk verouderd zijn, is eerlijker en bruikbaarder.

En laat het aanmeldscherm testen door iemand die er niet aan heeft meegewerkt. Bezoekers zijn ongeoefend, staan soms met een jas en een tas in de hand, en hebben geen zin om te lezen. Als een willekeurige collega het scherm niet in vijftien seconden doorloopt, doet een bezoeker het ook niet.

• Laat de ontrui­mingsroute uittekenen. Hoe komt de lijst bij de bedrij­fshulp­verlening zonder stroom en zonder netwerk.
• Eis eerlijkheid over verouderde registraties. Markeren wat onzeker is, in plaats van een lijst die stelliger is dan de werkelijkheid.
• Test het aanmelden met een buitenstaander. Vijftien seconden, staand, met een tas in de hand. Dat is de werkelijke situatie.
• Vraag naar de koppeling met toegangs­controle. Wat kan er met uw installatie, en wat kost dat. Zoek dat uit voordat u ontwerpt.
• Leg de bewaartermijn vast in het systeem. Automatisch opschonen, niet als procedure die iemand moet uitvoeren.

• Gids: QR-scanner-app
• Gids: reserveringssysteem
• Gids: checklist-app
• Gids: digitale handtekening