Soggiorno minimo e chiusure in arrivo: le regole che decidono se una data è prenotabile
Una stagione è una sola decisione commerciale — "agosto è 140, minimo tre notti, nessun arrivo il sabato" — ma per il software sono due domande diverse. Quanto costa questo soggiorno, e si può accettare?
Prezzo e permesso sono due domande distinte
Chi gestisce uno spazio ragiona per stagioni: agosto è 140 a notte, minimo tre notti, nessun arrivo il sabato. Per lui è una decisione sola. Per il software sono due domande, poste in momenti diversi da chiamanti diversi.
Il prezzo si chiede quando qualcuno è quasi deciso. Il permesso — questo soggiorno può esistere? — deve essere rispondibile prima che nessuno abbia accettato di pagare niente, perché è l'endpoint di disponibilità a doverlo sapere per decidere se disegnare una data come prenotabile.
Le due risposte devono leggere le stesse righe di regola. Se si separano in tabelle diverse, prima o poi qualcuno cambierà il prezzo di agosto e lascerà indietro il minimo di agosto.
Le tariffe si risolvono notte per notte
Un soggiorno che inizia in bassa stagione e finisce in alta non ha "una tariffa". Ogni notte paga la tariffa della regola che la copre, e il totale è la loro somma.
Sembra ovvio e viene sbagliato di continuo, perché una tariffa unica per soggiorno è molto più comoda da salvare. L'errore è invisibile: nessun messaggio, nessun reclamo, solo un totale silenziosamente sbagliato su ogni prenotazione a cavallo di un confine — nella direzione che l'implementazione ha scelto senza dirlo.
Quando più regole potrebbero coprire la stessa notte, la precedenza deve essere deterministica e non quella che il database restituisce per prima. In Boris una regola su una stanza specifica batte il default dello spazio, e fra due regole dello stesso livello vince la data di inizio più recente.
Le restrizioni appartengono alla notte di arrivo
Notti minime e massime e le chiusure in arrivo si giudicano sulla regola che copre la notte in cui il soggiorno inizia. È la convenzione che seguono tutti i channel manager, e non è una scelta arbitraria.
Si veda l'alternativa. Se il minimo valesse per ogni regola toccata dal soggiorno, un ospite che arriva il 30 luglio per quattro notti verrebbe rifiutato perché il soggiorno sfiora una regola di agosto che chiede tre notti: un soggiorno di quattro notti rifiutato perché troppo corto. Controllare ogni notte trasforma una soglia in una trappola.
La chiusura in partenza è l'eccezione, ed è il dettaglio che quasi tutti dimenticano: la data di partenza non è una notte del soggiorno. La regola della notte di arrivo può non estendersi fino a quel punto del calendario, quindi serve una lettura propria. Chi la ripiega sulla regola di arrivo ottiene un bug che compare solo sui soggiorni lunghi, cioè le prenotazioni che meno conviene sbagliare.
Zero non è un limite
Un dettaglio piccolo con conseguenze grandi: in una colonna "notti minime" che ammette NULL compariranno sia NULL sia 0, e significano entrambi "nessun limite". Un sistema che prende lo 0 salvato per un minimo reale confronterà ogni soggiorno con esso e non rifiuterà nulla — oppure, se il confronto è scritto al contrario, rifiuterà tutto. Si normalizza una volta, in lettura, non in ogni chiamante.
Rifiutare al checkout è un fallimento, non una tutela
Una restrizione applicata solo all'invio della prenotazione è comunque corretta e comunque una brutta esperienza. L'ospite ha scelto le date, inserito i dati, raggiunto il pagamento, e solo allora scopre che il sabato non si arriva.
La soluzione è esporre la restrizione, non solo il verdetto. L'endpoint di disponibilità di Boris sa dire cosa pretende una data di arrivo — notti minime, massime, se arrivo o partenza sono chiusi — così lo storefront disabilita le date che verrebbero rifiutate invece di rifiutarle dopo il checkout. Stessa regola, una query prima, un tasso di conversione diverso.
Per lo stesso motivo ogni percorso di prenotazione deve consultare le regole. Una tariffa o una restrizione valida nel back office ma non nello storefront, nell'app o nelle API è peggio che non averla: sembra applicata, e questo impedisce a chiunque di verificarla.
Niente deve cambiare finché non esiste una regola
Ultima proprietà di un'implementazione sana: quando nessuna regola copre il soggiorno, il resolver non restituisce nulla e il chiamante tiene il prezzo che aveva già. Installare le tariffe stagionali non deve cambiare nessun prezzo esistente finché qualcuno non scrive deliberatamente una stagione.
I buchi conviene segnalarli, non riempirli. Una notte scoperta dentro un piano giornaliero può ricadere sul prezzo di quel piano in modo difendibile. Un prezzo mensile non si divide in notti in un modo che si possa giustificare a un cliente, quindi lì il comportamento onesto è rifiutare il preventivo invece di inventare un numero.
Domande frequenti
Il soggiorno minimo vale per ogni notte del soggiorno?
No. Si verifica sulla regola che copre la notte di arrivo: è la convenzione di tutti i channel manager. Altrimenti un soggiorno che semplicemente arriva a toccare una stagione da tre notti verrebbe rifiutato per la sua seconda notte, e un ospite che arriva in bassa stagione e parte in alta si sentirebbe dire che il suo soggiorno è troppo corto.
Se il soggiorno attraversa due stagioni, quale tariffa si applica?
Ogni notte paga la tariffa della regola che la copre. Una tariffa unica per soggiorno non sa rappresentare un soggiorno che inizia economico e finisce caro: approssima verso l'estremo per cui è stata scritta, e il margine si perde silenziosamente proprio sulle prenotazioni a cavallo fra due stagioni.
Perché la chiusura in partenza è un controllo separato?
Perché la data di partenza non è una notte del soggiorno. La regola che copre la notte di arrivo può non arrivare fino a lì, quindi serve una lettura dedicata sulla data di partenza. Trattarla come parte della regola di arrivo è un bug che si manifesta solo sui soggiorni lunghi.
Le restrizioni valgono anche per le prenotazioni a ore?
Mai. "Minimo tre notti" non significa nulla per una sala riunioni o una postazione, e applicare in silenzio una regola sulle notti a una prenotazione oraria chiuderebbe per errore uno spazio coworking. Una richiesta senza notti deve saltare il controllo.