Ogni restrizione seleziona combinazioni di arrivo, partenza e durata. Per essere utile deve avere un obiettivo, una data di revisione e una condizione di rimozione.
Ogni restrizione seleziona combinazioni di arrivo, partenza e durata. Per essere utile deve avere un obiettivo,…
Definisci il problema di domanda prima di scegliere la regola nel PMS o nell’extranet.
Quale restrizione ti crea più dubbi operativi: MinLOS, CTA, CTD, booking window o release?
Una restrizione tariffaria non serve a “chiudere” la vendita in modo generico. Serve a decidere quali combinazioni di arrivo, partenza e durata l’hotel vuole accettare su una determinata data, camera, tariffa e canale. È una differenza sostanziale: una restrizione di soggiorno minimo (Minimum Length of Stay, MinLOS — apri la spiegazione) applicata senza leggere la domanda può eliminare soggiorni profittevoli; una chiusura agli arrivi (Closed to Arrival, CTA — apri la spiegazione) usata al posto di uno stop-sell — apri la spiegazione può lasciare vendibili permanenze che attraversano la data; una release — apri la spiegazione non governata può trattenere camere fino a quando è troppo tardi per rivenderle.
Minimum Length of Stay (MinLOS — apri la spiegazione), Maximum Length of Stay (MaxLOS — apri la spiegazione), Closed to Arrival (CTA — apri la spiegazione), Closed to Departure (CTD — apri la spiegazione), stop-sell — apri la spiegazione, booking window — apri la spiegazione e release — apri la spiegazione sono quindi regole di selezione della domanda, non pulsanti da attivare per abitudine. Prima di usarle servono quattro informazioni: il problema da risolvere, il livello su cui opera la regola, la data in cui sarà riesaminata e la condizione che ne determina la rimozione.
Le etichette, inoltre, non garantiscono un comportamento identico in ogni PMS — apri la spiegazione, channel manager — apri la spiegazione, CRS — apri la spiegazione o OTA — apri la spiegazione. La documentazione di Booking.com distingue, per esempio, fra soggiorno minimo applicato alla data di arrivo e soggiorno minimo applicato a tutte le date attraversate; Oracle separa MinLOS — apri la spiegazione, MaxLOS — apri la spiegazione, Min/Max Stay Through — apri la spiegazione, CTA — apri la spiegazione e CTD — apri la spiegazione; altri canali ricevono solo una parte delle restrizioni disponibili. Fonti: Booking.com Connectivity, disponibilità e restrizioni; Oracle Hospitality, Availability Management.
Questa guida costruisce un metodo operativo: definire la regola, capire che cosa filtra davvero, applicarla al livello corretto, verificare che sia arrivata ai portali e rimuoverla quando il motivo originario non esiste più.
La sequenza corretta parte dal calendario della domanda, non dall’extranet — apri la spiegazione. Per ogni periodo critico chiediti quale risultato vuoi ottenere:
Se il problema non è formulato, la restrizione diventa una scorciatoia. “Mettiamo tre notti perché c’è il ponte” non dice se esiste domanda per tre notti, quali mercati la generano, che cosa accade alle ricerche di due notti e quando la regola sarà allentata.
In questo articolo il pickup — apri la spiegazione indica la variazione netta delle camere-notte prenotate per lo stesso periodo di soggiorno fra due date di osservazione. Il confronto riflette nuove prenotazioni, cancellazioni e modifiche; nel registro vanno indicati il periodo di soggiorno, le due date di osservazione, l’unità e i filtri applicati.
La decisione dovrebbe sempre contenere quattro elementi:
Questo approccio collega le restrizioni alla strategia di revenue management alberghiero: non basta aumentare il prezzo o chiudere disponibilità; bisogna preservare la combinazione di domanda che massimizza il valore dell’intero periodo.
Le restrizioni possono operare su oggetti diversi. Prima di attivarne una, identifica almeno questi livelli:
Due regole con nomi simili possono filtrare ricerche differenti. Una MinLOS — apri la spiegazione arrival-based — apri la spiegazione valuta la durata soltanto quando il check-in — apri la spiegazione cade sulla data restritta. Una MinLOS — apri la spiegazione stay-through — apri la spiegazione valuta ogni notte attraversata. La prima può lasciare passare un soggiorno iniziato il giorno prima; la seconda può respingerlo perché include la notte soggetta al minimo.
Anche il livello di applicazione conta. Una CTA — apri la spiegazione sull’intero hotel è molto diversa dalla stessa regola su una camera o su un solo rate plan — apri la spiegazione. Oracle documenta restrizioni a livello di struttura, room type — apri la spiegazione, rate category — apri la spiegazione, rate code — apri la spiegazione e channel; Booking.com gestisce disponibilità e restrizioni attraverso combinazioni di camera e rate plan — apri la spiegazione. Fonti: Oracle Hospitality, gestione delle restrizioni; Booking.com Connectivity, Availability, Rates and Inventory.
La prima verifica pratica è quindi questa: la regola è associata all’oggetto che l’utente sta realmente cercando? Se la risposta è incerta, non è ancora pronta per essere pubblicata sui canali.
La Minimum Length of Stay impone un numero minimo di notti. Può essere utile quando una richiesta breve occuperebbe la notte più richiesta lasciando difficili da vendere le date adiacenti. Non serve, invece, a “far salire l’ADR — apri la spiegazione” in automatico: se il mercato cerca una o due notti, una MinLOS — apri la spiegazione 3 può semplicemente cancellare la struttura dai risultati.
Esempio: sabato è quasi pieno, venerdì e domenica sono deboli. Una MinLOS — apri la spiegazione 2 sul sabato può favorire soggiorni venerdì-sabato o sabato-domenica, ma soltanto se l’implementazione del canale e la domanda reale consentono entrambe le combinazioni. Se la regola è arrival-based — apri la spiegazione, l’esito cambia in funzione del giorno di check-in — apri la spiegazione.
La Maximum Length of Stay limita il numero massimo di notti. È meno frequente, ma può essere utile per:
Una MaxLOS — apri la spiegazione non sostituisce la gestione legale o amministrativa dei soggiorni prolungati. È una regola commerciale di disponibilità e va coordinata con policy — apri la spiegazione, contratti e requisiti locali.
Booking.com distingue minimumstay_arrival da minimumstay, e analogamente maximumstay_arrival da maximumstay: nel primo caso la regola dipende dal check-in — apri la spiegazione, nel secondo dalla presenza della data nel soggiorno. La piattaforma documenta anche exactstay_arrival, mentre sistemi più evoluti possono gestire pattern di Full Pattern Length of Stay — apri la spiegazione, cioè durate ammesse o vietate per singola data di arrivo. Fonti: Booking.com, restrictions; Oracle Hospitality, FPLOS.
Prima di usare MinLOS — apri la spiegazione o MaxLOS — apri la spiegazione annota quindi:
CTA — apri la spiegazione — Closed to Arrival impedisce nuovi check-in — apri la spiegazione nella data indicata. In genere non impedisce a un soggiorno iniziato prima di attraversare quella notte e non chiude automaticamente le partenze.
CTD — apri la spiegazione — Closed to Departure impedisce il check-out — apri la spiegazione nella data indicata. Può essere utile quando una partenza creerebbe un buco difficile da colmare o quando esistono limiti operativi, ma deve essere usata con cautela: un cliente che cerca di terminare il soggiorno proprio quel giorno può non trovare la combinazione.
CTA — apri la spiegazione e CTD — apri la spiegazione non sono sinonimi di stop-sell — apri la spiegazione:
Expedia usa codici di indisponibilità distinti per checkin_not_allowed, checkout_not_allowed, minimum_stay, maximum_stay e altre restrizioni. Questo conferma che il motore di ricerca interpreta cause diverse e può restituire un “non disponibile” anche quando esiste inventario fisico. Fonte: Expedia Group, unavailable reason codes.
Un controllo semplice evita molti errori: prova almeno quattro ricerche intorno alla data restritta — arrivo il giorno prima, arrivo nel giorno, partenza nel giorno, partenza il giorno dopo — e registra quali combinazioni restano realmente prenotabili.
Lo stop-sell — apri la spiegazione sospende la vendita dell’oggetto selezionato: può riguardare l’hotel, una camera, una tariffa o un canale. È appropriato quando non vuoi accettare altre prenotazioni in quel perimetro, per esempio perché:
Non usarlo al posto di una restrizione più precisa. Se vuoi evitare soltanto arrivi il sabato, chiudere tutte le vendite del sabato può eliminare anche soggiorni già iniziati che avrebbero riempito domenica. Se vuoi proteggere una promozione, chiudere l’intera tipologia può danneggiare BAR — apri la spiegazione e vendita diretta.
Booking.com precisa che lo stato closed non cancella automaticamente prezzo e camere precedentemente inviati: alla riapertura possono tornare disponibili i dati rimasti memorizzati. È un motivo in più per controllare disponibilità e tariffa dopo ogni open, non soltanto il simbolo verde nell’extranet — apri la spiegazione. Fonte: Booking.com Connectivity, open/close rooms.
Quando lo stop-sell — apri la spiegazione nasce da un errore tecnico, collega l’intervento al processo di verifica mensile delle extranet OTA e alla prevenzione dell’overbooking in hotel: chiudere è una misura di contenimento, non la soluzione della causa.
La booking window — apri la spiegazione definisce quanto tempo prima dell’arrivo una tariffa può essere prenotata. Le due estremità rispondono a problemi differenti.
Impedisce prenotazioni troppo vicine all’arrivo. Può servire quando una tariffa include servizi da preparare, quando manca presidio operativo dopo una certa ora o quando un canale non trasmette in tempo utile. Il cutoff — apri la spiegazione può essere espresso in giorni oppure, nei sistemi che lo supportano, in ore.
Impedisce prenotazioni oltre una certa distanza nel futuro. Può evitare di vendere prima che prezzi, contratti o disponibilità siano definiti. Non va confuso con il limite generale del calendario aperto: una tariffa può avere una finestra più corta dell’inventario dell’hotel.
Una tariffa last minute — apri la spiegazione è normalmente disponibile entro una finestra vicina all’arrivo; un cutoff — apri la spiegazione rende invece la tariffa indisponibile dentro quella stessa finestra. Sono logiche opposte. Cloudbeds le distingue esplicitamente e ricorda che il comportamento dipende dalle restrizioni configurate e dalla trasmissione supportata dal canale. Fonti: Cloudbeds, rate plan restrictions; Cloudbeds, cutoff e last minute.
Per ogni booking window — apri la spiegazione verifica il fuso orario, l’orario di cambio data e il sistema che fa fede. Una regola “1 giorno” può comportarsi diversamente se il portale calcola giorni di calendario e il PMS — apri la spiegazione usa ore rispetto al check-in — apri la spiegazione.
La release — apri la spiegazione è il termine entro cui le camere di un allotment — apri la spiegazione non ancora vendute vengono restituite alla disponibilità dell’hotel. Non è una restrizione identica a MinLOS — apri la spiegazione o CTA — apri la spiegazione: nasce da un rapporto contrattuale e definisce quando l’inventario bloccato per un partner smette di esserlo.
Le variabili da scrivere nel contratto e replicare nei sistemi sono:
Non esiste una release — apri la spiegazione “giusta” per tutti. Una finestra lunga può proteggere il partner ma restituire le camere quando la domanda residua è debole; una finestra corta aumenta la libertà del partner e l’esposizione dell’hotel. La scelta deve confrontare pickup — apri la spiegazione del partner, lead time — apri la spiegazione del mercato alternativo e probabilità di rivendere.
Nel controllo settimanale separa tre numeri: camere assegnate, camere vendute, camere ancora bloccate. La differenza fra allotment — apri la spiegazione contrattuale e inventario effettivamente recuperabile è una delle cause più frequenti di percezione errata della disponibilità. Per approfondire la filiera contrattuale, consulta bedbank, wholesaler, tour operator e OTA.
Molti sistemi usano tariffe parent — apri la spiegazione e child — apri la spiegazione: la tariffa figlia — apri la spiegazione deriva prezzo, disponibilità o restrizioni da una tariffa principale. Questo riduce il lavoro manuale, ma crea un rischio: modificare la regola nel punto sbagliato oppure aspettarsi che una figlia erediti un campo non previsto.
Booking.com documenta regole di ereditarietà diverse in base al tipo di restrizione e alla configurazione del rate plan — apri la spiegazione. Oracle consente livelli multipli di controllo e pubblicazione verso CRS — apri la spiegazione e canali. Il nome commerciale “derivata” non basta quindi a sapere che cosa si propaga. Fonti: Booking.com, restrictions and rate relations; Oracle Hospitality, Availability Management.
Prima di intervenire crea una mappa minima:
Se una restrizione sembra “ricomparire”, non correggerla ripetutamente nell’OTA — apri la spiegazione. Cerca prima un parent rate — apri la spiegazione, un’automazione RMS — apri la spiegazione, una regola del PMS — apri la spiegazione o un job — apri la spiegazione del channel manager — apri la spiegazione che la reinvia.
Sabato è quasi pieno, venerdì e domenica sono deboli. Valuta MinLOS — apri la spiegazione o pattern di soggiorno solo dopo aver misurato quante ricerche utili esistono per due o tre notti. Controlla ogni giorno pickup — apri la spiegazione e camere residue. Se le spalle — apri la spiegazione non si muovono, riduci il vincolo prima di perdere le richieste brevi ancora profittevoli. Nei periodi di ponti e festività la restrizione deve seguire il calendario reale della domanda, non la sola etichetta “alta stagione”.
Se il picco cade nel giorno dell’evento, una CTA — apri la spiegazione può proteggere gli arrivi precedenti senza chiudere automaticamente chi è già in casa. Verifica però trasporti, check-in — apri la spiegazione tardivi e permanenze richieste dal mercato. La data di rimozione può dipendere dall’occupazione o dai giorni mancanti, non da una scadenza arbitraria.
In bassa stagione le restrizioni rigide spesso riducono visibilità e conversione — apri la spiegazione. Usa MinLOS — apri la spiegazione soltanto quando esiste una ragione economica misurabile; altrimenti lavora su offerta, segmenti, permanenza media e costi di apertura. Un MaxLOS — apri la spiegazione può avere senso su una tariffa promozionale, ma non deve limitare senza motivo la domanda lunga che aiuta a coprire i costi fissi.
Un partner ha dieci camere con release — apri la spiegazione a sette giorni. Il controllo non consiste nel guardare soltanto le prenotazioni ricevute: confronta produzione, camere ancora bloccate, lead time — apri la spiegazione degli altri canali e capacità di rivendere dopo la release — apri la spiegazione. Se la produzione è concentrata nelle sole date già forti, rinegozia quantità, periodo o finestra di restituzione.
Questi scenari mostrano la stessa regola: la restrizione è valida finché risolve il problema per cui è stata attivata. Quando il problema cambia, deve cambiare anche la configurazione.
Le restrizioni possono migliorare il mix di domanda, ma generano effetti collaterali prevedibili.
Una permanenza accettata può lasciare una singola notte fra due prenotazioni. MinLOS — apri la spiegazione e pattern di soggiorno possono ridurre il problema, ma anche crearne altri se applicati su date sbagliate. Simula il calendario dopo ogni nuova prenotazione rilevante.
Il cliente può vedere “nessuna disponibilità” anche quando esistono camere, perché la combinazione viola CTA — apri la spiegazione, CTD — apri la spiegazione, durata o anticipo. Expedia elenca codici distinti per queste cause; nel funnel — apri la spiegazione pubblico il viaggiatore, però, spesso percepisce soltanto l’assenza dell’hotel. Fonte: Expedia Group, unavailable reason codes.
Una MinLOS — apri la spiegazione impostata per un evento può restare attiva dopo che il pickup — apri la spiegazione ha rallentato. Ogni regola deve quindi avere un responsabile, una data di revisione e un motivo scritto. “Finché serve” non è una scadenza.
Un canale può non ricevere la restrizione, interpretarla diversamente o ricevere soltanto disponibilità e prezzi. Cloudbeds avverte che alcuni canali calendar-based — apri la spiegazione accettano disponibilità ma non l’intero insieme di restrizioni. Fonte: Cloudbeds, Channel Distribution FAQ.
Se la regola elimina le combinazioni più cercate, la tariffa non partecipa al confronto e il problema può essere confuso con ranking — apri la spiegazione o prezzo. Prima di intervenire sulla visibilità, verifica che la struttura sia davvero prenotabile per la ricerca osservata; poi analizza i fattori controllabili del ranking su Booking.com.
Salvare una restrizione nel PMS — apri la spiegazione o nel channel manager — apri la spiegazione non dimostra che sia attiva sull’OTA — apri la spiegazione. Il flusso minimo è:
Un HTTP — apri la spiegazione 200 non garantisce sempre che ogni elemento sia stato accettato. Booking.com documenta risposte che possono contenere errori, warning — apri la spiegazione o esiti parziali anche dopo una richiesta tecnicamente ricevuta. Fonte: Booking.com Connectivity, error handling.
Per una modifica critica conserva:
La prova pubblica deve essere effettuata come un cliente reale: occupazione corretta, valuta, paese o device quando rilevanti, date pulite e nessuna sessione che riutilizzi ricerche precedenti. Se emergono differenze, non compensarle con modifiche ripetute finché non hai identificato il sistema che prevale.
Una procedura breve riduce sia gli errori sia le restrizioni “eterne”.
Per ogni intervento compila una riga con:
Il rollback — apri la spiegazione non è soltanto “togliere la spunta”. Dopo la rimozione verifica che prezzi, camere e altre restrizioni rimaste siano coerenti; controlla inoltre almeno una ricerca che prima era bloccata. Se compaiono differenze di prezzo o inventario, applica il metodo di diagnosi del rate leakage prima di intervenire su più sistemi contemporaneamente.
Le risposte sintetizzano la differenza fra durata, arrivo, partenza, chiusura e anticipo. La configurazione esatta va sempre verificata nel PMS — apri la spiegazione, nel channel manager — apri la spiegazione e nella documentazione del canale utilizzato.
MinLOS — apri la spiegazione è un’etichetta generale per il soggiorno minimo. In alcuni sistemi è applicata alla data di arrivo; una regola stay-through — apri la spiegazione viene invece valutata su tutte le date attraversate dalla prenotazione. Le due configurazioni possono produrre risultati diversi sulla stessa ricerca.
No. Closed to Arrival impedisce il check-in — apri la spiegazione nella data interessata, ma normalmente consente a un soggiorno iniziato prima di attraversarla. Per chiudere la vendita nel perimetro selezionato serve uno stop-sell — apri la spiegazione o una chiusura equivalente.
Di norma CTD — apri la spiegazione filtra nuove ricerche e prenotazioni con partenza nella data, non riscrive automaticamente prenotazioni già confermate. Le prenotazioni esistenti vanno comunque controllate prima di applicare la regola.
Possono produrre un risultato pubblico simile, ma descrivono stati diversi. Lo stop-sell — apri la spiegazione chiude la vendita; disponibilità zero indica assenza di unità vendibili. Nei sistemi il prezzo e l’inventario precedentemente inviati possono restare memorizzati e riemergere alla riapertura.
La trasmissione può non essere supportata, essere fallita, avere ricevuto un warning — apri la spiegazione, essere stata sovrascritta o applicarsi a una diversa combinazione camera-tariffa. Controlla log — apri la spiegazione, acknowledgment — apri la spiegazione, mappatura, Extranet — apri la spiegazione e prova pubblica prima di reinviare.
Sì, se l’architettura del sistema consente regole per canale e il contratto non impone altri vincoli. Va però verificato che la restrizione sia davvero supportata dal singolo collegamento e che non venga ereditata da una regola globale.
Quando non protegge più valore: il pickup — apri la spiegazione rallenta, le spalle — apri la spiegazione non si riempiono, la disponibilità residua cresce o il tempo alla data rende più profittevoli soggiorni brevi. La condizione dovrebbe essere definita prima dell’attivazione e riesaminata a scadenze ravvicinate.
No. La release — apri la spiegazione restituisce all’hotel camere di un allotment — apri la spiegazione; il cutoff — apri la spiegazione limita quanto vicino all’arrivo si può prenotare; la politica di cancellazione disciplina conseguenze e termini della rinuncia a una prenotazione già confermata.
Soltanto se risolvono un problema concreto. In domanda debole una regola rigida può eliminare visibilità e prenotazioni utili. Può avere senso proteggere una promozione, un servizio o una permanenza minima economicamente necessaria, ma va misurata e rivista.
Controlla sistema sorgente, log — apri la spiegazione di invio, risposta del canale, Extranet — apri la spiegazione e ricerche pubbliche. Prova combinazioni che devono essere consentite e bloccate, su desktop e mobile se il canale presenta flussi diversi, e registra data, ora, occupazione e risultato.
Fonti verificate al 25 agosto 2026: Booking.com Connectivity, Availability, Rates and Inventory; Oracle Hospitality, Availability Management; Expedia Group, unavailable reason codes; SiteMinder Exchange, Availability and Rates; HSMAI, The Future of Pricing; Cloudbeds, Channel Distribution FAQ. La semantica effettiva dipende dall’integrazione utilizzata e va verificata prima dell’attivazione.
Il confronto continua nella Community Revenue & Co.: proponi un tema, condividi un caso o partecipa alle conversazioni.
Quale restrizione ti crea più dubbi operativi: MinLOS, CTA, CTD, booking window o release?
I commenti e il confronto proseguono sui canali social e nello spazio Community di Revenue & Co.
Mappiamo domanda, sistemi, gerarchie e canali per definire regole con obiettivo, verifica pubblica e rollback.
Le espressioni tecniche della guida, spiegate nel significato preciso con cui vengono usate qui.
