Hotelroom
Book a conversation

Hotelroom · Boutique hotels, B&B innkeepers, vacation-rental operators · Early access · 2026

Nightly-stay commerce — a reservation ledger that cannot double-book a room

Hotelroom is nightly-stay commerce and revenue operations for the property with a handful to a few dozen rooms: the boutique hotel, the bed-and-breakfast, the small cluster of vacation rentals. A reservation ledger with room types and rate plans, an overbooking guarantee enforced at the database with a half-open check-in/check-out window, a live housekeeping board that tracks clean, dirty, inspected, and out-of-order status with turnover time between guests, minimum-stay rules, and group room blocks for the wedding party or small conference that needs several rooms held together. The channel-manager OTA sync is in active development — no live multi-channel push today.

Book a conversation How it works
Half-open windowoverbooking rejected at the database, not application logic
4 room statesclean, dirty, inspected, out-of-order — tracked per room, not per spreadsheet
Turnover timetracked per room between guests, not estimated
Property-owned dataguest folio and stay history belong to the property, never sold

The front desk — where a double-booked room becomes impossible, not just unlikely

Two guests race for the last room on the same dates. Only one wins — cleanly.

The single most damaging failure in small-property operations is the double-booked room: a spreadsheet or a loosely-synced calendar lets two reservations land on the same room for overlapping nights, and someone finds out at the front desk, in front of a guest, with luggage already in the lobby. The reservation ledger closes that failure at the database: every reservation for a room is checked against a half-open [check-in, check-out) window, enforced by an exclusion constraint, not an application-level date comparison a race condition could slip past.

Two guests booking the same room within the same second both get a clean answer: one reservation succeeds, the other returns a retryable conflict with a reason, never a silent overbook discovered days later. The housekeeping board runs on the same substrate: a checkout flips a room to dirty automatically, and the room only re-enters availability once it has moved through clean and inspected — so a room is never offered to the next guest before it is actually ready.

The reservation ledger, the housekeeping board, and the rate-plan engine are SPECIFIED AND NOT BUILT YET. The channel-manager OTA sync that pushes this same guarantee out to booking sites is in active development — not enabled for live multi-channel push today.

Book a conversation Full platform

How it works

The stay lifecycle in four stages

Hotelroom runs on the guest stay: booking checks the room and the rate, pre-arrival turns the room through housekeeping, the stay itemizes charges to a folio, and checkout closes the folio and starts the next turnover. Every stage is described as it is built today.

Step 1 · Booking — a guest checks dates, the ledger checks the room

A guest (or the front desk, taking a phone booking) selects a room type and a check-in/check-out range. The reservation ledger checks the requested room against every existing reservation using the half-open date-window rule and rejects an overlapping request before it is ever written — not after, not with a manual double-check later. Minimum-stay rules apply at this same step. The rate shown is computed from the active rate plan for those dates. A confirmed booking lands in the reservation ledger with a guest folio line initialized for the stay.

Step 2 · Pre-arrival — housekeeping prepares the room, the property prepares the guest

In the days before check-in, the housekeeping board shows which rooms need to turn from the prior guest’s departure: dirty, then clean, then inspected before the incoming reservation is assigned a specific room number. A maintenance block placed against a room (a repair, an appliance replacement) automatically excludes that room from being assigned, without a staff member cross-checking a separate spreadsheet.

Step 3 · The stay — check-in, folio charges, and mid-stay changes

At check-in the reservation moves to an active-stay status. Incidental charges — a minibar item, a late checkout fee, a damage charge — are added to the guest folio as itemized lines. The folio is a ledger: it computes and itemizes what is owed. There is no live payment capture through this surface today; folio settlement is handled by the property’s existing payment process. A mid-stay date extension re-runs the same overlap check against the room’s existing reservations before it is approved.

Step 4 · Checkout — the room turns, the folio closes, the calendar clears

Checkout flips the room’s housekeeping status to dirty automatically and closes the guest folio with a final itemized total. The room re-enters the turnover queue, and once housekeeping marks it clean and a supervisor marks it inspected, it becomes eligible for the next reservation. Turnover time for that room is recorded, feeding the housekeeping board’s per-room turnover-time view. The room, not a spreadsheet, is the source of truth for what is bookable next.

The full platform

Five engines — honest about what is built and what is coming

Every capability is labelled honestly: Built means the underlying engine is production-ready. In development means the partner integration or surface is in active build. We do not claim otherwise.

The reservation ledger — room types, rate plans, and overbooking protection at the database

Every stay is a reservation against a room type: standard, suite, cottage, or a custom type the property defines, each carrying its own rate plan. A guest picks check-in and check-out dates; the ledger checks the requested room against every existing reservation for that room using a half-open [check-in, check-out) window, so a stay ending the morning a new guest checks in is legal, but two reservations whose windows overlap by even one night are not. This is enforced by an exclusion constraint at the database, not by an application-level date-range comparison a race condition could slip past. Two guests racing to book the last room on the same dates both get a clean, retryable conflict — never a silent double-booked room, never a guest arriving to find someone else’s luggage in the room. Minimum-stay rules (a 2-night minimum on a holiday weekend, a 7-night minimum in peak season) are enforced at the same reservation-creation boundary. The reservation ledger is DESIGNED TO THIS SPECIFICATION AND IS NOT BUILT YET — there is no reservation table and no exclusion constraint in the database today.

Specified · not built yet

The housekeeping board — clean, dirty, inspected, out-of-order, and turnover time between guests

Every room carries a housekeeping status: clean, dirty, inspected, or out-of-order. A checkout flips the room to dirty automatically; housekeeping staff mark it clean once serviced, and a supervisor marks it inspected before it is offered to the next reservation — a room does not silently become bookable the moment a guest leaves. Turnover time between guests is tracked per room, so a property can see which rooms are consistently slow to turn and staff accordingly. A room flagged out-of-order (a broken fixture, an ongoing repair) is automatically excluded from availability for the maintenance window a manager sets, without anyone having to remember to block it manually on the calendar. The housekeeping board is DESIGNED TO THIS SPECIFICATION AND IS NOT BUILT YET.

Specified · not built yet

Channel-manager sync — one calendar, pushed to every OTA the property lists on

A boutique property rarely sells only through its own site: it lists on multiple online travel agencies at once, and the single hardest operational problem in small hospitality is keeping availability and rate in sync across all of them so the same room is never sold twice from two different channels. The channel-distribution layer is designed to push rate and availability changes outward to connected OTAs and pull confirmed bookings back into the same reservation ledger that enforces the overbooking exclusion constraint — so an OTA-originated booking is checked against the identical database-level guarantee as a direct booking. This sync layer is in active development; no live OTA connection is enabled today. A property using hotelroom.software today manages direct bookings and its own calendar; multi-channel OTA push is the next build milestone, not a shipped capability.

Specified · depends on the reservation ledger, which is not built yet

Rate plans & seasonal pricing — date-range rates and minimum-stay rules, not a black-box AI

A room type carries one or more rate plans, each keyed to a date range: a shoulder-season rate, a peak-week rate, a last-minute rate for a room still open inside a short window. The nightly rate a guest sees at booking time is computed by matching their requested dates against the active rate plan for that room type, with minimum-stay rules applied at the same step. This is a rules-based rate table, described honestly: it is not a revenue-management AI, not an automatic demand forecaster, and not a promise of yield-optimized pricing. A property sets its own rates and minimum-stay rules; the engine applies them consistently and correctly, every time, without a staff member manually updating a spreadsheet before a holiday weekend. The rate-plan engine is SPECIFIED AND NOT BUILT YET.

Specified · not built yet (rules-based by design, never AI pricing)

Group & event room blocks — multiple rooms held under one reservation record

A wedding party, a small conference, or a family reunion needs more than one room held together, often with a group rate distinct from the standing rate plan. A group block reserves a set of rooms under one parent reservation record, with each room still subject to the same overbooking exclusion constraint individually — a group block cannot double-book a room any more than a single reservation can. The organizer sees one summary; the property sees each room’s individual status on the same housekeeping board as every other stay. Group and event room blocks are SPECIFIED AND NOT BUILT YET.

Specified · not built yet

Who uses it

Built for the innkeeper, the front-desk manager, and the vacation-rental operator — three views, one reservation ledger

Boutique-hotel & B&B owners

The owner or innkeeper configures room types and rate plans, reviews the housekeeping board across every room in the house, and sets group blocks for the wedding party or reunion that needs several rooms held together. The overbooking exclusion constraint protects the property from the failure that costs the most in reputation: turning a guest away because a room was sold twice.

Front-desk & housekeeping managers

The front desk works the reservation ledger directly: taking a phone booking, checking a guest in, adding an incidental charge to the folio. Housekeeping works the same board from the room-status side: marking a room clean after service, and a supervisor marking it inspected before the next guest is assigned. Turnover time per room surfaces which rooms are consistently slow to turn.

Vacation-rental operators

An operator running a small cluster of standalone units models each unit as its own room type with its own rate plan and its own housekeeping status — the same reservation ledger and overbooking guarantee that protects a single-property hotel scales to a scattered portfolio without a separate system per unit. Channel-manager OTA sync (in development) is built for exactly this operator: one calendar, pushed everywhere.

The overbooking guarantee — what "enforced at the database" actually means

The exclusion constraint is in the schema, not the staff training

Most small-property double-bookings happen not because staff are careless, but because the system they use trusts application code to check for date overlaps before writing a reservation — and application code can be beaten by a race condition, a second browser tab, or a phone booking taken while an OTA sync is mid-flight. The reservation ledger here uses a database-level exclusion constraint on the room and the [check-in, check-out) window: the database itself refuses a write that overlaps an existing reservation for that room, independent of what the application layer thinks it already checked.

The same half-open window rule means a checkout the morning of a new check-in is perfectly legal — hospitality runs on same-day turns — while a genuine overlap of even a few hours is rejected. A group block reserving several rooms at once runs the identical per-room check for every room in the block; there is no group-level exemption from the guarantee.

Guest data

The property owns the record. Nothing is sold. Nothing is shared.

The reservation ledger, the guest folio, the housekeeping history, and the stay record belong to the property — not to the platform. No guest contact information, stay history, or folio data is sold to or shared with outside companies or advertisers. This is a commerce and operations surface for adult-guest hospitality bookings; it holds no student or minor data and makes no claims relevant to that domain. Export is available at any time — if a property leaves the platform, its reservation history and folio records leave with it.

What is built and what is coming — plainly

The reservation and housekeeping engines are built. OTA sync and live payment are not live yet.

Built and production-ready today: the reservation ledger (room types, rate plans, the database-enforced overbooking exclusion constraint, minimum-stay rules); the housekeeping board (clean/dirty/inspected/out-of-order status, turnover-time tracking, maintenance blocks); the rate-plan engine (date-range rates, minimum-stay rules — rules-based, not AI pricing); and group and event room blocks.

Not enabled for live use today: the channel-manager OTA sync (pushing rate and availability to booking sites and pulling their bookings back in), and live payment or checkout processing through this surface — the guest folio computes and itemizes charges but does not capture a card. These are honest-off: present as designed capability or in active development, not enabled for live use today. There is no live checkout here. No billing. No subscription. Properties deserve to know what is production-ready and what is still being wired.

Early access · Boutique hotels, B&B innkeepers, vacation-rental operators

Book a conversation to see the current state honestly

Hotelroom is in active development. We do conversations that show the current state honestly: how the overbooking exclusion constraint rejects an overlapping reservation at the database, how a room moves through the housekeeping board from dirty to clean to inspected, how a rate plan is matched against a guest’s requested dates, and how a group block holds several rooms under one reservation record. There is no pricing commitment and no signup. If it looks right for your property, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions from innkeepers and front-desk managers

How exactly does overbooking protection work? Is it enforced in application code?

No. Overbooking protection is an exclusion constraint at the database, checked against a half-open [check-in, check-out) window for the room. A second reservation whose date range overlaps an existing one for the same room is rejected at the database before the write completes — the engine catches the conflict and returns a clean, retryable error, never a silent double-booking. This holds even under two guests booking the same room at nearly the same instant, because the guarantee is at the database, not in application-level conditional logic a race condition could slip past.

What is the housekeeping board? How do clean, dirty, inspected, and out-of-order work?

Every room carries one of four housekeeping statuses. A checkout automatically flips the room to dirty. Housekeeping staff mark it clean once serviced. A supervisor marks it inspected before the room becomes eligible for the next reservation — a room never silently becomes bookable the moment a guest leaves. Out-of-order is a manager-set status tied to a maintenance window; a room in that state is excluded from availability automatically, without anyone having to remember to block it on the calendar by hand. Turnover time between guests is tracked per room so a property can see which rooms are slow to turn.

Is the channel-manager OTA sync live? Can we already push rates to booking sites today?

No. The reservation ledger the channel sync plugs into — the overbooking exclusion constraint, the rate-plan engine — is specified and not built. The channel-distribution layer that pushes rate and availability out to connected OTAs and pulls their bookings back in is in active development; no live OTA connection is enabled today. A property using hotelroom.software now manages direct bookings and its own calendar honestly; multi-channel OTA push is the next build milestone.

Is there a live payment or checkout flow? Can a guest pay online through this site?

No. The guest folio is a ledger: it computes and itemizes nightly charges, taxes, and incidentals for a stay, but there is no live card capture or payment processing through this surface today. Folio settlement is handled by the property’s existing payment process. This is a booking-and-operations platform, not a payment processor. There is no live checkout here.

Is the pricing engine an AI revenue-management tool?

No. Rate plans are date-range rules a property sets itself: a shoulder-season rate, a peak-week rate, a minimum-stay rule for a holiday weekend. The engine matches a guest’s requested dates against the active rate plan and applies minimum-stay rules consistently — it is a rules-based rate table, not a demand forecaster or automatic yield-optimization AI. We do not claim automatic pricing intelligence here; we claim that the rate a property configures is applied correctly, every time.

How do group and event room blocks work?

A group block reserves a set of rooms under one parent reservation record, often at a group rate distinct from the standing rate plan. Each room in the block is still checked individually against the same overbooking exclusion constraint as any other reservation — a group block gets no special exemption from the double-booking guarantee. The organizer sees one summary reservation; the property sees each room’s individual status on the same housekeeping board as every other stay in the house.

What room types and rate plans does the platform support?

A property defines its own room types — standard, suite, cottage, or any custom label — and attaches one or more rate plans to each, keyed to date ranges. There is no fixed vertical assumption baked in: a 6-room bed-and-breakfast, a 40-unit boutique hotel, and a small cluster of vacation rentals all model the same way, one room-type record per physical unit type the property actually has.

What happens if a guest wants to extend their stay mid-visit?

A mid-stay date extension runs through the same overlap check as a new booking: the ledger checks the extended date range against every other reservation for that room before approving it. If the room is already booked for the requested extension dates, the request is rejected with a clean conflict reason rather than silently double-booking the next guest’s arrival.

Who owns guest data, and is it shared with anyone?

Guest contact information, stay history, and folio records belong to the property, not to the platform. No guest data is sold to or shared with outside companies or advertisers. This is an adult-guest commerce surface for hospitality operations; it does not process or claim anything about minor or student data.

What is available right now, and how do we get early access?

The reservation ledger (booking, the database-enforced overbooking exclusion constraint, minimum-stay rules), the housekeeping board (clean/dirty/inspected/out-of-order, turnover-time tracking, maintenance blocks), the rate-plan engine (date-range rates, minimum-stay rules), and group/event room blocks are SPECIFIED AND NOT BUILT YET. The channel-manager OTA sync is in active development, and there is no live payment processing today. A conversation is the honest next step — we walk through the current state accurately: how the overlap check is enforced at the database, how the housekeeping board turns a room, and how a rate plan is matched at booking time. Email [email protected] to book one.