Modeling Hotel Room Status as a State Machine

Modeling Hotel Room Status as a State Machine

A hotel room needs more than "available" or "occupied." When I built a hotel management system for a hotel in Pekalongan, the first design decision was to make room status explicit — modeled as a state machine, not a free-text field.

Think of a traffic light. From red, a car can't jump straight to green without passing through yellow. Room status needs the same discipline: it stops housekeeping from prepping a room engineering blocked for repair, front desk from checking a guest into a room that was never inspected, and a "ready" room that's actually mid-cleaning.

A room has several dimensions at once

A real room is not one status. It has independent dimensions:

• Reservation availability — can this room be sold for a date range?
• Physical status — clean, dirty, inspected, maintenance, out of order.
• Operational status — ready for check-in, waiting for inspection, blocked.
• Guest status — checked in, checked out, no-show, extended stay.

The physical/operational dimension benefits most from a state machine, because its transitions have rules that must never be skipped.

The housekeeping state machine

Here is the core housekeeping flow. A room moves through defined states, and each arrow is a transition an authorized action triggers:

The important guard: a room marked OutOfOrder cannot become Ready directly. It has to go back through maintenance clearance and cleaning first. Engineering blocks a room; housekeeping can't accidentally undo that block just by marking it clean.

Why a state machine and not a status field

A free-text or single-enum status invites illegal jumps — someone sets a room to Ready straight from OutOfOrder, or to Occupied while it's still Dirty. Modeling transitions explicitly means the system only allows moves that make operational sense. Everything else gets rejected.

Just as important, every transition is recorded with an actor, timestamp, and reason. That audit trail is what lets the front desk explain, during an incident, why a room changed status or who blocked it. Without it, "the system says it's ready" is an argument, not an answer.

Reservations are a state machine too

The same idea applies to bookings. A reservation is not just "booked." It moves through its own states:

A Held reservation can expire automatically. A Confirmed one can become a NoShow. An active stay can be Extended.

Each transition records who did it and why — exactly what you need when a guest disputes a charge or a cancellation. That short-lived Held state is also part of preventing overbooking.

The takeaway

Room and reservation status are not labels — they are state machines with rules. Modeling them explicitly is the difference between a system that guides the next correct action and one that merely stores whatever someone typed.

This is one piece of a larger system. See the complete hotel management system guide for how it fits together, the Pekalongan case study for the real build, or the hotel management system service if you want one built for your hotel.