Visitor Kiosk Customization
Configure branding, legal documents, check-in steps, and confirmation messaging per location. Meeting Room 365 supports two kiosk clients — both sync with the Visitors portal:
| Client | Where you configure |
|---|---|
| Simpler visitor sign-in flow (Meeting Room 365 app on iOS, Android, Fire OS, or a browser) | Primarily the Visitors portal → Kiosks — branding, requirements, splash buttons, notifications, and badge templates |
| Native iPad app (Visitor Check-in Kiosk) | Settings on the device and the Visitors portal — edits sync both ways |
The display key from Admin is required for the simpler visitor sign-in flow and optional on iPad (you can Create New Kiosk in the native app after Microsoft or Google sign-in, or Connect Display Key). Everything visitors see and sign can be edited on the portal; native iPad adds on-device Settings for self-service setup without a browser.
On-device Settings (native iPad app)
The native Visitor Check-in Kiosk app exposes a full Settings area on the lobby iPad. The simpler visitor sign-in flow (Meeting Room 365 app or a browser) does not include this panel — configure those kiosks on the Visitors portal. Typical self-service sections in the native app include:
| Area | Examples |
|---|---|
| Appearance | Logo, brand color, welcome title, fonts |
| Check-in requirements | Visitor rules, NDA, photo, custom fields, per-purpose overrides |
| Splash screen | Sign-in, invite code, QR scan, sign-out, package delivery buttons |
| Guest Wi‑Fi | Show a splash button; SSID and password with QR for visitors to connect |
| Badge printing | Wireless printing toggle, HTML template, label dimensions |
| Notifications | Area channels (contact email, Slack, Teams) for every check-in; separate host email toggle |
| Security | PIN lock, inactivity timeout, security photo |
Edits on the native iPad app sync to the Visitors portal and back. Receptionists who prefer a browser — or who run the simpler visitor sign-in flow on Android, Fire OS, iOS, or in a browser — manage kiosks under Kiosks on visitors.meetingroom365.com.
Branding
| Setting | Where it appears |
|---|---|
| Logo | Kiosk welcome and check-in screens; badge template |
| Email logo | Invitation, pre-check-in, reminder, and notification emails |
| Wallet pass logo | Apple Wallet and Google Wallet passes (compact format) |
| Brand color | Kiosk accents, emails, and wallet pass styling |
| Company / location name | Kiosk header, emails, NDAs ({{company}} variable) |
| Address | Invite and calendar emails; map/location on wallet passes |
| Directions / instructions | Prose entry and building guidance in guest emails — see below |
| Confirmation title & message | Shown on the kiosk after successful check-in (not in the invite email) |
Upload logos directly in the portal or paste HTTPS image URLs.
Visitor directions and instructions
Help guests find your office and get through the door before they arrive. Each kiosk stores a location address and free-text directions / instructions that flow into the emails visitors receive when you invite them.
What to put in directions
Directions are plain-language guidance your visitors read on their phone or laptop — not legal copy (that belongs in visitor rules or NDAs). Typical content:
- Which entrance to use (main lobby, south door, loading dock for deliveries)
- How to enter the building (check in at reception, ring the intercom, use the visitor elevator to floor 4)
- Parking or transit notes (visitor lot on Maple St, validate at front desk)
- Where to go after entry (sign in at the kiosk in the lobby, host will meet you at the security desk)
- Campus or multi-tenant cues (Building C, Suite 200 — look for the Acme sign)
Keep it concise but complete enough that a first-time visitor is not guessing at the curb.
Address vs directions
| Field | Purpose |
|---|---|
| Address | Structured street address for calendar invites, map links, and wallet-pass location relevance |
| Directions / instructions | Narrative steps — "Enter through the glass doors on 2nd Ave, take the elevator to 4, turn left at reception." |
Both can appear in the same invite email. The address helps calendars and maps; directions explain what the map does not.
Where visitors see them
When directions are configured and included on an invite, they appear in:
| Touchpoint | What the guest gets |
|---|---|
| Invitation email | Address and directions in the body, plus invite code and QR |
| Pre-check-in email | Same directions while the guest completes requirements online |
| Reminder email | Directions repeated if paperwork is still outstanding |
| Calendar invite (ICS) | Address as the event location; directions in the event description |
| Apple / Google Wallet pass | Directions field on the pass when configured |
Directions are guest-facing email content — they are not shown on the kiosk splash screen for walk-ins who were not invited (those guests rely on building signage and reception). Walk-in hosts are still captured at check-in.
How to configure
| Surface | Path |
|---|---|
| Visitors portal | Kiosks → your location → Instructions / Directions and Location (Address) |
| Native iPad app | Settings → Visitor Instructions — address, directions, and post-check-in confirmation text |
Set directions once per kiosk / location. When staff send an invite, the portal shows Include directions in invitation email when directions exist on that kiosk — on by default so guests receive them unless you uncheck it for a one-off invite.
See Invites and hosts for the invite workflow.
Check-in requirements
Under each kiosk's Requirements settings, control what visitors must complete — at the kiosk, in the pre-check-in web wizard, or both.
| Requirement | Description |
|---|---|
| Visitor rules | HTML rules visitors acknowledge before proceeding |
| NDA / agreement | HTML or Markdown document with on-screen signature; PDF emailed after signing |
| Photo | Camera capture during sign-in or pre-check-in |
| Custom fields | Extra form fields you define (see below) |
| Additional documents | Secondary agreements beyond the primary NDA |
| File uploads | Optional attachments — prefer attestations and in-person verification; vault encrypts if used |
NDA variables in document text:
| Variable | Replaced with |
|---|---|
{{name}} |
Visitor name |
{{company}} |
Visitor company |
{{date}} |
Visit date |
To disable the signature step entirely, clear the NDA document content.
Branching check-in flows by purpose of visit
Enable purpose of visit on a kiosk and define your purpose labels — for example Interview, Contractor, Vendor delivery, Tour, or Board meeting. When a visitor selects a purpose (at the kiosk or on an invite), the check-in flow branches to that purpose's requirement set instead of the kiosk default.
Each purpose path can be customized independently and completely. You are not limited to turning steps on or off — you can build a different compliance story per visit type on the same tablet.
| What you can set per purpose | Examples |
|---|---|
| Visitor rules | Lobby safety rules for tours; contractor site rules for vendors |
| Primary NDA / agreement | Standard visitor NDA for guests; stricter contractor agreement for vendors |
| Additional document to sign | Second signature step — safety addendum, IP assignment, or site-specific waiver |
| Visitor photo | Headshot for interviews; optional or skipped for quick deliveries |
| Custom form fields | Vehicle plate for deliveries; badge number for contractors; department being visited |
| Photo custom fields | Photo of a contractor license (non-PII), equipment certification, or vehicle placard |
| File uploads | Optional — use sparingly; prefer attestations; vault encrypts if uploads occur |
Global kiosk defaults still apply when no purpose-specific override exists. Purpose-specific settings replace or extend the default path for that branch only.
Example branches
| Purpose | Typical path |
|---|---|
| Interview | Rules → NDA → visitor photo → badge |
| Contractor / vendor | Contractor rules → contractor NDA → second doc (safety) → checkbox attestation (insurance and license submitted or will be submitted for verification) → staff verifies documents at desk → badge |
| Delivery | Rules only → host notification (no NDA) |
| Tour | Rules → group waiver signature → badge |
The same branching logic runs at the kiosk and in the pre-check-in web wizard — contractors can sign documents and acknowledge requirements before they arrive; walk-ins pick a purpose on the splash screen and get the matching path immediately.
Purpose is set on invites (staff choose when pre-registering) and at walk-in check-in (visitor picks from your list). See Invites and hosts and Check-in flows.
Custom fields
Add structured data collection beyond name and host:
| Field type | Use case |
|---|---|
| Text / textarea | Job title, vehicle plate, notes |
| Email / phone | Alternate contact |
| Dropdown / checkbox | Policy acknowledgments, category picks |
| Photo | Contractor license (non-PII), equipment photo, or vehicle image |
Custom fields appear in pre-check-in, kiosk check-in, and visit history. Answers can also print on visitor badges — add {{fields.<field-id>}} (or {{custom.<field-id>}}) to your badge HTML, using the same ID you assign when creating the field. Surface a vehicle plate, contractor badge number, or department on the label without hand-keying data at reception.
Use checkbox or dropdown fields for policy acknowledgments and attestations — often a better fit than collecting documents on the kiosk. See Encrypted document vault below.
Encrypted document vault
The encrypted vault is a safety net — not the centerpiece of your check-in design.
If a visitor incidentally uploads a file that contains personally identifiable information (PII) or other sensitive material, the vault ensures it is handled correctly: encrypted client-side before it reaches Meeting Room 365 servers, decryptable only with your org key. Meeting Room 365 cannot read vault contents after storage.
We do not recommend designing your check-in flow around the collection of PII or identity documents on the kiosk. What you may collect, store, and verify is subject to regulations that depend on your jurisdiction — privacy law, employment screening, contractor compliance, and industry rules vary. Review your flows with qualified counsel and compliance staff before asking guests to submit licenses, insurance certificates, or government IDs through a self-service tablet.
How verification should work
Document verification belongs with a qualified, trained employee — reception, security, or facilities staff who can review originals or trusted copies during check-in or the visit, not an unattended upload step on a lobby kiosk.
A practical pattern many sites use instead of document scanning or file upload steps:
| Instead of… | Consider… |
|---|---|
| Upload COI and contractor license at the kiosk | A checkbox on the check-in form: "I have submitted, or will submit, my insurance and contractor license for verification" |
| Photo of a government ID | Staff verifies ID at the desk; kiosk collects only what regulations allow (for example a non-PII contractor badge number) |
| Vault upload as the primary compliance step | Vault enabled as backup if someone attaches a file anyway — not as the main path |
The kiosk can still capture signatures, rules acknowledgments, visitor photos for badges, and non-PII custom fields appropriate to your lobby. Keep high-assurance document review in human hands.
Enabling the vault (fully self-service)
When you do allow file uploads — or want protection if uploads happen accidentally — enable the vault in the Visitors portal:
- Turn on the vault for your organization in portal settings.
- The portal generates a vault key and prompts you to download a PDF — store this key securely offline.
- Files uploaded during pre-check-in or kiosk check-in are encrypted with that key before storage.
If you lose the key, the encrypted files cannot be recovered. Authorized admins with the key can unlock and review uploads in the portal Vault view.
Kiosk behavior toggles
| Toggle | Effect |
|---|---|
| Allow sign-out from kiosk | Splash-screen sign-out for departing visitors |
| Take photo during sign-in | Master photo capture toggle (also part of requirements) |
| Require approval before sending invitations | Non-admin invites need admin approval |
| Wireless badge printing | Print labels at check-in — see Badges and wallet passes |
| Invite code / QR | Show invite-code entry and QR scanning on welcome screen |
| Directory search at kiosk | Walk-in host lookup from M365 / Google — native iPad app queries the directory on-device with anti-enumeration modes; see Invites and hosts |
| Security photo | Capture photos on the device when visitors interact with configured actions — photos stay on the kiosk tablet and do not leave the device |
| Guest Wi‑Fi details | Splash button with SSID, password, and connect QR — self-service on iPad under Settings → Guest Wi‑Fi; also editable on the Visitors portal |
Some legacy Android or Fire OS kiosk builds may still need support to expose guest Wi‑Fi if the toggle is not visible — email support for same-day help.
Badge template editor
When badge printing is on, pick one of four built-in templates — Classic, Modern, Minimal, or Split — from a visual picker with live preview in the Visitors portal (Kiosks → badge settings). The native iPad app exposes the same presets in Settings.
You can stop at a preset or open the HTML editor to tweak colors, add a logo, drop in custom field placeholders, or paste a fully custom layout. Set label width, height, and content scale for your Brother QL stock. See Badges and wallet passes.
Notifications and integrations
On the Notifications tab in the Visitors portal — or Settings → Notifications on iPad — configure area channels (contact email, Slack webhook, Teams channel email) for a stream of every check-in, toggle host arrival email separately, and set package delivery contacts on their own path. See Notifications.
Localization
Kiosk apps support locale configuration for multi-language lobbies. If a string or language pack gap blocks rollout, contact support — translation overrides are often resolved the same business day.
Advanced support-assisted customization
Some options are not exposed as simple toggles but are routinely configured by support:
- Guest Wi‑Fi splash button with SSID and password (self-service on iPad; portal sync)
- Custom CSS or layout tweaks on legacy kiosk shells
Email [email protected] rather than guessing hidden settings.
Supported / not supported
| Supported | Not supported |
|---|---|
| Full branding: logos, colors, confirmation text | Door-display theme editor (room display product) |
| Visitors portal configuration for simpler visitor sign-in flow (iOS, Android, Fire OS, or browser) | Exchange directory for host autocomplete |
| On-device Settings on native iPad app plus portal sync | Meeting Room TV Chrome extension on visitor displays |
| Guest Wi‑Fi self-service on native iPad app | Webex / in-room video customization on visitor kiosks |
| HTML/Markdown NDAs and visitor rules with variables | |
| Branching check-in flows by purpose of visit — independent rules, NDAs, extra signatures, fields, and uploads per path | |
| Custom fields and per-purpose requirement overrides | |
| Four built-in badge templates plus HTML editor with live preview | |
| Apple / Google wallet branding fields | |
| Microsoft 365 and Google SSO (included) | |
| Kiosk sign-out, invite QR, directory search toggles |
Best fit for
- Brand-conscious enterprises — one visual identity across kiosk, email, badge, and wallet pass
- Varied visit types — purpose-of-visit drives different NDAs and fields
- Compliance teams needing rules, signatures, attestations, and vault-backed handling when sensitive files are uploaded
- IT-light rollouts — native iPad Settings or simpler visitor sign-in flow configured entirely on the portal, with support for vault and legacy Android extras
Frequently asked questions
Where do I edit the kiosk vs create it?
Simpler visitor sign-in flow: create a Visitor Kiosk display in Admin → enter the display key in the Meeting Room 365 app, or use a browser with the display key → customize on the Visitors portal → Kiosks. Native iPad app: sign in in Visitor Check-in Kiosk → Create New Kiosk (or Connect Display Key), then use Settings on the device. Both paths stay in sync with the portal.
What is the difference between the native iPad app and the simpler visitor sign-in flow for customization?
The native iPad app has on-device Settings for branding, requirements, splash buttons, guest Wi‑Fi, badges, and notifications — edits sync with the Visitors portal. The simpler visitor sign-in flow is configured primarily on the portal (no on-device Settings panel); it runs in the Meeting Room 365 app with a visitor display key or in a browser.
Do I have to use the Visitors portal for every setting?
For the simpler visitor sign-in flow, yes — the portal is the primary configuration surface. For the native iPad app, branding, requirements, splash buttons, guest Wi‑Fi, badges, and notifications are self-service in Settings on the tablet (and sync to the portal). You always use the portal for invites, visit history, and receptionist workflows.
Can I use our lawyer's NDA?
Yes. Paste HTML or Markdown into the NDA editor. Meeting Room 365 does not provide legal advice — review content with your counsel.
How do I remove the NDA step?
Clear all text from the NDA document field on the kiosk.
Can different visit types have different check-in steps?
Yes. Enable purpose of visit, then configure each purpose with its own rules, NDA, additional documents, photos, custom fields, and attestations. A contractor path might require a safety document and a checkbox that insurance was submitted for staff verification, while a tour path only shows lobby rules.
Should we collect insurance and licenses on the kiosk?
Generally no as a default design. Regulations depend on your jurisdiction. Prefer a checkbox attestation plus in-person verification by trained staff. Enable the encrypted vault so any incidental uploads are protected — not as a substitute for proper document review.
Can different floors have different rules?
Yes. Each location / kiosk has its own configuration. Licence is per location (which is usually a sign-in tablet).
Is custom CSS available?
Advanced visual tweaks may be support-assisted. Routine branding uses logos, brand color, and badge HTML templates.
What is security photo?
When enabled, the kiosk captures photos when people interact with configured actions (sign-in, package delivery, etc.). Security photos do not leave the device — view them on the kiosk tablet only. They are not uploaded to the Visitors portal or cloud storage.
Related
- Visitor Management overview
- Check-in flows — how requirements run at the kiosk and pre-check-in
- Badges and wallet passes — template variables and printing
- Notifications — email, Slack, Teams, and package settings