Fluxuri de comenzi — Pay-First vs Pay-Later

Fooodo acceptă două fluxuri de comenzi distincte. Acestea diferă prin momentul în care bucătăria vede comanda și momentul în care are loc plata. Alegerea depinde de stilul de servire, nu de restaurant — un singur restaurant poate rula fluxuri diferite la mese diferite.

Fluxurile de comenzi ale Fooodo comunică cu POS-ul tău printr-un contract de conector. R-Keeper este conectorul de referință activ în prezent — mecanismele descrise mai jos reprezintă ceea ce orice implementare de conector trebuie să satisfacă.

Pay-First

Utilizați Pay-First atunci când oaspeții ar trebui să plătească înainte ca serviciul să înceapă: comenzi de luat, serviciu rapid, food court-uri. Bucătăria nu vede niciodată o comandă neplătită; POS-ul primește un singur export de comandă per coș; dacă un oaspete abandonează coșul, nimic nu ajunge la linie.

Pay-Later

Utilizați Pay-Later pentru servire la masă și serviciu cu mai multe runde. Prima rundă ajunge la POS în momentul în care este trimisă; rundele ulterioare sunt adăugate la aceeași comandă POS una câte una. Comanda rămâne deschisă în POS de la prima rundă până când plata o închide. Intern, Fooodo urmărește ce articole au fost deja trimise, astfel încât fiecare rundă să fie sincronizată o singură dată.

De ce diferă fluxurile

Diferența mecanică este mică — Pay-First face un singur export POS, Pay-Later face mai multe. Diferența operațională contează mai mult:

• În Pay-First, bucătăria nu face nicio muncă suplimentară dacă un oaspete abandonează coșul. Însă experiența oaspetelui este nepotrivită pentru servirea la masă: oamenii se așteaptă să plătească la final; a cere plata în avans pare tranzacțional, nu ospitalier.
• În Pay-Later, experiența oaspetelui corespunde unui restaurant obișnuit. Operatorul acceptă un risc mic că o comandă ar putea să nu fie plătită (un oaspete pleacă, un card eșuează) — același risc care există astăzi cu orice serviciu cu notă de plată pe hârtie.

Multe lanțuri încep cu Pay-First la ghișeele de comenzi de luat, apoi adaugă Pay-Later la mesele pentru servire la masă odată ce personalul este familiarizat cu panoul de administrare.

Configurarea fluxului

Fluxul este setat per masă sau ca implicit pentru restaurant în panoul de administrare. Un restaurant poate combina fluxuri — de exemplu, mesele pentru servire la masă pe Pay-Later, ghișeul de comenzi de luat pe Pay-First, ambele rulând prin aceeași instalare Fooodo.

Stările, în practică

Comenzile parcurg o mașină de stări. Denumirile de mai jos sunt exact cele care apar în panoul de administrare — utile atât pentru operatorii care își citesc propriile comenzi, cât și pentru integratorii care consumă evenimente de comenzi.

Stările de care se preocupă cei mai mulți operatori:

Stările adiacente eșecului:

Majoritatea stărilor Locked se rezolvă în câteva secunde. Un Locked persistent înseamnă de obicei că un chelner are comanda deschisă în POS și a uitat să o închidă.

Error este singura stare care necesită atenție umană. Jurnalele de eșec ale conectorului înregistrează ce a mers greșit; rezolvarea tipică este recrearea comenzii la terminalul POS.

Ce rulează în fundal

Un set restrâns de procese programate menține stratul de comenzi sincronizat — operatorii nu trebuie să le memoreze, dar integratorii care consumă date Fooodo ar trebui să cunoască cadențele:

Dacă POS-ul este inaccesibil, procesele reîncearcă cu backoff exponențial; comenzile se pun în coadă în starea lor curentă și se reconciliază când conectorul se recuperează.