To prepare a hotel for self check-in, test the whole arrival journey before guests use it. Prove five things with your own bookings, rooms and locks: only an inspected room can be assigned, the guest's identity document matches the booking, payment is taken once and recorded, the issued key opens the assigned room, and a guest who gets stuck can reach a staff member. Give each test a named owner who signs it off, then start with a limited pilot before opening the service to every arrival.

This guide is written for managers, front-office leads and IT teams at hotels and serviced apartments in Saudi Arabia who are planning a self check-in kiosk or reviewing one that is already installed. It is an operational checklist and does not replace the requirements of the competent authorities or the terms of your contract with a supplier.

Define what the first phase covers

Write the scope of phase one on a single page before you test anything.

  • Guests: confirmed bookings only, or walk-in guests as well?
  • Transactions: check-in only, or also new bookings, stay extensions, cancellations and check-out?
  • Payment: is payment taken at the kiosk, and for which kinds of booking?
  • Rooms: all room types, or a group of rooms your team can monitor closely?
  • Hours: which hours have a staff member nearby, and what happens outside them?

Agree the acceptance scenarios with your supplier in writing. Each scenario should say what the guest does, what each system records, and what counts as a pass. Keep cases that need a human decision, such as a booking that does not match the guest's document, on a clear path to a staff member.

The five readiness tests at a glance

Each test below has one pass condition and one sign-off owner. Where the table gives two roles, choose one. Do not go live while any row is unsigned.

Self check-in readiness tests, pass conditions and owners
TestPass whenSign-off owner
1. Room readinessA room that has not been inspected cannot receive a guest or a keyFront-office manager, with the housekeeping lead
2. Identity and bookingA document that does not match the booking is routed to staff, not to a keyFront-office manager
3. PaymentThe amount due is correct, charged once, and the same in the provider's record and the hotel's recordFinance or night audit
4. Room keyThe issued key opens the assigned room and the shared doors the guest needs, and no other guest room, for the dates of the stay onlyEngineering or IT
5. Guest helpA guest who is stuck reaches a person who can finish the caseDuty manager

Test 1: Room readiness

A room that is free to sell is not always a room that is ready to enter. At a kiosk there is no receptionist to notice the difference, so the room status in your hotel management system has to be trustworthy on its own.

  • Separate "cleaned" from "inspected and ready", and name who is allowed to set each status.
  • Try to check in to a room that is still marked as not ready or out of service. The journey should stop or offer another room, and it should never issue a key.
  • Try a room whose previous guest has not checked out or has a late check-out. It must not be assigned.
  • Test an early arrival, when the booking is valid but no room of that type is ready yet.
  • Test a room move made by staff a few minutes earlier, and confirm that the kiosk shows the new room.
  • Test a booking with more than one room, and confirm that each room is checked separately.

Repeat this test after any change to how housekeeping or maintenance updates room status. Repeat Test 4 after any change to locks or key cards.

Test 2: Identity and booking match

This test confirms that the document presented matches the booking, that the person presenting it is its holder, and that the details your property must record are captured correctly. Use the document types your guests actually carry, such as national identity cards, residence permits and passports.

  • Document holder: decide how the holder is checked against the document, by the kiosk or by a staff member, and test with a document that belongs to someone else.
  • Name mismatch: a booking made in English and a document in Arabic can spell the same name in different ways. Decide what counts as a match and when a staff member must confirm it.
  • Unreadable or expired document: the guest should see a clear message and a way to ask for help. The journey should not continue to payment or key issue.
  • Booking made by someone else: a company or a relative booked the stay. Decide which details the arriving guest must provide.
  • Booking state: a booking that is already checked in, cancelled or dated for another day, including an arrival after midnight, is not checked in a second time and is routed to staff.
  • Companions: if companions must be registered, test a booking with two or more guests and check every record.
  • End of session: confirm that no guest data stays on the screen when the guest finishes or walks away.

Guest registration and reporting requirements are set by the competent authorities. Confirm the current requirements with the authority and with your supplier before launch. Where data is sent to an official platform, treat "sent" and "accepted" as two separate checks, and name the person who follows up a rejection.

Test 3: Payment

Run this test with test transactions approved by your payment provider or supplier, not with real guest cards.

  • Compare the amount on the kiosk with the amount in the hotel system for a prepaid booking, a partly paid booking and a booking to be paid on arrival.
  • Use a test card that will be declined, and confirm that the booking stays unchanged and that the guest can try again or ask for help.
  • Interrupt a payment before the result appears. Before anyone retries, find the transaction reference and confirm whether the charge went through.
  • Confirm that every successful payment appears against the correct booking, with its reference, in the hotel's records.
  • If you take a deposit or a pre-authorisation, test that it is held and released correctly.
  • Check the receipt or invoice the guest receives against the booking.
  • If your scope includes cancellations or refunds, test them against your written cancellation policy.

A success message on the screen is not proof on its own. The proof is the same result in the payment provider's record and in the hotel's record. Before launch, repeat one payment and one refund from start to finish with a card that belongs to the hotel, if your provider allows it.

Test 4: Room key

Issue a key at the kiosk, walk to the room and open the door. Do not accept a key issued at a demo desk as proof. The test ends at the door.

  • Confirm that the key opens the assigned room and does not open the room next to it.
  • Confirm that it opens the shared doors on the guest's route, such as the entrance, lift or parking, if they are card-controlled.
  • Confirm that the key works from the start of the stay and expires at the end of it. Ask your lock supplier what cancels a key after an early check-out, and test that case.
  • Issue a second key for a companion, if your scope includes it, and test both keys.
  • After a room move or a stay extension, confirm that the key matches the new room or the new dates and that the old key no longer opens the old room.
  • Replace a lost key and confirm that the earlier key is cancelled.
  • Let the key stock run out, or interrupt key issue, and confirm that the guest sees a clear message and that staff are alerted.

Compatibility is established by testing your actual lock model and your actual key cards. A familiar brand name on the lock is not evidence that key issue will work with a specific kiosk.

Test 5: The guest-help path

For each situation below, agree what the guest sees, who acts, and what must be checked before the step is repeated. Then rehearse it with the staff who will be on shift.

Escalation examples to rehearse before go-live
SituationWho actsCheck before retrying
Booking not foundFront-desk agent checks the reference and the booking channelNo second booking is created during the search
Document cannot be readAgent completes verification using the property's manual procedureThe details recorded match the document
Payment result unclearSupervisor or finance reviews the transaction referenceProvider record and hotel record agree before any new charge
Room not readyFront-desk agent or duty manager offers the available optionsNo key was issued for the room that is not ready
Key not issued or does not open the doorAn authorised staff member completes the caseRoom number and stay status are correct, and no fee is repeated
Kiosk or network unavailableFront desk switches to the fallback check-in procedureThe status of the interrupted transaction is settled first

Put short help instructions beside the kiosk in Arabic and English, and tell guests how to reach a staff member at any hour the kiosk is in use. Set your own response-time target and measure it during the pilot. Keep document images and payment details out of general staff chat groups.

Run a limited pilot and measure it

Start with a scope your team can watch closely, such as a set period or a group of suitable bookings. Record every journey in one sheet, and do not publish a speed promise before you know the real figures for your property.

  • Completion: journeys completed out of journeys started.
  • Assistance: where a staff member stepped in, why, and how long the guest waited, with usage questions separated from technical faults.
  • Time: a defined start and end point, with the longest cases and their causes shown beside the average.
  • Mismatches: cases where booking, payment or room data differed between systems.
  • Guest feedback: one short question about how clear the steps and the help were.

Review the results with operations, IT and the supplier. Fix the repeated causes, test the affected cases again, and widen the scope only after the results are stable.

Go-live checklist

  1. The phase-one scope is written and agreed with the supplier.
  2. All five tests are signed off by their owners, with recorded results.
  3. Keys are tested on real doors, including a room move and a check-out.
  4. Every shift has rehearsed the escalation cases.
  5. A fallback check-in procedure exists for kiosk or network downtime.
  6. The current requirements are confirmed with the competent authority and the supplier.
  7. Pilot measures and a review date are set.

Common questions

Does self check-in remove the need for front-desk staff?

No. It moves routine arrivals to the kiosk and leaves staff free for exceptions, questions and guests who prefer a person.

Do we have to replace our door locks?

Not necessarily. It depends on whether the kiosk can issue keys for the lock system you already use. Ask the supplier to prove it on your own doors with your own key cards before you decide.

How long does preparation take?

It depends on your scope, the systems that must be connected and the results of the tests above. Set the launch date after the tests pass, not before.

Turn the checklist into a demo for your property

Bring this checklist to any supplier demonstration and ask to see each test performed, not described. City2Day provides a self check-in kiosk for hotels and a hotel management system. As its product page describes, the kiosk lets guests complete booking, check-in, payment, room-key collection, stay extension and check-out, with an Arabic and English interface, voice guidance, and passport and ID scanning. Whether it works with your current hotel system and door locks has to be established by on-site testing on your own doors, as in Test 4.

Request a live demo and share your phase-one scope, so the session covers your own bookings, rooms and exceptions. An Arabic guide on the same topic is also available: تجهيز الفندق للتسكين الذاتي: قائمة تشغيل واختبار.

Sources and useful links