A checklist for switching to unmanned operation

Unmanned operation is not about removing the front desk. It is about reducing the moments when a person must be present. Labour cost scales with hours staffed, and the cost comes from having to cover 24 hours for the few when check-ins cluster. Changing that structure is the goal, which is why sequence matters.

Step 0: list the moments that need a person

Starting with equipment purchases usually fails. First, log every moment a person intervened over a week: check-in, opening a door, an inbound booking call, an amenity request, a payment error, a noise complaint. Attach frequency and time-of-day to each, and it becomes clear which one to automate first for staffed hours to actually drop.

Without that log you end up with equipment installed and staffed hours unchanged. Progress in unmanned operation is measured by the length of the window that needs nobody, not by the number of devices.

Step 1: detach check-in with a kiosk

A kiosk lets guests check themselves in without a front desk attendant. It comes first because the biggest block of required presence sits in the check-in window. On its own, though, it solves only half: if reservation data does not arrive live from the PMS, someone still has to verify on site.

• Is the PMS link live? Same-day bookings and changes must appear on the kiosk immediately.
• Is there a fallback for failed payment or failed ID verification? Without one, every failure summons a person.
• Does it handle foreign languages? If not, the workload just moves to the phone.
• Is the location reachable at night? It has to be designed together with your door-lock policy.

Step 2: smart locks, automating access

IoT connects door locks, lighting and HVAC to your operating system. Locks come first because handing over a physical key keeps the presence requirement intact even after check-in moves to a kiosk. Once access rights are tied to the reservation period automatically, the human touchpoint disappears from check-in through departure.

• Do access rights open and close automatically with the reservation window? Manual issuance is not automation.
• Is there a physical opening method for power or network failure? This is a safety requirement.
• Can you check battery level and offline status remotely? If not, expect night call-outs.
• Do rights expire immediately at checkout? Delayed expiry becomes a security incident.

Step 3: what is left is the talking

Once check-in and access are automated, communication is what remains. Booking questions, directions, amenity requests, change and cancellation queries arrive at scattered hours and are what keeps a person on duty longest. AI phone and text response absorbs those, answers the repeated ones, and escalates only what needs judgement.

What matters here is the handoff rule more than answer quality. Without an explicit scope for the AI and a condition for escalation, ambiguous queries fall between the two. And the exchange must be recorded against the reservation in the PMS so the next shift inherits the context.

Five common mistakes

• Skipping the sequence: adding locks without automating check-in brings the person back to verify reservations.
• Contracting devices and software separately: if kiosks and locks come from a different vendor than the PMS, accountability splits during outages and every spec change costs money.
• Not designing the exception paths: failed payments, failed ID checks and offline locks will happen. What you design is not their absence but what happens when they occur.
• Not keeping records: in unmanned operation, handover exists only as records in the system. Without them you cannot answer a complaint.
• Measuring progress in devices: the metric is the length of the window that needs nobody. If that number does not grow, the transition has not happened.

The transition is not a single event. Redo the step-0 log each quarter and the interventions that survived automation surface. Those are the targets for the next step.