Modeling Hotel Room Status as a State Machine

Modeling Hotel Room Status as a State Machine

In many early hotel systems, a room is simply "available" or "occupied." That is not enough. When I built a hotel management system for a hotel in Pekalongan, the first design decision was to make room status explicit — and to model it as a state machine instead of a free-text field.

This one decision prevents a whole class of operational mistakes: housekeeping preparing a room that engineering blocked for repair, front desk checking in a guest to a room that was never inspected, or a "ready" room that is 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 is the one that 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 must go back through maintenance clearance and cleaning. Engineering blocks a room; housekeeping cannot accidentally undo that block 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 is still Dirty. Modeling transitions explicitly means the system only allows moves that make operational sense, and rejects the rest.

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 — which is exactly what you need when a guest disputes a charge or a cancellation.

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.