Zašto Excel nije sustav za prodaju događaja

Zamislite novogodišnju večeru u hotelu. Kongresna dvorana ima nekoliko kategorija mjesta, neki se stolovi čuvaju za izvođače, a prodaja istodobno prima upite putem web stranice, telefona i poslovnih partnera. Menadžer ne želi samo znati koliko je mjesta ukupno ostalo. Treba mu točan odgovor na mnogo zahtjevnije pitanje: koja su mjesta stvarno slobodna, tko ih je rezervirao i što je s tom rezervacijom dosad učinjeno?

U praksi se na to pitanje često odgovara pomoću više nepovezanih evidencija. Jedna tablica bilježi rezervacije. Druga prikazuje raspored sjedenja. Treća prati uplate. Imena gostiju i odabir jelovnika stižu naknadno, obično u porukama. Na dan događaja netko slaže konačni popis za ulaz.

Excel nije loš alat. Naprotiv: odličan je za pregled, proračun i ad hoc analizu. Ali kad više ljudi istodobno mijenja stanje istog mjesta, nije dovoljan kao jedinstveni sustav za upravljanje prodajom.

Prvi problembroj slobodnih mjesta nije dovoljan

Za događaj s definiranim sjedenjem deset slobodnih mjesta nije isto što i slobodan stol za desetero. Možete imati po dva slobodna mjesta za pet stolova, a da nijedna obitelj od šestero ne može sjesti zajedno.

Zato evidencija mora biti vezana uz konkretna mjesta u prostoru. Stol, pojedinačno mjesto i kategorija nisu samo napomena uz rezervaciju. Oni su predmet rezervacije.

U 100LICA tlocrt dvorane predstavlja upravo tu vezu. Na njemu su stvarni stolovi i mjesta, s raspoloživošću i statusima koji se koriste u procesu rezervacije. Organizator može odvojiti mjesta koja nisu u javnoj prodaji, dok gost na javnom prikazu bira ona koja jesu dostupna.

Drugi problemdvoje ljudi može željeti isto mjesto

Kad je tablica otvorena na više računala, stanje se mijenja između trenutka kad ga jedan zaposlenik vidi i trenutka kad spremi izmjenu. Još je složenije kad gost istodobno bira mjesto putem web stranice.

Suvremeni rezervacijski sustav mora razlikovati tri trenutka: mjesto je prikazano kao slobodno; privremeno je zadržano dok gost dovršava podatke; zahtjev za rezervaciju obrađen je i stanje je upisano.

U 100LICA postoji logika vremenski ograničenog zadržavanja i provjera raspoloživosti na poslužitelju. Rezervacijska jezgra koristi transakcije i provjere sukoba. To je mnogo važnije od same boje sjedala na tlocrtu: rezervacija mora biti potvrđena prema stanju koje vrijedi kad je zahtjev obrađen.

To nije obećanje da nijedan softver nikad ne može pogriješiti. To je objašnjenje zašto rezervacija mora imati pravila i kontrolu sukoba ugrađene u poslovni tijek.

Treći problemrezervacija nije uplata

Gost može rezervirati osam mjesta i platiti samo dio iznosa. Ako se u tablici jedno polje zove „plaćeno”, često nije jasno označava li primljeni predujam, puni iznos ili samo informaciju koju je gost javio telefonom.

Za prodaju događaja potrebno je odvojiti rezervirana mjesta od financijskog stanja. Uz rezervaciju treba znati ukupnu obvezu, provjerene uplate i preostali iznos. Ako jedna grupa plaća u više koraka, svaki korak mora biti razumljiv sljedećem kolegi koji preuzima posao.

100LICA podržava ručno evidentiranje provjerenih uplata, djelomične iznose, preostale obveze i PDF predračun. To nije isto što i aktivna online kartična naplata ili automatsko bankovno usklađivanje. Upravo je zato preciznost statusa važna: dobar sustav ne smije sugerirati da je novac primljen ako nije evidentiran.

Četvrti problem„Popis gostiju” brzo postaje više od popisa

Kod većih grupa osoba koja radi rezervaciju često još ne zna sva imena. Naknadno stižu odabiri jelovnika, promjene pratitelja i napomene o prehrani. Ako se informacije šalju odvojeno od rezervacije, tim kuhinje i tim na ulazu lako rade s različitim verzijama.

Kad su podaci povezani s rezerviranim mjestima, organizator može vidjeti tko je prijavljen za konkretno mjesto, što je od jelovnika odabrano i što još treba provjeriti. U 100LICA gost može, kroz zaštićeni pristup, dopunjavati podatke za već rezervirana mjesta. To ne znači automatsku kupnju dodatnih mjesta niti obećanje da je svaki poseban zahtjev za prehranu već odobren.

Istodobno, grupa ne mora doći zajedno. Provjera na ulazu treba podržati i djelomičan dolazak, uz praćenje broja preostalih gostiju u rezervaciji.

Peti problemdogađaj ne završava zatvaranjem prodaje

Kad večer završi, menadžment želi odgovor na konkretna pitanja. Koliko je mjesta bilo rezervirano? Koliko je zaista evidentirano kao uplaćeno? Koje su obveze ostale otvorene? Kako se rezultat uspoređuje s drugim programom iste sezone?

To zahtijeva iste definicije tijekom cijelog procesa. „Rezervirano”, „uplaćeno” i „preostalo” ne smiju se proizvoljno miješati. A ako događaji posluju u različitim valutama, običan zbroj iznosa bez pravila konverzije nije smislen prihod.

U 100LICA postoje pregledi na razini događaja i sezonsko izvještavanje. Vrijednost nije u tome da sustav napravi lijep grafikon. Vrijednost je u tome da izvještaj polazi od istih rezervacija i evidencija s kojima je tim zaista radio.

Što mijenja jedan povezani operativni sustav?

Kad se tlocrt dvorane, rezervacija, financijski status, podaci o gostima i doček nalaze u povezanom procesu, zaposlenici imaju manje razloga provjeravati „tko ima posljednju verziju tablice”. Promjena rezervacije ima mjesto u evidenciji. Uplata se prati uz odgovarajuću obvezu. Gosti i jelovnici ostaju uz rezervirana mjesta. Na ulazu se ne počinje ispočetka.

To ne znači da svaki hotel mora prestati koristiti Excel. Naprotiv: tablica ostaje odličan format za analizu i izvoze. Ali ne bi trebala biti jedini autoritet za pravo na određeno mjesto, njegov status i informacije potrebne različitim timovima.

Ako su odgovori nejasni, problem vjerojatno nije još jedan stupac u tablici, nego način na koji su procesi povezani.