Zašto Excel nije sistem za prodaju događaja

Zamislite novogodišnju večeru u hotelu. Kongresna sala ima nekoliko kategorija mesta, neki stolovi se čuvaju za izvođače, a prodaja istovremeno prima upite preko sajta, telefona i poslovnih partnera. Menadžer ne želi samo da zna koliko je mesta ukupno ostalo. Treba mu tačan odgovor na mnogo zahtevnije pitanje: koja mesta su stvarno raspoloživa, ko ih je rezervisao i šta je sa tom rezervacijom do sada urađeno?

U praksi se na to pitanje često odgovara pomoću više nepovezanih evidencija. Jedna tabela beleži rezervacije. Druga prikazuje raspored sedenja. Treća prati uplate. Imena gostiju i izbor menija stižu naknadno, obično u porukama. Na dan događaja neko sastavlja konačni spisak za ulaz.

Excel nije loš alat. Naprotiv: odličan je za pregled, proračun i ad hoc analizu. Ali kada više ljudi istovremeno menja stanje istog mesta, nije dovoljan kao jedinstveni sistem za upravljanje prodajom.

Prvi problembroj slobodnih mesta nije dovoljan

Za događaj sa definisanim sedenjem deset slobodnih mesta nije isto što i slobodan sto za desetoro. Možete imati po dva slobodna mesta za pet stolova, a da ni jedna porodica od šestoro ne može zajedno da sedne.

Zato evidencija mora biti vezana za konkretna mesta u prostoru. Sto, pojedinačno mesto i kategorija nisu samo napomena uz rezervaciju. Oni su predmet rezervacije.

U 100LICA mapa sale predstavlja upravo tu vezu. Na njoj su stvarni stolovi i mesta, sa raspoloživošću i statusima koji se koriste u procesu rezervacije. Organizator može da odvoji mesta koja nisu u javnoj prodaji, dok gost na javnom prikazu bira ona koja jesu dostupna.

Drugi problemdvoje ljudi može želeti isto mesto

Kada je tabela otvorena na više računara, stanje se menja između trenutka kada ga jedan zaposleni vidi i trenutka kada sačuva izmenu. Još je složenije kada gost istovremeno bira mesto preko sajta.

Moderni rezervacioni sistem mora razlikovati tri momenta: mesto je prikazano kao slobodno; privremeno je zadržano dok gost završava podatke; zahtev za rezervaciju obrađen je i stanje je upisano.

U 100LICA postoji logika vremenski ograničenog zadržavanja i provera raspoloživosti na serveru. Rezervaciono jezgro koristi transakcije i provere konflikata. To je mnogo važnije od same boje sedišta na mapi: rezervacija mora biti potvrđena prema stanju koje važi kada je zahtev obrađen.

To nije obećanje da nijedan softver nikada ne može pogrešiti. To je objašnjenje zašto rezervacija mora imati pravila i kontrolu konflikta ugrađene u poslovni tok.

Treći problemrezervacija nije uplata

Gost može rezervisati osam mesta i platiti samo deo iznosa. Ako se u tabeli jedno polje zove „plaćeno”, često nije jasno da li označava primljeni avans, puni iznos ili samo informaciju koju je gost javio telefonom.

Za prodaju događaja potrebno je odvojiti rezervisana mesta od finansijskog stanja. Uz rezervaciju treba znati ukupnu obavezu, proverene uplate i preostali iznos. Ako jedna grupa plaća u više koraka, svaki korak mora biti razumljiv sledećem kolegi koji preuzima posao.

100LICA podržava ručno evidentiranje proverenih uplata, delimične iznose, preostale obaveze i PDF predračun. To nije isto što i aktivna online kartična naplata ili automatsko bankarsko usaglašavanje. Upravo zato je preciznost statusa važna: dobar sistem ne treba da sugeriše da je novac primljen ako nije evidentiran.

Četvrti problem„Spisak gostiju” brzo postaje više od spiska

Kod većih grupa osoba koja pravi rezervaciju često još ne zna sva imena. Naknadno stižu izbori menija, promene pratilaca i napomene o ishrani. Ako se informacije šalju odvojeno od rezervacije, tim kuhinje i tim na ulazu lako rade sa različitim verzijama.

Kada su podaci povezani sa rezervisanim mestima, organizator može da vidi ko je prijavljen za konkretno mesto, šta je od menija izabrano i šta još treba proveriti. U 100LICA gost može, kroz zaštićeni pristup, dopunjavati podatke za već rezervisana mesta. To ne znači automatsku kupovinu dodatnih mesta niti obećanje da je svaki poseban zahtev za ishranu već odobren.

Istovremeno, grupa ne mora da dođe zajedno. Provera na ulazu treba da podrži i delimičan dolazak, uz praćenje broja preostalih gostiju u rezervaciji.

Peti problemdogađaj se ne završava zatvaranjem prodaje

Kada se završi veče, menadžment želi odgovor na konkretna pitanja. Koliko je mesta bilo rezervisano? Koliko je zaista evidentirano kao uplaćeno? Koje su obaveze ostale otvorene? Kako se rezultat poredi sa drugim programom iste sezone?

To zahteva iste definicije tokom celog procesa. „Rezervisano”, „uplaćeno” i „preostalo” ne smeju se proizvoljno mešati. A ako događaji posluju u različitim valutama, prost zbir iznosa bez pravila konverzije nije smislen prihod.

U 100LICA postoje pregledi na nivou događaja i sezonsko izveštavanje. Vrednost nije u tome da sistem napravi lep grafikon. Vrednost je u tome da izveštaj polazi od istih rezervacija i evidencija sa kojima je tim zaista radio.

Šta menja jedan povezani operativni sistem?

Kada se mapa sale, rezervacija, finansijski status, podaci o gostima i prijem nalaze u povezanom procesu, zaposleni imaju manje razloga da proveravaju „ko ima poslednju verziju tabele”. Promena rezervacije ima mesto u evidenciji. Uplata se prati uz odgovarajuću obavezu. Gosti i meniji ostaju uz rezervisana mesta. Na ulazu se ne počinje iz početka.

To ne znači da svaki hotel mora prestati da koristi Excel. Naprotiv: tabela ostaje odličan format za analizu i izvoze. Ali ne bi trebalo da bude jedini autoritet za pravo na određeno mesto, njegov status i informacije potrebne različitim timovima.

Ako su odgovori nejasni, problem verovatno nije još jedna kolona u tabeli, nego način na koji su procesi povezani.