Kalendar, iCal i channel manager: spriječite dvostruku prodaju

Problem iz poslovanja

Dvije rezervacije potvrde se za isti apartman ili vilu jer je jedan kanal ostao otvoren. Veza kalendara je postavljena, ali tim pretpostavlja da je prijenos trenutačan i da prenosi sve podatke. Potrebna je provjerena logika, ne samo oznaka „povezano”.

Nakon lekcije moći ćete

• Razlikovati kalendarsku vezu od upravljanja cijenama i inventarom.
• Provjeriti oba smjera blokada i životni ciklus rezervacije.
• Uspostaviti postupak za prekid veze i sukob rezervacija.

Odredite primarni izvor raspoloživosti

Zapišite gdje tim prvi unosi direktnu rezervaciju, privatni boravak i radove. Ako tri osobe ručno mijenjaju različite kalendare bez dogovora, ne postoji pouzdana glavna evidencija. Svaka prodajna jedinica treba imati jednoznačan identifikator, a inventar mora odgovarati stvarnom broju jedinica. Blokada cijelog objekta i blokada jednog apartmana nisu ista operacija.

iCal služi razmjeni kalendarskih događaja

Uvoz i izvoz su različiti smjerovi veze. To što rezervacija s kanala A blokira B ne dokazuje da B blokira A. Osvježavanje nije nužno trenutačno i ovisi o sustavima i njihovim postavkama. Kalendarska poveznica nije opća zamjena za prijenos cjenika, pravila, detalja gostiju i poruka. Točan opseg svake integracije provjerite u službenoj dokumentaciji i stvarnom računu.

Channel manager također traži testiranje

Upravljanje inventarom preko povezanog sustava može biti prikladnije za složeniju prodaju, ali naziv proizvoda ne jamči ispravnu konfiguraciju. Provjerite mapiranje jedinica, tarifne planove, ograničenja boravka i smjerove promjena. Pitajte tko je izvor pojedinog podatka i gdje se vidi pogreška. Kod promjene sustava planirajte prijelaz i zadržite pregled svih budućih rezervacija.

Pripremite postupak za iznimku

Kada veza zakaže, zabilježite vrijeme, kanale i zahvaćene termine; odmah ograničite daljnju prodaju u okviru svojih ovlasti i obavijestite odgovornu osobu. U slučaju preklapanja provjerite izvorne potvrde i službeni postupak svakog kanala. Ne brišite rezervaciju iz vlastite evidencije da biste prikrili problem i ne pritiskajte gosta da preuzme odgovornost. Svaka promjena mora ostaviti jasan trag.

Privremeno rezerviran termin i konačno potvrđena rezervacija ne moraju imati isti status u izvozu. Provjerite kako se u vašoj vezi tretiraju opcije i privremene blokade. Izbjegnite kružne veze čije učinke nitko nije provjerio, osobito nakon zamjene sustava.

Postupak rješavanja

1. Nacrtajte jednostavnu mapu svake prodajne jedinice i svih smjerova prijenosa raspoloživosti.

2. Provjerite potvrdu, izmjenu, otkazivanje i ručnu blokadu koristeći dopušteni testni postupak ili stvarnu dokumentiranu promjenu.

3. Zabilježite očekivani ritam osvježavanja i mjesto provjere greške, bez obećanja trenutnog prijenosa.

4. Za dan prekida definirajte tko zatvara prodaju, tko provjerava rezervacije i tko komunicira s gostom i podrškom.

Primjena prema vrsti poslovanja

Pogreške koje treba izbjeći

• Pretpostaviti da „povezano” znači trenutačno i dvosmjerno.
• Mijenjati iste podatke u više sustava bez pravila.
• Nakon otkazivanja ne provjeriti ponovno otvaranje datuma.

Vaš praktični zadatak

Izradite mapu kalendara jednog objekta i zapis testa četiri radnje: potvrda, izmjena, otkazivanje i privatna blokada. U svakoj radnji napišite izvorni sustav, očekivanu promjenu i zatečeni rezultat.