02-09-2022, 10:50 PM
(Questo messaggio è stato modificato l'ultima volta il: 02-09-2022, 10:58 PM da yellow.)
Ciao CM,
grazie del post professionale e preciso. E contributivo e collaborativo.
Dunque, provo a rispondere in ordine sparso.
Le idee che proponi hanno dei contro. E quindi due volte giusto usare la parola "valutare". In particolare,
l'assetto dell'Online Reception di Zak e' stata scelta con alcuni obiettivi, tra cui:
1. Dare massimo spazio al prodotto e alla sua presentazione
2. Essere mobile friendly. E quindi fare economia di spazio
3. Avere un impianto grafico moderno
Se vogliamo valutare l'espansione della FORM (per la selezione date/camere, numero adulti e bambini
per ogni camera), in modo che l'utente veda a colpo d'occhio dove inserire le informazioni, cosa spendiamo?
Quella che ora e' una testata piuttosto contenuta prenderebbe parecchio di spazio. O, alternativamente,
bisogna fare una pagina dedicata per la selezione date. In effetti, nell'immagine che si allega mi sembra
di vedere che la SERP (search engine results page) non c'e'. Sembra una pagina dedicata alla selezione
date, totalmente. Nessun prodotto viene presentato.
Ma questa funzionalita' dovrebbe essere gestita sul sito. Uno dovrebbe aprire il booking engine gia'
in "landing page" sulle date che ha scelto sul sito.
E poi si pone un problema: se sono sulla SERP e voglio cambiare date, devo cambiare pagina? E finire
in una pagina totalmente dedicata alla selezione date? Altrimenti, bisogna prendere parecchio spazio.
C'e' anche un'altra spesa da fare. Io non so se il booking engine allegato (mi sembra sia vertical
booking) abbia una versione mobile dedicata. Se non ce l'ha ed e' responsive, come quello di Zak,
qualla FORM sul mobile rischia di diventare piccola.
Il calendario colorato e con i prezzi non e' preciso. Non lo puo' essere se il booking engine supporta
per esempio multiple rates con restrizioni variegate. Faccio un esempio: se in un giorno abbiamo
aclune restrizioni come MinStay (che quindi sono LOS dependent) non e' possibile mostrare subito
sul calendario il prezzo, tantomeno la dispo. Perche' prima di poterlo capire occorre avere una data
di riferimento. A meno di rischiare una menzogna. La stessa cosa si applica al ClosedToDeparture
e altre restrizioni che possono essere calcolate con precisone solo *dopo* la selezione date.
Al punto 3 dici che occorre "verificare la disponibilita'": ma e' vero solo in parte dati i punti che ho
appena descritto. Anzi, per me non e' tanto bello dire: qui c'e' disponibilita', cliccare e poi trovarsi
un messaggio: scusa, non c'e' disponibilita'. O sono troppo rigoroso? Meglio un errore in questo
senso che un passaggio in piu'? (domanda non retorica).
Ora, con le date flessibili che abbiamo appena introdotto, non dovesse esserci disponibilita', ti
mostriamo per filo e per segno alternative simili. Quindi, una volta che hai compilato la FORM,
anche nel caso non ci sia dispo, vedrai immediatamente la soluzioni alternative migliori.
Domani rilasceremo un potenziamento delle date flessibili. Allego qua uno Shot per farvi capire
quanto l'Onlne Reception vada incontro all'assenza di disponbilita'. Senza cadere al tempo stesso
in menadri poco precisi (vedi allegato al post).
Infine ancora una considerazione che si e' fatta spesso anche su questo forum. Alcuni in Italia
(ma probailmente anche altrove) hanno cavalcato l'era d'oro del booking engine (a N-MILA
euro l'anno) tentando di vendere vitamine piuttosto che arance. Per giustificare certi costi
si e' diffusa l'idea che sia il booking engine a vendere. Piuttosto che il vostro prodotto.
Accade su diversi settori e a mi parere, si puo' ben parlare di una forma di feticismo:
per quanto limitata come metafora, si pensa che sia il Bancomat a rendere vendibile
la banca.
Perche' lo dico? Noi non siamo Google. Abbiamo un team limitato. Non riusciamo al tempo
stesso a occuparci di Channel Management, Booking Engine, Fatturazione elettronica,
Alloggiati, Istat, Ristorante (etc etc) in maniera troppo verticale. Se ora ci mettiamo a
lavorare duri sull'Online Reception, andiamo a rallentare tanti lavori che stiamo per
iniziare, tra cui per esempio:
1. Una nuova mobile APP
2. Una nuova versione di tutta la sezione contabilita'
3. Uno Yield Manager
4. Un CRM
e che secondo me possono esservi molto, molto piu' preziosi. Nella mia esperienza, sempre
ci si e' lamentati del booking engine, ma da dietro le quinte, proprio in quegli anni d'oro per
esempio, io vedevo percentuali di convesione sul booking engine dell'11% [!!!]. E di fianco
a casi di questo tipo, avevamo anche 1%.
Non ci siamo mai vantati per l'11. Perche' semplicemente non era merito nostro. Soltanto,
chi usava le tecnologie, le organizzava in chiave comunicativa con i propri clienti, le proponeva
e le promuoveva con codici sconto per esempio. Dava a tutti i clienti, durante il checkout,
depliant su come prenotare con sconti. Inviava email preciso dopo ogni contatto.
Questo e' cio che veramente disintermedia: non il booking engine come "feticcio".
Valutiamo volentieri evoluzioni del booking engine di Zak. Come no. L'unica cosa che mi
preoccupa e' che poi, tutto sommato, le prenotazioni e le conversioni non cambino. O
meglio, che questi investimenti siano infine inutili e dannose, perche' lavorare in questa
direzione significa non investire dove potreste avere piu' vantaggio voi e di conseguenza
persino noi.
Allora, allego le date alternative come promesso sopra. Perche' secondo me sono uno
strumento che ben si lega e ben risolve le problematiche tipiche di tutti i booking engine.
E in particolare quelle di cui stiamo parlando proprio ora.
Notate che ci sono due immagini, proprio perche' abbiamo sofisticato bene e penso sia
una bella implementazione:
1. In prima battuta, proponiamo solo date molto vicine a quelle scelte dal cliente.
2. In seconda battuta, se per esempio non c'e' niente di vicino, andiamo alla ricerca
delle combinanzioni giuste, allargandoci 60 (60!!!) giorni dalla data di arrivo. Che
io sappia, questa e' un'innovazione (non conosco competitors che riescono ad
avere gittate di questo tipo e -a meno di bug perche' appena uscita- si tratta
di una soluzione *precisa*: se e quando diciamo che c'e' dispo, c'e' veramente.
grazie del post professionale e preciso. E contributivo e collaborativo.
Dunque, provo a rispondere in ordine sparso.
Le idee che proponi hanno dei contro. E quindi due volte giusto usare la parola "valutare". In particolare,
l'assetto dell'Online Reception di Zak e' stata scelta con alcuni obiettivi, tra cui:
1. Dare massimo spazio al prodotto e alla sua presentazione
2. Essere mobile friendly. E quindi fare economia di spazio
3. Avere un impianto grafico moderno
Se vogliamo valutare l'espansione della FORM (per la selezione date/camere, numero adulti e bambini
per ogni camera), in modo che l'utente veda a colpo d'occhio dove inserire le informazioni, cosa spendiamo?
Quella che ora e' una testata piuttosto contenuta prenderebbe parecchio di spazio. O, alternativamente,
bisogna fare una pagina dedicata per la selezione date. In effetti, nell'immagine che si allega mi sembra
di vedere che la SERP (search engine results page) non c'e'. Sembra una pagina dedicata alla selezione
date, totalmente. Nessun prodotto viene presentato.
Ma questa funzionalita' dovrebbe essere gestita sul sito. Uno dovrebbe aprire il booking engine gia'
in "landing page" sulle date che ha scelto sul sito.
E poi si pone un problema: se sono sulla SERP e voglio cambiare date, devo cambiare pagina? E finire
in una pagina totalmente dedicata alla selezione date? Altrimenti, bisogna prendere parecchio spazio.
C'e' anche un'altra spesa da fare. Io non so se il booking engine allegato (mi sembra sia vertical
booking) abbia una versione mobile dedicata. Se non ce l'ha ed e' responsive, come quello di Zak,
qualla FORM sul mobile rischia di diventare piccola.
Il calendario colorato e con i prezzi non e' preciso. Non lo puo' essere se il booking engine supporta
per esempio multiple rates con restrizioni variegate. Faccio un esempio: se in un giorno abbiamo
aclune restrizioni come MinStay (che quindi sono LOS dependent) non e' possibile mostrare subito
sul calendario il prezzo, tantomeno la dispo. Perche' prima di poterlo capire occorre avere una data
di riferimento. A meno di rischiare una menzogna. La stessa cosa si applica al ClosedToDeparture
e altre restrizioni che possono essere calcolate con precisone solo *dopo* la selezione date.
Al punto 3 dici che occorre "verificare la disponibilita'": ma e' vero solo in parte dati i punti che ho
appena descritto. Anzi, per me non e' tanto bello dire: qui c'e' disponibilita', cliccare e poi trovarsi
un messaggio: scusa, non c'e' disponibilita'. O sono troppo rigoroso? Meglio un errore in questo
senso che un passaggio in piu'? (domanda non retorica).
Ora, con le date flessibili che abbiamo appena introdotto, non dovesse esserci disponibilita', ti
mostriamo per filo e per segno alternative simili. Quindi, una volta che hai compilato la FORM,
anche nel caso non ci sia dispo, vedrai immediatamente la soluzioni alternative migliori.
Domani rilasceremo un potenziamento delle date flessibili. Allego qua uno Shot per farvi capire
quanto l'Onlne Reception vada incontro all'assenza di disponbilita'. Senza cadere al tempo stesso
in menadri poco precisi (vedi allegato al post).
Infine ancora una considerazione che si e' fatta spesso anche su questo forum. Alcuni in Italia
(ma probailmente anche altrove) hanno cavalcato l'era d'oro del booking engine (a N-MILA
euro l'anno) tentando di vendere vitamine piuttosto che arance. Per giustificare certi costi
si e' diffusa l'idea che sia il booking engine a vendere. Piuttosto che il vostro prodotto.
Accade su diversi settori e a mi parere, si puo' ben parlare di una forma di feticismo:
per quanto limitata come metafora, si pensa che sia il Bancomat a rendere vendibile
la banca.
Perche' lo dico? Noi non siamo Google. Abbiamo un team limitato. Non riusciamo al tempo
stesso a occuparci di Channel Management, Booking Engine, Fatturazione elettronica,
Alloggiati, Istat, Ristorante (etc etc) in maniera troppo verticale. Se ora ci mettiamo a
lavorare duri sull'Online Reception, andiamo a rallentare tanti lavori che stiamo per
iniziare, tra cui per esempio:
1. Una nuova mobile APP
2. Una nuova versione di tutta la sezione contabilita'
3. Uno Yield Manager
4. Un CRM
e che secondo me possono esservi molto, molto piu' preziosi. Nella mia esperienza, sempre
ci si e' lamentati del booking engine, ma da dietro le quinte, proprio in quegli anni d'oro per
esempio, io vedevo percentuali di convesione sul booking engine dell'11% [!!!]. E di fianco
a casi di questo tipo, avevamo anche 1%.
Non ci siamo mai vantati per l'11. Perche' semplicemente non era merito nostro. Soltanto,
chi usava le tecnologie, le organizzava in chiave comunicativa con i propri clienti, le proponeva
e le promuoveva con codici sconto per esempio. Dava a tutti i clienti, durante il checkout,
depliant su come prenotare con sconti. Inviava email preciso dopo ogni contatto.
Questo e' cio che veramente disintermedia: non il booking engine come "feticcio".
Valutiamo volentieri evoluzioni del booking engine di Zak. Come no. L'unica cosa che mi
preoccupa e' che poi, tutto sommato, le prenotazioni e le conversioni non cambino. O
meglio, che questi investimenti siano infine inutili e dannose, perche' lavorare in questa
direzione significa non investire dove potreste avere piu' vantaggio voi e di conseguenza
persino noi.
Allora, allego le date alternative come promesso sopra. Perche' secondo me sono uno
strumento che ben si lega e ben risolve le problematiche tipiche di tutti i booking engine.
E in particolare quelle di cui stiamo parlando proprio ora.
Notate che ci sono due immagini, proprio perche' abbiamo sofisticato bene e penso sia
una bella implementazione:
1. In prima battuta, proponiamo solo date molto vicine a quelle scelte dal cliente.
2. In seconda battuta, se per esempio non c'e' niente di vicino, andiamo alla ricerca
delle combinanzioni giuste, allargandoci 60 (60!!!) giorni dalla data di arrivo. Che
io sappia, questa e' un'innovazione (non conosco competitors che riescono ad
avere gittate di questo tipo e -a meno di bug perche' appena uscita- si tratta
di una soluzione *precisa*: se e quando diciamo che c'e' dispo, c'e' veramente.