[Your Sardinia]

Buongiorno,
Premetto che gestisco appartamenti situati non nello stesso punto geografico, ma in varie strutture
Vorrei chiedere l'utilità di alcuni suggerimenti.
vedendo altri siti che utilizzano le online reception concorrenti, ho notato alcune cose che potrebbero essere d'aiuto:

1) la lista degli appartamenti può essere filtrata in:
a )prezzi
b) numero occupanti (ora da noi se scegli un filtro di X persone esclude dalla ricerca le case con occupazione Y, Z etc)
c) filtrata per posizione (con tanto di mappa con i puntatori che ne indicano l'esatta posizione)
d) filtrata per dotazione (es. wi-fi, aria condizionata, giardino etc)

entrando all'interno del sito del programma di online reception (non so se si può dire il nome) ho trovato questo spunto:

2) Pos virtuale
permette di realizzare riscossioni, preautorizzazioni (anche per le cauzioni con rilascio dopo un numero di giorni preimpostato), rimborsi su tutte le tue prenotazioni, convalida dei dati della carta del cliente, se sono corretti e se c'è saldo (mi viene in mente la prenotazione da booking.com).

Inoltre la terza richiesta è una che ho chiesto altre volte ma non credo che sia stata fatta, vi faccio direttamente un esempio pratico:
3) ad oggi in una tipologia di case (la chiamerò piano terra) ho 3 appartamenti/disponibilità e mi risulta che nella prima casa ci sia disponibilità per lunedì e martedì, nella seconda mercoledì e giovedì, nella terza venerdì e sabato.
Al cliente che cerca da lunedì a sabato da disponibile, anche se in realtà dovrebbe prendere le valige ogni 2 giorni e traslocare.
E' possibile fare qualcosa a riguardo, in modo che dia non disponibile?
Su zak il percorso è inverso: si creano gli appartamenti (1, 2 e 3) e poi si riuniscono in tipologie. Magari facendo questo percorso si riesce a trovare una soluzione.
L'alternativa che ho usato il primo anno è stato eliminare le tipologie e fare una scheda per ogni appartamento, ma oltre ad essere brutto a livello estetico (con le tipologie si riesce a ridurre l'elenco anche del 60%), non si può fare il giochetto di spostare le prenotazioni all'interno della stessa tipologia in quanto il cliente ha prenotato l'appartamento 1 e dovrebbe soggiornare in quello specifico.

Credo che per oggi basti :D

Buona giornata a tutti!

[yellow]

Ciao,

a proposito del primo punto, vediamo cosa riusciremo a fare. Nelle prossime settimane sono attesi diversi aggiornamenti
dell'online reception che prevedono:

1. Miglioramenti grafici
2. Costi obbligatori su base camere (cioe' ogni camera puo' avere i suoi)
3. Miglioramento del voucher (e grafico e operativo, in modo che sia per esempio stampabile in A4 e, inviato tramite fax, sia una sola pagina)

Poi vedremo un attimo il da farsi e certamente valorizziamo tutti gli interventi. Amo questo forum!!

Per il secondo punto, io penso che Stripe possa essere un servizio per te. Vuoi dare un occhio?
Non credo possiamo aiutarti. E per diversi punti: da questioni giuridiche a questioni economiche (e anche tecniche).

Per il problema della dispo "spezzata", non e' risolvibile in nessun modo, se non manualmente. Almeno su WuBook,
perche' WuBook (come booking.com) ignora completametne le camere fisiche che danno disponibilita' alle categorie.

Questo puo' eventualmetne essere fatto su Zak e nella nuova versione (ripeto come ho fatto qua e la che stiamo
riscrivendolo daccapo) abbiamo gia' intenzione di valutarla come possibilita'!!

[brown]

In merito al 3° Punto: disponibilità spezzate.
Non credo che neanche con ZaK sia possibile risolvere questo problema.
L'informazione della disponibilità fra ZaK e WuBook è infatti diversa. In WuBook
è "più povera", e questo è inevitabile poichè in WuBook camere della stessa
categoria sono mescolate ed indistinguibili.

L'unica cosa che mi è venuta in mente è l'introduzione di una nuova restrizione:
il max.stay.arrival (impedisce l'ingresso di soggiorni più lunghi rispetto
al valore configurato nella data di arrivo). Se ZaK aggiornasse su WuBook,
assieme alla disponibilità, anche questa restrizione, il grosso di questi
casi sarebbe risolto (per prenotazioni dirette).

La creazione di questa nuova restrizione avrebbe però un peso enorme per WuBook:
fra l'altro anche la speigazione e la visualizzazione sul Tabla, ma anche la gestione
e il controllo sull'online reception.
Ma sopratutto questa soluzione non sarebbe risolutiva. Il grosso delle prenotazioni
proviene infatti ancora dai portali. Se i portali non supportano la restrizione,
le prenotazioni su disponibilità spezzata potrebbero comunque continuare ad entrare.

[PR045]

Io fin ora ho provato a rimediare con il max.stay.arrival.
Ma non ho capito una cosa, se io imposto questo parametro ha effetto anche sui canali come booking.com oppure no?
Grazie,

In merito al 3° Punto: disponibilità spezzate.
Non credo che neanche con ZaK sia possibile risolvere questo problema.
L'informazione della disponibilità fra ZaK e WuBook è infatti diversa. In WuBook
è "più povera", e questo è inevitabile poichè in WuBook camere della stessa
categoria sono mescolate ed indistinguibili.

L'unica cosa che mi è venuta in mente è l'introduzione di una nuova restrizione:
il max.stay.arrival (impedisce l'ingresso di soggiorni più lunghi rispetto
al valore configurato nella data di arrivo). Se ZaK aggiornasse su WuBook,
assieme alla disponibilità, anche questa restrizione, il grosso di questi
casi sarebbe risolto (per prenotazioni dirette).

La creazione di questa nuova restrizione avrebbe però un peso enorme per WuBook:
fra l'altro anche la speigazione e la visualizzazione sul Tabla, ma anche la gestione
e il controllo sull'online reception.
Ma sopratutto questa soluzione non sarebbe risolutiva. Il grosso delle prenotazioni
proviene infatti ancora dai portali. Se i portali non supportano la restrizione,
le prenotazioni su disponibilità spezzata potrebbero comunque continuare ad entrare.

[Your Sardinia]

Ciao!

grazie mille per gli interventi e sono contento che ci potrebbe essere qualche spiragli per le mie richieste.

Per la questione delle maximum stay, si dovrebbero fare tanti passaggi tipo:
periodo lun - mar > max stay 2 e poi far no check-in per il martedì.. e così via per gli altri periodi?

Buona serata a tutti

In merito al 3° Punto: disponibilità spezzate.
Non credo che neanche con ZaK sia possibile risolvere questo problema.
L'informazione della disponibilità fra ZaK e WuBook è infatti diversa. In WuBook
è "più povera", e questo è inevitabile poichè in WuBook camere della stessa
categoria sono mescolate ed indistinguibili.

L'unica cosa che mi è venuta in mente è l'introduzione di una nuova restrizione:
il max.stay.arrival (impedisce l'ingresso di soggiorni più lunghi rispetto
al valore configurato nella data di arrivo). Se ZaK aggiornasse su WuBook,
assieme alla disponibilità, anche questa restrizione, il grosso di questi
casi sarebbe risolto (per prenotazioni dirette).

La creazione di questa nuova restrizione avrebbe però un peso enorme per WuBook:
fra l'altro anche la speigazione e la visualizzazione sul Tabla, ma anche la gestione
e il controllo sull'online reception.
Ma sopratutto questa soluzione non sarebbe risolutiva. Il grosso delle prenotazioni
proviene infatti ancora dai portali. Se i portali non supportano la restrizione,
le prenotazioni su disponibilità spezzata potrebbero comunque continuare ad entrare.

[brown]

Ciao!

grazie mille per gli interventi e sono contento che ci potrebbe essere qualche spiragli per le mie richieste.

Per la questione delle maximum stay, si dovrebbero fare tanti passaggi tipo:
periodo lun - mar > max stay 2 e poi far no check-in per il martedì.. e così via per gli altri periodi?

Buona serata a tutti

In merito al 3° Punto: disponibilità spezzate.
Non credo che neanche con ZaK sia possibile risolvere questo problema.
L'informazione della disponibilità fra ZaK e WuBook è infatti diversa. In WuBook
è "più povera", e questo è inevitabile poichè in WuBook camere della stessa
categoria sono mescolate ed indistinguibili.

L'unica cosa che mi è venuta in mente è l'introduzione di una nuova restrizione:
il max.stay.arrival (impedisce l'ingresso di soggiorni più lunghi rispetto
al valore configurato nella data di arrivo). Se ZaK aggiornasse su WuBook,
assieme alla disponibilità, anche questa restrizione, il grosso di questi
casi sarebbe risolto (per prenotazioni dirette).

La creazione di questa nuova restrizione avrebbe però un peso enorme per WuBook:
fra l'altro anche la speigazione e la visualizzazione sul Tabla, ma anche la gestione
e il controllo sull'online reception.
Ma sopratutto questa soluzione non sarebbe risolutiva. Il grosso delle prenotazioni
proviene infatti ancora dai portali. Se i portali non supportano la restrizione,
le prenotazioni su disponibilità spezzata potrebbero comunque continuare ad entrare.

Vedo che il tema interessa. E' un po' complesso, provo a spiegarmi.

Innanzitutto rispondo a PR045: WuBook attualmente non supporta il max.stay.arrival.
Non credo che verrà sviluppato perchè è un lavoro pesante e delicato in WuBook
ma sopratutto perchè neanche le OTA lo supportano, quindi avrebbe comunque
efficacia solo per la vendita dal proprio sito.

Per rispondere ad Alberto:
Nel calcolare la disponibilità da inviare a WuBook, ZaK controlla ogni singolo
giorno. La disponibilità inviata è corretta, non si può lavorare sulla disponibilità.
Si potrebbe al limite usare una restrizione. Ma quale?
Il "close to arrival" non è esatta: ogni giorno può essere comprato singolarmente
indipendentemente da quando arrivo.

Il problema si verifica quando il soggiorno dura più di un giorno (e nel mezzo
finisce una camera e ne inizia un'altra della stessa categoria).
Quindi deve essere il "max.stay". Ma questo è troppo grezzo. Servirebbe
un "max.stay.arrival" per farla bene (ma questa restrizione non è supportata).

Supponiamo di avere le camere A e B della stessa categoria. La disponibilità
della A è aperta dal 5 al 10 del mese, quella di B è apera dal 6 al 15.
La disponibilità sarà 1 dal 5 al 15, e questo è giusto.
Se ci fosse un max.stay.arrival di 6 notti per chi arriva il 5, di 5 notti per
chi arriva il 6, di 4 notti per chi attiva il 7, 8->3, 9->2... di 1 notte per chi arriva il 10.
Sarebbe possibile prenotare solo soggiorni abbastanza corti da non occupare
entrambe le camere. Chi prenota la A potrà farlo solo per un soggiorno
abbastanza corto da non dover cambiare camera.
(Restano fuori casi ancora più complessi, ad esempio quando si hanno
3 camere della stessa categoria che si aprono e chiudono).

Ci ho pensato a lungo, questa è l'unica soluzione che mi è venuta in mente.
Ripeto che è lontana dall'essere sviluppata per i motivi che ho già spiegato:
1) E' un lavoro grande di impatto notevole e delicato.
2) Se le OTA non supportano la restrizione, sarebbe comunque una soluzione
molto limitata.
3) In realtà non risolverebbe comunque al 100% il problema.

E' un tema complesso. Se io mi fossi spiegato male, chiedete pure.

Michele

[Your Sardinia]

Si in effetti non risolve il problema.

Mentre al posto di inserire (esempio) categoria villetta - numero disponibilità 5 si inserisse : villetta 1, 2, 3, 4, 5 e poi si crea un gruppo villetta e si inseriscono tutte?

La prenotazione di wubook (con disponibilità spezzata) che viene scaricata in zak te la mette in "pending" perché vede che in un unica villetta non c'è tutto il periodo prenotato in un unica casa.

So che sono 2 modi di concepire la disponibilità diversi, ma credo che su questo punto Zak abbia una marcia in più.. è complicato applicare lo stesso su Wubook?

grazie mille e scusatemi se sono molto pesante sull'argomento ma finora me la sono quasi sempre cavata bene facendo spostamenti.. ma quando non è possibile fare gli incastri diventa un problema grave.

Ciao!

grazie mille per gli interventi e sono contento che ci potrebbe essere qualche spiragli per le mie richieste.

Per la questione delle maximum stay, si dovrebbero fare tanti passaggi tipo:
periodo lun - mar > max stay 2 e poi far no check-in per il martedì.. e così via per gli altri periodi?

Buona serata a tutti

In merito al 3° Punto: disponibilità spezzate.
Non credo che neanche con ZaK sia possibile risolvere questo problema.
L'informazione della disponibilità fra ZaK e WuBook è infatti diversa. In WuBook
è "più povera", e questo è inevitabile poichè in WuBook camere della stessa
categoria sono mescolate ed indistinguibili.

L'unica cosa che mi è venuta in mente è l'introduzione di una nuova restrizione:
il max.stay.arrival (impedisce l'ingresso di soggiorni più lunghi rispetto
al valore configurato nella data di arrivo). Se ZaK aggiornasse su WuBook,
assieme alla disponibilità, anche questa restrizione, il grosso di questi
casi sarebbe risolto (per prenotazioni dirette).

La creazione di questa nuova restrizione avrebbe però un peso enorme per WuBook:
fra l'altro anche la speigazione e la visualizzazione sul Tabla, ma anche la gestione
e il controllo sull'online reception.
Ma sopratutto questa soluzione non sarebbe risolutiva. Il grosso delle prenotazioni
proviene infatti ancora dai portali. Se i portali non supportano la restrizione,
le prenotazioni su disponibilità spezzata potrebbero comunque continuare ad entrare.

Vedo che il tema interessa. E' un po' complesso, provo a spiegarmi.

Innanzitutto rispondo a PR045: WuBook attualmente non supporta il max.stay.arrival.
Non credo che verrà sviluppato perchè è un lavoro pesante e delicato in WuBook
ma sopratutto perchè neanche le OTA lo supportano, quindi avrebbe comunque
efficacia solo per la vendita dal proprio sito.

Per rispondere ad Alberto:
Nel calcolare la disponibilità da inviare a WuBook, ZaK controlla ogni singolo
giorno. La disponibilità inviata è corretta, non si può lavorare sulla disponibilità.
Si potrebbe al limite usare una restrizione. Ma quale?
Il "close to arrival" non è esatta: ogni giorno può essere comprato singolarmente
indipendentemente da quando arrivo.

Il problema si verifica quando il soggiorno dura più di un giorno (e nel mezzo
finisce una camera e ne inizia un'altra della stessa categoria).
Quindi deve essere il "max.stay". Ma questo è troppo grezzo. Servirebbe
un "max.stay.arrival" per farla bene (ma questa restrizione non è supportata).

Supponiamo di avere le camere A e B della stessa categoria. La disponibilità
della A è aperta dal 5 al 10 del mese, quella di B è apera dal 6 al 15.
La disponibilità sarà 1 dal 5 al 15, e questo è giusto.
Se ci fosse un max.stay.arrival di 6 notti per chi arriva il 5, di 5 notti per
chi arriva il 6, di 4 notti per chi attiva il 7, 8->3, 9->2... di 1 notte per chi arriva il 10.
Sarebbe possibile prenotare solo soggiorni abbastanza corti da non occupare
entrambe le camere. Chi prenota la A potrà farlo solo per un soggiorno
abbastanza corto da non dover cambiare camera.
(Restano fuori casi ancora più complessi, ad esempio quando si hanno
3 camere della stessa categoria che si aprono e chiudono).

Ci ho pensato a lungo, questa è l'unica soluzione che mi è venuta in mente.
Ripeto che è lontana dall'essere sviluppata per i motivi che ho già spiegato:
1) E' un lavoro grande di impatto notevole e delicato.
2) Se le OTA non supportano la restrizione, sarebbe comunque una soluzione
molto limitata.
3) In realtà non risolverebbe comunque al 100% il problema.

E' un tema complesso. Se io mi fossi spiegato male, chiedete pure.

Michele

[brown]

Si in effetti non risolve il problema.

Mentre al posto di inserire (esempio) categoria villetta - numero disponibilità 5 si inserisse : villetta 1, 2, 3, 4, 5 e poi si crea un gruppo villetta e si inseriscono tutte?

La prenotazione di wubook (con disponibilità spezzata) che viene scaricata in zak te la mette in "pending" perché vede che in un unica villetta non c'è tutto il periodo prenotato in un unica casa.

So che sono 2 modi di concepire la disponibilità diversi, ma credo che su questo punto Zak abbia una marcia in più.. è complicato applicare lo stesso su Wubook?

grazie mille e scusatemi se sono molto pesante sull'argomento ma finora me la sono quasi sempre cavata bene facendo spostamenti.. ma quando non è possibile fare gli incastri diventa un problema grave.

Ciao Alberto, non so se ho capito bene la tua soluzione.

Se, anzichè 3 camere ragruppate in un'unica categoria, usassi 3 categorie
di camera distinte, il problema sarebbe risolto.
Il problema si presenta solo quando più camere fisiche fanno parte della
stessa categoria.

Non ho capito nel tuo esempio cosa intendi per
"si crea un gruppo villetta e si inseriscono tutte".

Michele

[FC082]

avete idea delle tempistiche per
Costi obbligatori su base camere?

grazie, per noi sarebbe importantissimo

Ciao,

a proposito del primo punto, vediamo cosa riusciremo a fare. Nelle prossime settimane sono attesi diversi aggiornamenti
dell'online reception che prevedono:

1. Miglioramenti grafici
2. Costi obbligatori su base camere (cioe' ogni camera puo' avere i suoi)
3. Miglioramento del voucher (e grafico e operativo, in modo che sia per esempio stampabile in A4 e, inviato tramite fax, sia una sola pagina)

Poi vedremo un attimo il da farsi e certamente valorizziamo tutti gli interventi. Amo questo forum!!

Per il secondo punto, io penso che Stripe possa essere un servizio per te. Vuoi dare un occhio?
Non credo possiamo aiutarti. E per diversi punti: da questioni giuridiche a questioni economiche (e anche tecniche).

Per il problema della dispo "spezzata", non e' risolvibile in nessun modo, se non manualmente. Almeno su WuBook,
perche' WuBook (come booking.com) ignora completametne le camere fisiche che danno disponibilita' alle categorie.

Questo puo' eventualmetne essere fatto su Zak e nella nuova versione (ripeto come ho fatto qua e la che stiamo
riscrivendolo daccapo) abbiamo gia' intenzione di valutarla come possibilita'!!

[pink]

avete idea delle tempistiche per
Costi obbligatori su base camere?

grazie, per noi sarebbe importantissimo

Buondì,
il costo per camera sarà operativo con la release della Online Reception che è in cantiere e che andrà online entro la settimana prossima (salvo imprevisti).

Saluti, Andrea.