Hvorfor sliter barer med ineffektive kassasystemer i hektiske perioder?

Et kassesystem trenger ikke føles tregt når det er rolig.

Problemet kommer når 25 gjester vil bestille samtidig.

Da blir hvert ekstra trykk, hvert produktsøk og hvert sekund foran skjermen ganget opp igjen og igjen.

Og plutselig er det ikke bartenderen som bestemmer hvor raskt baren kan jobbe.

Det er kassesystemet.

Dette er noe løsninger som Munu er bygget for å løse.

Her er de vanligste grunnene til at det skjer.

Dette lærer du

• Hvorfor små forsinkelser blir store i rush
• Hvilke deler av kassen som faktisk bremser bartenderen
• Hvorfor innlogging og betaling betyr mer enn mange tror
• Hvordan ordre til kjøkken og bar påvirker kapasiteten
• Hva du bør teste før du velger kassesystem til en travel bar
• Hvordan systemvalg påvirker hele arbeidsflyten i serveringssteder
• Hvorfor skalerbarhet er avgjørende når volumet øker

1. For mange trykk på de vanligste bestillingene

Tenk på det en bartender selger hundrevis av ganger:

En halvliter.

Et glass vin.

Gin tonic.

Enkel drink.

To øl og én alkoholfri.

Disse ordrene bør gå ekstremt raskt.

Hvis bartenderen må åpne en menygruppe, velge undergruppe, finne produktet, velge variant og bekrefte flere ganger, har systemet allerede tapt tid.

Én slik ordre er ikke problemet.

Hundrevis av dem er.

Det viktigste spørsmålet er derfor ikke hvor mange funksjoner kassen har.

Det er hvor raskt bartenderen kan gjennomføre de vanligste ordrene.

Et godt baroppsett prioriterer volumproduktene først.

Produktene bartenderen bruker mest bør ligge lett tilgjengelig. Menystrukturen bør følge hvordan baren faktisk jobber, ikke hvordan produktregisteret ser finest ut i backoffice.

2. Ansatte bruker tid på å logge inn og bytte bruker

Personlige brukere er viktige.

Du vil vite hvem som slo inn salget, hvem som åpnet regningen og hvem som gjorde en korrigering.

Men identifikasjon må være rask.

Hvis bartenderen må taste en lang PIN-kode eller skrive inn e-post og passord hver gang en annen ansatt overtar kassen, skaper du kø rundt selve systemet.

I en hektisk bar brukes gjerne samme arbeidsstasjon av flere ansatte gjennom kvelden.

Da bør bytte mellom ansatte skje på sekunder.

Det gir både fart og bedre datakvalitet.

Alternativet er ofte at alle bruker samme innlogging fordi det går raskere.

Da har du løst køproblemet ved å ødelegge sporbarheten.

3. Menyen er bygget for administrasjon, ikke for bartenderen

En produktstruktur kan være helt logisk i et regneark og helt håpløs fredag kveld.

Tenk deg at bartenderen skal finne en bestemt whisky.

I backoffice kan det virke ryddig med:

Drikke → Alkohol → Brennevin → Whisky → Skottland → Produkt.

Bak baren er det fem nivåer for mye.

Det samme gjelder drinker med mange modifikasjoner.

Bartenderen bør ikke måtte navigere gjennom systemet for å finne det gjesten nettopp bestilte.

Test derfor kassen med de faktiske ordrene dere får.

Ikke bare med én kaffe under en salgsdemo.

4. Betalingen stopper neste ordre

Dette er en klassisk flaskehals.

Bartenderen har registrert ordren.

Gjesten skal betale.

Terminalen jobber.

Og kassen venter.

I mellomtiden står neste gjest klar.

En travel bar må kunne håndtere høy betalingsfrekvens uten at én betaling låser arbeidsflyten for resten av baren.

Det handler både om hvor raskt betalingen starter og hvor mange betalinger du kan håndtere samtidig.

Har du én kasse og én terminal som alle må vente på, har du laget én felles flaskehals.

Bruk gjerne Terminaler per kasse-kalkulatoren for å teste hvordan antall terminaler, betalingstid og antall betalinger i rush påvirker kapasiteten.

Men husk:

Flere terminaler løser ikke et tregt kassasystem.

Hele flyten må være rask.

5. Kasse og betaling fungerer som to separate prosesser

Bartenderen bør ikke måtte tenke på hva som skjer mellom kassen og betalingen.

Beløpet bør gå riktig over.

Betalingen bør knyttes til riktig ordre.

Og neste salg bør kunne starte så raskt som mulig.

Når ansatte må taste beløpet manuelt i terminalen, kontrollere summen og deretter fullføre ordren i kassen, får du flere operasjoner per gjest.

Du øker også risikoen for feil.

Det er en av grunnene til at én samlet betalingsplattform kan være interessant for serveringssteder med mange betalingspunkter.

Det samme prinsippet gjelder betaling i restaurant, bar og pub generelt:

Jo mindre manuelt arbeid mellom bestilling og betaling, desto bedre flyt.

6. Åpne regninger og splittbetaling tar for lang tid

Ikke alle barer kjører ren bestill-og-betal.

Noen har løpende barregninger.

Andre har bordservering.

Og noen har begge deler samtidig.

Da må systemet være raskt også når ordren ikke følger standardflyten.

Bartenderen bør enkelt kunne:

• åpne en regning
• finne den igjen
• legge til nye varer
• flytte varer
• dele regningen
• ta delbetaling
• avslutte regningen

Hvis en enkel splittbetaling krever hjelp fra den ene personen på jobb som virkelig kan kassen, har du et problem.

Rush avslører slike svakheter raskt.

7. Bartenderen må vente på at andre ansatte blir ferdige

En travel bar jobber parallelt.

Én tar ordre.

En annen lager drinker.

En tredje tar betaling.

En fjerde serverer.

Kassesystemet må støtte samme måte å jobbe på.

Hvis systemet i praksis tvinger alle gjennom én skjerm, én terminal eller én bestemt arbeidsflyt, begynner ansatte å vente på hverandre.

Da hjelper det lite at hver enkelt bartender er rask.

Systemet setter kapasiteten.

Dette er også grunnen til at du bør teste flere samtidige brukere før du velger løsning.

Ikke test bare hvor raskt én person kan slå inn én ordre.

Test hva som skjer når hele baren jobber samtidig.

8. Alle bestillinger må gjennom samme punkt

Noen barer har én naturlig kø.

Andre har flere.

Du kan ha gjester ved bardisken, bordservering, uteservering og digitale bestillinger samtidig.

Hvis alt må gjennom den samme bartenderen og den samme kassen, får du et kapasitetsproblem selv om teknologien isolert sett er rask.

Da bør du vurdere hvor ordrene egentlig bør komme fra.

Spørsmålet om QR-bestilling eller kø i baren er derfor mer enn et spørsmål om gjesteopplevelse.

Det handler også om kapasitet.

På en stor uteservering kan digital bestilling flytte selve registreringen bort fra bardisken.

I en cocktailbar kan det motsatte være riktig fordi dialogen med bartenderen er en viktig del av opplevelsen.

Poenget er ikke at alle skal bruke QR.

Poenget er at kassesystemet bør støtte arbeidsflyten som passer konseptet.

9. Ordrene kommer ikke raskt nok til riktig produksjonssted

Mange barer selger mer enn øl og vin.

De har cocktails.

Mat.

Snacks.

Kaffe.

Kanskje pizza eller burgere fra kjøkkenet.

Da må en ordre kunne deles automatisk.

Drikken skal til riktig sted.

Maten skal til kjøkkenet.

Ingen bør måtte rope bestillingen videre eller skrive den på en ekstra lapp.

Jo mer volum du har, desto mindre tåler du manuelle overleveringer.

En god ordrevei gjør at bartenderen kan registrere bestillingen én gang og stole på at resten skjer riktig.

10. Systemet fungerer fint helt til nettet eller en integrasjon får problemer

Rush er feil tidspunkt å oppdage hvor avhengig baren er av én nettforbindelse eller én ekstern tjeneste.

Et moderne kassesystem kan være skybasert og samtidig ha en plan for ustabil forbindelse.

Det viktige er å vite hva som faktisk skjer.

Kan bartenderen fortsette å registrere ordre?

Hva skjer med betalingene?

Hva skjer med åpne regninger?

Kommer ordrene frem til produksjonen?

Hva synkroniseres når forbindelsen kommer tilbake?

Dette bør være avklart før den kvelden du faktisk trenger det.

11. Kassesystemet ble aldri testet som en bar

Dette er kanskje den vanligste feilen.

Systemet blir demonstrert i et møterom.

Noen legger inn en Cola.

Åpner et bord.

Deler en regning.

Tar betalt.

Alt fungerer.

Men det sier nesten ingenting om hvordan systemet fungerer lørdag klokken 00:30.

Et barsystem bør stresstestes.

Lag en realistisk øvelse:

Tre ansatte bruker systemet samtidig.

Én gjest bestiller fire forskjellige drinker.

Neste gjest skal ha to øl.

En tredje vil åpne regning.

Noen skal splitte betaling.

En vare er utsolgt.

Kjøkkenet skal ha én del av ordren.

En nyansatt skal klare det uten å spørre om hjelp.

Da begynner du å se forskjellen på et system som kan brukes i bar og et system som er bygget for bar.

Hva bør et effektivt kassesystem for bar klare?

For meg handler et godt barsystem først og fremst om friksjon.

Det skal fjerne den.

De viktigste tingene jeg ville sett etter er:

• raske produkttaster og logisk meny
• svært rask innlogging og brukerbytte
• integrert og rask betaling
• flere ansatte som kan jobbe samtidig
• enkel håndtering av åpne regninger
• rask splitt og delbetaling
• tydelig ordrevei til bar og kjøkken
• mulighet for mobile eller ekstra salgspunkter i rush
• stabil drift når volumet blir høyt
• støtte for flere lokasjoner og skalerbare oppsett
• fleksibilitet til ulike serveringskonsepter

Munu for barer og puber er ett eksempel på en løsning som er bygget med denne typen høyvolumsflyt som bruksområde.

Det interessante er ikke bare hvilke funksjoner som står på produktlisten.

Det interessante er hvordan de fungerer når mange mennesker skal betjenes samtidig.

Det ser du også tydelig i mer ekstreme miljøer. DNB Arena bruker for eksempel samme plattform på tvers av barer, kiosker og andre serveringspunkter.

Det er slike situasjoner som er interessante når du skal vurdere hvor godt et system skalerer under press.

Den virkelige testen skjer når køen begynner å vokse

Et ineffektivt kassesystem er lett å leve med når det er stille.

Det er derfor problemet kan få eksistere lenge.

Men i rush blir hvert ekstra trykk synlig.

Hver treg innlogging merkes.

Hver terminal det ventes på får en kø bak seg.

Og hver unødvendig prosess stjeler kapasitet fra bartenderen.

Derfor bør du ikke velge kassesystem etter hvor mange funksjoner det har.

Velg etter hvor lite bartenderen trenger å tenke på systemet når baren er full.

Test de vanligste ordrene.

Test betalingen.

Test flere ansatte samtidig.

Test den vanskelige splittregningen.

Og test det med tempo.

Det er først da du finner ut om kassen faktisk er rask.