Video summary

Checkin En El Kiosko

Main summary

Key takeaways

Business

Business process: Kiosk-based guest check-in (self-service)

Customer flow

  • Guests arrive at the kiosk located outside the building (inside a fence).
  • Guests have no access to the building until they complete check-in, receive keys, and then proceed through fenced gates to the entrance.
  • After check-in, the route is:
    • Blue fence → blue/orange barrier → building entrance

Operational & security controls

  • Keys are ejected after check-in.
  • If keys are not collected within ~30 seconds, the system retracts the keys back into the kiosk to prevent misuse.
  • If the kiosk is waiting on payment/transaction actions and the customer doesn’t complete within ~1–1.5 minutes, the transaction cancels and the kiosk returns to the previous screen.

Kiosk components & supporting systems (operations/UX)

  • Touchscreen UI (primary data entry)
  • Voice guidance to instruct scanning/steps
  • Document scanner
    • Scans physical IDs/passports
    • Reads MRZ/band characters via the camera/glass
  • POS (payment) terminal
    • Supports chip cards and proximity cards
    • Notes magnetic stripe support (less common)
    • Has its own screen and touch input for entering PIN
  • QR camera / QR ID verification (Spain-only)
    • For Spanish citizens using the official MiDNI app (National Police app)
    • Guests can authenticate by presenting a QR code to the kiosk camera instead of scanning a physical ID card
    • If the app’s QR contains incomplete data (e.g., “simple ID”), the kiosk may still require additional fields due to legal data collection obligations
  • Ticket printer
    • Prints: legal/terms summary, reservation summary, room number, Wi‑Fi code, duplicate key code, and room/key info
  • Intercom/phone module
    • Guests press a button to speak directly with staff
    • The phone is pre-programmed to route calls to the hotel’s main number
  • Ongoing instruction/label updates
    • The team updates “vinyl/instructions” and UI prompts to reduce mistakes
    • Focus includes ID scanning module placement and “how to scan”
    • UI guidance is treated as a process-quality lever because scanning/entry is a frequent failure point

Check-in “playbook” (step-by-step logic)

  1. Start check-in

    • Choose language
    • Buttons: “check-in” and “request new key”

  2. Enter reservation identifier

    • Enter reservation number
      • Internal reservation ID: always works (server lookup guaranteed)
      • OTA locator code from agencies (e.g., Booking.com): may fail if intermediaries change/issue incorrect locators
    • Common issue:
      • Guests booked via intermediate OTAs may receive a locator that doesn’t match what the property can query
      • Guests call reception to get/confirm the correct reservation number

  3. Server lookup

    • The kiosk queries the server and returns reservation summary
      • Example shown: 2 people and a small remaining balance like €0.01
    • If the locator covers multiple rooms, the kiosk asks:
      • which room to start with
      • then which guest details to enter per room

  4. Guest identity + mandatory data capture

    • Choose identity method:
      • Physical ID (typical flow)
      • MiDNI app QR (Spain-only)
    • The kiosk may correct/guide scanning:
      • If scan fails, it guides the user to re-present
      • After repeated failure attempts, it switches to manual entry

  5. Handle minors and relationship fields

    • If a non-adult’s date of birth is entered, the kiosk requires:
      • relationship to the reservation holder
      • (reservation holder must be an adult; minor can be accompanying)
    • Logic/constraint note:
      • For minors, the kiosk makes Spanish DNI optional unless the guest selects providing a DNI/document type
      • If that option is selected, it forces document fields and validation

  6. Address fields & validation rules (Spain / country of residence)

    • Address fields are mandatory due to Ministry of Interior / police requirements
    • If guest declares Spain as country of residence:
      • Province and municipality become select-based, not free-text
    • UX constraints examples:
      • Predictive text requires exact selection/confirmation (e.g., must press accept for “Pinto”)
      • Some municipalities with articles require exact encoded naming (e.g., “Palmas de Gran Canaria”)
    • Validation occurs on data transfer
      • Example: Spanish citizen document format checks for expected ID structure

  7. Terms acceptance + signature

    • Guest must accept terms and sign with finger on the touchscreen
    • Each guest checks in sequentially
    • Kiosk reflects completed status as it moves to the next person

Common failure modes & operational mitigations (quality control)

  • ID scan failures

    • Scanner expects MRZ/band in correct position “in contact with the glass”
    • After repeated failures:
      • prompt to rescan / waiting (first)
      • then fallback to manual entry if still unreadable
    • Team mitigates by improving UI prompts/images to reduce scanning mistakes

  • OTA locator mismatches

    • Locator codes from intermediaries may not work
    • Workflow: reception confirms identity (name/surname/details) and provides the correct reservation number

  • Cancellation/signature bug (organizational bug tracking)

    • If a guest cancels during signature and returns, an extra guest entry may appear
    • Operational note for staff: “new guests keep appearing” could be caused by this behavior

  • Room status / readiness gating

    • Kiosk blocks check-in if room is “dirty” (cleaning ongoing):
      • Displays cleaning will finish at 3 PM (standard check-in time)
      • If early check-in is booked, readiness may be 1 PM
    • Room is considered dirty if the previous guest hasn’t checked out yet
    • Kiosk also blocks if it’s before allowed check-in time

  • Payment interruptions

    • If customer doesn’t complete POS action within about 1–1.5 minutes:
      • transaction cancels
      • kiosk resets

Key “business rules” encoded into the kiosk

  • One key per person by default
  • Duplicate key workflow uses a ticket code
  • Legal compliance
    • Mandatory data fields and validation based on country/status (Spain vs non-Spain; Spanish DNI specifics; minor handling)
  • Time-bound user actions
    • Key pickup window: ~30 seconds
    • POS transaction timeout: ~1–1.5 minutes

Duplicate key request (service recovery / repeatability)

  • Guest taps “request new key”
  • Enters duplicate key code printed on the ticket
  • If the code is invalid:
    • message indicates it’s not the reservation code but the special duplicate code
  • Key issuance is subject to the kiosk’s physical process:
    • may briefly “freeze” on-screen while dispensing
    • then reprints/returns

Metrics / KPIs explicitly mentioned

  • Timeouts / time-to-completion
    • 30 seconds to collect keys before retraction
    • ~1 to 1.5 minutes before payment transaction cancellation
  • Check-in readiness times
    • Standard room readiness: 3:00 PM
    • Early check-in readiness (when booked): 1:00 PM
  • Payment example shown
    • Example reservation displays €0.01 remaining (illustrative; not stated as a KPI target)

Actionable recommendations implied by the video (process/UX improvements)

  • Reduce scanning errors with better instructions and visuals
    • Update kiosk labels and “how to place ID” prompts (especially MRZ alignment)
  • Make OTA locator resolution more robust
    • Given intermediary OTA issues, consider staff/guest support to quickly map the correct reservation ID
  • Strengthen kiosk edge-case handling
    • Fix signature/cancel flow bug that can create extra guest entries
  • Prevent early/dirty-room check-in frustrations
    • Continue showing clear, language-specific top-of-screen messages with exact readiness times (1 PM / 3 PM)

Presenters / sources

  • Presenter: “I” (video speaker; not named in subtitles)
  • Official external source referenced: Spanish National Police (MiDNI / National Police app)

Original video