08-28-2020, 10:16 AM
(Questo messaggio è stato modificato l'ultima volta il: 08-28-2020, 10:35 AM da yellow.)
Cari WuBookers,
scrivo per parlarvi del nuovo meccanismo dell'Ota Limit. Sono arrivate mille domande ed e' bene
fare chiarezza. In modo da spiegarvi bene tutto quello che c'e' da sapere a riguardo.
Inizio pero' con le mie scuse per le turbolenze da release: come qualcuno ha accennato, il lavoro
e' stato realmente enorme. Le aspettavamo queste turbolenze e ci siamo impegnati al massimo
per gestirle. Non e' mai abbastanza, ma sappiate che gli sforzi sono stati massimi. Spero anche
che la release piaccia: le nuove cose non sono poche. E presto, a cascata, ne arriveranno altre.
A partire dalla prossima settimana. Vedrete.
Anyway, torniamo al punto. Ota Limit.
Zak ha fatto un passo molto avanti rispetto all'industry. Non conosco altre tecnologie (siano OTA
oppure PMS oppure channel manager) che supportino disponibiltia' diverse a seconda delle rates.
E una ragione c'e': ci vuole del coraggio per affrontare certe sfide. Non sono semplici.
Un passo indietro per chi ancora non avesse chiari gli ultimi intereventi.
Su Tabla, abbiamo inserito due nuovi valori: Ota Limit e Availability Modifier.
Questi strumenti consentono di differenziare la dispo, per ogni rate, per ogni giorno.
L'availabiility modifier consente di aggiungere/togliere dispo. Questo permette una gestione razionale,
per esempio, delle overbooking-sales.
L'Ota Limit, invece, si utilizza per limitare le vendite delle vostre OTA, pratica chiaramente orientata al
tentativo di ottimizzare le vendite dirette o quantomeno quelle dai canali piu' appropriati.
Ma.... i canali supportano disponibilita' diverse per ogni rate? No.
La risposta e' No. Almeno in genere. La disponiblita' viene gestita a livello camera.
Poi e' chiaro, si possono mettere restrizioni e chiusure: ma non si tratta di differenziare la dispo.
Si tratta di chiudere alcune rates rispetto ad altre.
E allora, come viene gestita la cosa? Come fa Zak ad assegnare disponibiltia' diverse alle rates dei vostri
canali. Ecco il perche' di questo articolo. Vi spiego precisamente cosa succede.
Partiamo da un esempio: sulla nostra OTA X abbiamo due rates: OR1 e OR2. Diciamo che queste rates
sono state mappate alle rates di Zak ZR1 e ZR2. Ora fissiamo nelle nostre menti una data e una camera.
Una camera con disponibilita' 100 .
Su ZR1 abbiamo OtaLimit = 4. Mentre su ZR2 abbiamo OtaLimit = 6.
In questo caso (e supponendo che non siano ancora state ricevute prenotazioni dall'OTA), Zak inviera'
disponibilita' 4 a entrambe le rates (OR1 e OR2).
E voi subito osserverete: ma cosi' tradite la vendita di 6 camere su OR2.
Non proprio. Vediamo cosa succede quando ricevete una prima prenotazione.
La disponibilita' OTA e' scesa. Su OR1, teoricamente, dovremmo avere 3. E su OR2 5.
Come nel caso precedente, Zak prende il valore minimo. E inviera' disponibilta' 3 alla vostra camera.
Mano a mano che riceverete altre prenotazioni, le cose vengono ripetute. Fino a che, finalmente,
l'OTA Limit della rate ZR1 non viene esaurita.
Ora abbiamo 4 prenotazioni dalle OTA. La rate OR1 verra' chiusa (aveva Ota Limit = 4).
Ma a questo punto, Zak inviera' dispo = 2 alla vostra camera, tenendo aperta la rate OR2.
Pronta a ricevere altre due prenotazioni.
Utilizzare questi strumenti avanzati non e' obbligatorio. Tuttavia, gia' osserviamo diversi utenti
che mettono OtaLimit= 1 sulla standard e OtaLimit= 5 sulla NR. Spero possiate intuire che questo
tipo di meccanismo potrebbe gia' costituire un primo mattone di un potente Yield Manager :)
Qualsiasi domanda e' bene accetta. Sono totalmente disponibile a chiarire ogni dubbio.
Intendo relativamente al tema Ota Limit (per commenti piu' generici relativi alla release,
fatturazione e cose cosi', vi prego di usare il thread specifico).
Considero importante una totale disponiblita' a parlare con il nostro pubblico, data la
novita' che abbiamo introdotto.
Grazie a tutti per l'attenzione
scrivo per parlarvi del nuovo meccanismo dell'Ota Limit. Sono arrivate mille domande ed e' bene
fare chiarezza. In modo da spiegarvi bene tutto quello che c'e' da sapere a riguardo.
Inizio pero' con le mie scuse per le turbolenze da release: come qualcuno ha accennato, il lavoro
e' stato realmente enorme. Le aspettavamo queste turbolenze e ci siamo impegnati al massimo
per gestirle. Non e' mai abbastanza, ma sappiate che gli sforzi sono stati massimi. Spero anche
che la release piaccia: le nuove cose non sono poche. E presto, a cascata, ne arriveranno altre.
A partire dalla prossima settimana. Vedrete.
Anyway, torniamo al punto. Ota Limit.
Zak ha fatto un passo molto avanti rispetto all'industry. Non conosco altre tecnologie (siano OTA
oppure PMS oppure channel manager) che supportino disponibiltia' diverse a seconda delle rates.
E una ragione c'e': ci vuole del coraggio per affrontare certe sfide. Non sono semplici.
Un passo indietro per chi ancora non avesse chiari gli ultimi intereventi.
Su Tabla, abbiamo inserito due nuovi valori: Ota Limit e Availability Modifier.
Questi strumenti consentono di differenziare la dispo, per ogni rate, per ogni giorno.
L'availabiility modifier consente di aggiungere/togliere dispo. Questo permette una gestione razionale,
per esempio, delle overbooking-sales.
L'Ota Limit, invece, si utilizza per limitare le vendite delle vostre OTA, pratica chiaramente orientata al
tentativo di ottimizzare le vendite dirette o quantomeno quelle dai canali piu' appropriati.
Ma.... i canali supportano disponibilita' diverse per ogni rate? No.
La risposta e' No. Almeno in genere. La disponiblita' viene gestita a livello camera.
Poi e' chiaro, si possono mettere restrizioni e chiusure: ma non si tratta di differenziare la dispo.
Si tratta di chiudere alcune rates rispetto ad altre.
E allora, come viene gestita la cosa? Come fa Zak ad assegnare disponibiltia' diverse alle rates dei vostri
canali. Ecco il perche' di questo articolo. Vi spiego precisamente cosa succede.
Partiamo da un esempio: sulla nostra OTA X abbiamo due rates: OR1 e OR2. Diciamo che queste rates
sono state mappate alle rates di Zak ZR1 e ZR2. Ora fissiamo nelle nostre menti una data e una camera.
Una camera con disponibilita' 100 .
Su ZR1 abbiamo OtaLimit = 4. Mentre su ZR2 abbiamo OtaLimit = 6.
In questo caso (e supponendo che non siano ancora state ricevute prenotazioni dall'OTA), Zak inviera'
disponibilita' 4 a entrambe le rates (OR1 e OR2).
E voi subito osserverete: ma cosi' tradite la vendita di 6 camere su OR2.
Non proprio. Vediamo cosa succede quando ricevete una prima prenotazione.
La disponibilita' OTA e' scesa. Su OR1, teoricamente, dovremmo avere 3. E su OR2 5.
Come nel caso precedente, Zak prende il valore minimo. E inviera' disponibilta' 3 alla vostra camera.
Mano a mano che riceverete altre prenotazioni, le cose vengono ripetute. Fino a che, finalmente,
l'OTA Limit della rate ZR1 non viene esaurita.
Ora abbiamo 4 prenotazioni dalle OTA. La rate OR1 verra' chiusa (aveva Ota Limit = 4).
Ma a questo punto, Zak inviera' dispo = 2 alla vostra camera, tenendo aperta la rate OR2.
Pronta a ricevere altre due prenotazioni.
Utilizzare questi strumenti avanzati non e' obbligatorio. Tuttavia, gia' osserviamo diversi utenti
che mettono OtaLimit= 1 sulla standard e OtaLimit= 5 sulla NR. Spero possiate intuire che questo
tipo di meccanismo potrebbe gia' costituire un primo mattone di un potente Yield Manager :)
Qualsiasi domanda e' bene accetta. Sono totalmente disponibile a chiarire ogni dubbio.
Intendo relativamente al tema Ota Limit (per commenti piu' generici relativi alla release,
fatturazione e cose cosi', vi prego di usare il thread specifico).
Considero importante una totale disponiblita' a parlare con il nostro pubblico, data la
novita' che abbiamo introdotto.
Grazie a tutti per l'attenzione
