Drie reserveringsmodi, en waarom het er geen één is

Het is verleidelijk om reserveren één keer te modelleren en er daarna vertakkingen aan te hangen. Een restaurant, een verhuur en een afspraak lijken alle drie op iemand die een tijd kiest. Het zijn niet dezelfde problemen, en doen alsof dat wel zo is komt later terug als een prijsregel die niet kan uitdrukken wat de eigenaar bedoelde.

Wat elk van de drie eigenlijk telt

Een restaurant wijst tafels toe op basis van het aantal gasten. Twee gezelschappen krijgen niet dezelfde tafel, en de duur is een beslissing van het huis en niet van de klant.

Verhuur telt nachten tussen twee data, met een minimale en maximale verblijfsduur en check-in- en check-outtijden.

Een afspraak vraagt dat een specifieke persoon vrij is, met buffers tussen de slots zodat de dag niet aan elkaar vast geboekt raakt.

Elke modus krijgt een eigen prijsstrategie in plaats van één gedeelde vol voorwaarden.

De fout die iedereen één keer maakt

Elke modus heeft een resource van het juiste type nodig: een tafel, een eenheid, een persoon. Zonder die resource tekent de kalender zich perfect en biedt hij niets aan. Het is verreweg de meest gemaakte inrichtingsfout, en het ziet eruit als een bug in plaats van als een ontbrekend record.

Een reservering is een reeks stappen

Hij begint als een optie terwijl de gast nog aan het typen is, en beweegt alleen langs overgangen die de engine toestaat: in afwachting wanneer de dienst om jouw akkoord vraagt, wacht op betaling wanneer er een aanbetaling verschuldigd is, en dan bevestigd. Afgerond, geannuleerd en no-show volgen daarna, met vanuit elk daarvan de mogelijkheid tot terugbetaling.