Three booking modes, and why they are not one

It is tempting to model booking once and add branches. A restaurant, a rental and an appointment all look like somebody choosing a time. They are not the same problem, and pretending otherwise shows up later as a pricing rule that cannot express what the owner meant.

What each one actually counts

A restaurant allocates tables from a party size. Two parties do not get the same table, and the duration is a house decision rather than a customer one.

A rental counts nights between two dates, with minimum and maximum stays and check-in and check-out times.

An appointment needs a specific person to be free, with buffers between slots so the day is not booked back to back.

Each mode gets its own pricing strategy rather than a shared one with conditionals in it.

The mistake everyone makes once

Every mode needs a resource of the right kind behind it: a table, a unit, a person. Without one, the calendar draws perfectly and offers nothing. It is the single most common setup mistake, and it looks like a bug rather than a missing record.

A booking is a sequence

It starts as a hold while the guest is still typing, and it moves only along transitions the engine allows: pending when the service asks for your approval, awaiting payment when a deposit is due, then confirmed. Completed, cancelled and no-show follow from there, with refunds available from any of them.