Pasūtījumu plūsmas — Maksāt vispirms vs Maksāt vēlāk
Kad izmantot Maksāt vispirms vai Maksāt vēlāk, kā katra plūsma darbojas no sākuma līdz beigām, pasūtījumu stāvokļi, ko operatori redz administrācijas panelī, un fona uzdevumi, kas uztur pasūtījumu sinhronizāciju ar POS.
Fooodo atbalsta divas atšķirīgas pasūtījumu plūsmas. Tās atšķiras pēc tā, kad virtuve redz pasūtījumu, un kad notiek maksājums. Izvēle ir atkarīga no apkalpošanas stila, nevis no restorāna — viens restorāns var izmantot dažādas plūsmas dažādos galdiņos.
- Guest scans QR, builds cart
- Guest pays
- Order is exported to R-Keeper
- Kitchen prepares
- Guest receives or collects
- Guest scans QR, builds cart
- Items go to R-Keeper kitchen immediately
- Guest adds more rounds (each one syncs)
- Guest asks to pay
- Order locked → marked paid in R-Keeper
Fooodo pasūtījumu plūsmas sazinās ar jūsu POS, izmantojot savienotāja līgumu. R-Keeper šobrīd ir aktīvais atsauces savienotājs — tālāk aprakstītā mehānika raksturo to, kas jānodrošina katrai savienotāja implementācijai.
Maksāt vispirms
Izmantojiet Maksāt vispirms, ja viesiem jāmaksā pirms apkalpošanas sākuma: ēdiena paņemšanai, ātrās apkalpošanas vietās, ēdiena tirgos. Virtuve nekad neredz neapmaksātu pasūtījumu; POS saņem vienu pasūtījuma eksportu uz katru grozu; ja viesis pamet grozu, nekas nesasniedz virtuves līniju.
Maksāt vēlāk
Izmantojiet Maksāt vēlāk ēdināšanai uz vietas un daudzposmu apkalpošanai. Pirmā kārta nonāk POS brīdī, kad tā tiek iesniegta; vēlākās kārtas tiek pievienotas tam pašam POS pasūtījumam pa vienai. Pasūtījums POS paliek atvērts no pirmās kārtas līdz brīdim, kad maksājums to aizver. Iekšēji Fooodo izseko, kuri posteņi jau ir nosūtīti, lai katra kārta tiktu sinhronizēta tikai vienu reizi.
Kāpēc plūsmas atšķiras
Mehāniskā atšķirība ir neliela — Maksāt vispirms veic vienu POS eksportu, Maksāt vēlāk — daudzus. Operacionālā atšķirība ir svarīgāka:
- Maksāt vispirms gadījumā virtuvei nav papildu darba, ja viesis pamet grozu. Taču viesa pieredze nav piemērota ēdināšanai uz vietas: cilvēki sagaida maksāt beigās; prasīt samaksu iepriekš šķiet darījumisks, nevis viesmīlīgs žests.
- Maksāt vēlāk gadījumā viesa pieredze atbilst parastajai restorāna kārtībai. Operators uzņemas nelielu risku, ka pasūtījums var netikt apmaksāts (viesis aiziet, karte neizdodas) — tas pats risks, kas pastāv ar jebkuru šodienas papīra rēķina apkalpošanu.
Daudzi tīkli sāk ar Maksāt vispirms ēdiena izsniegšanas letes, pēc tam pievieno Maksāt vēlāk ēdināšanas galdiņiem, kad personāls ir iepazinies ar administrācijas paneli.
Plūsmas konfigurēšana
Plūsma tiek iestatīta katram galdiņam atsevišķi vai kā restorāna noklusējums administrācijas panelī. Restorāns var kombinēt plūsmas — piemēram, ēdināšanas galdiņi ar Maksāt vēlāk, ēdiena izsniegšanas lete ar Maksāt vispirms, abas darbojoties caur vienu un to pašu Fooodo instalāciju.
Stāvokļi praksē
Pasūtījumi pārvietojas caur stāvokļu automātu. Tālāk norādītie nosaukumi ir tieši tie, kas parādās administrācijas panelī — noderīgi gan operatoriem, kas lasa savus pasūtījumus, gan integrētājiem, kas patērē pasūtījumu notikumus.
Stāvokļi, par kuriem operatori visvairāk rūpējas:
| Stāvoklis | Nozīme |
|---|---|
Created | Grozs pastāv, vēl nav iesniegts neviens postenis |
InProgress | Posteņi iesniegti POS, gaida papildinājumus vai maksājumu |
ReadyToBePaid | Viesis pabeidzis pasūtīšanu, maksājums gaida |
Paid | Maksājums veiksmīgs, POS atzīmēts kā apmaksāts |
Finished | Pasūtījums slēgts, galīgais veiksmīgais stāvoklis |
Ar kļūmēm saistītie stāvokļi:
| Stāvoklis | Nozīme |
|---|---|
Locked | POS ir atvērts pasūtījums (viesmīlis to rediģē). Automātiski atkārto ar atvilkumu. |
Error | Eksports uz POS neizdevās pēc visiem atkārtojumiem. Nepieciešama manuāla iejaukšanās. |
Cancelled | Pasūtījums tika atcelts vai beidzās laiks bez apmaksas |
Lielākā daļa Locked stāvokļu atrisinās sekunžu laikā. Pastāvīgs Locked parasti nozīmē, ka viesmīlis ir atvēris pasūtījumu POS un aizmirsis to aizvērt.
Error ir vienīgais stāvoklis, kas prasa cilvēka uzmanību. Savienotāja kļūmju žurnāli reģistrē, kas nogāja greizi; tipiskais risinājums ir pasūtījuma atkārtota izveide POS terminālī.
Kas darbojas fonā
Neliels skaits ieplānotu uzdevumu uztur pasūtījumu slāni sinhronizētā stāvoklī — operatoriem šie nav jāiegaumē, taču integrētājiem, kas patērē Fooodo datus, vajadzētu zināt biežumus:
| Biežums | Uzdevums |
|---|---|
| Katru minūti | Restorāna pieejamības pārbaude |
| Katru minūti | Atcelt pasūtījumus, kuriem beidzās laiks bez maksājuma |
| Ik 2 min | Ielādēt pasūtījumu atjauninājumus no POS |
| Ik 4 min | Ielādēt galdiņu statusu no POS |
| Ik 5 min | Sinhronizēt posteņu pieejamību |
| Katru dienu 09:00 | Pilna ēdienkartes sinhronizācija |
Ja POS nav sasniedzams, uzdevumi atkārtojas ar eksponenciālu atvilkumu; pasūtījumi rindojas savā pašreizējā stāvoklī un tiek saskaņoti, kad savienotājs atjaunojas.
Fooodo arhitektūra
Kā Fooodo ir veidots — divu pakalpojumu sadalījums starp izvēlnes lietotni un maksājumu pakalpojumu, uzņēmuma/restorāna/galda daudzīrnieku modelis, no POS neatkarīgais savienotāja līgums un kur atrodas UVS.
R-Keeper savienotājs
Fooodo POS savienotāja līguma tiešraides atsauces implementācija — kādi dati šķērso robežu, sinhronizācijas biežums, lojalitātes cenas un kā ražošanā tiek atkārtoti mēģinājumi kļūmju gadījumā.