Flussi degli ordini — Pay-First vs Pay-Later
Quando utilizzare Pay-First o Pay-Later, come si comporta ciascuno dall'inizio alla fine, gli stati degli ordini che gli operatori vedono nell'admin e i job in background che mantengono gli ordini sincronizzati con il POS.
Fooodo supporta due flussi di ordine distinti. Si differenziano per quando la cucina vede l'ordine e quando avviene il pagamento. La scelta dipende dallo stile di servizio, non dal ristorante — un singolo ristorante può eseguire flussi diversi su tavoli diversi.
- 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
I flussi di ordine di Fooodo comunicano con il tuo POS attraverso un contratto di connettore. R-Keeper è il connettore di riferimento attivo oggi — i meccanismi descritti di seguito illustrano ciò che ogni implementazione di connettore deve soddisfare.
Pay-First
Utilizza Pay-First quando gli ospiti devono pagare prima che il servizio inizi: asporto, servizio rapido, food court. La cucina non vede mai un ordine non pagato; il POS riceve un'unica esportazione per carrello; se un ospite abbandona il carrello, nulla raggiunge la linea.
Pay-Later
Utilizza Pay-Later per il servizio al tavolo e il servizio a più portate. Il primo giro viene inviato al POS nel momento in cui viene confermato; i giri successivi vengono aggiunti allo stesso ordine POS uno alla volta. L'ordine rimane aperto nel POS dal primo giro fino a quando il pagamento lo chiude. Internamente, Fooodo tiene traccia degli articoli già inviati in modo che ogni giro venga sincronizzato una sola volta.
Perché i flussi sono diversi
La differenza meccanica è piccola — Pay-First effettua un'unica esportazione verso il POS, Pay-Later ne effettua molte. La differenza operativa è più rilevante:
- Con Pay-First, la cucina non ha lavoro aggiuntivo se un ospite abbandona il carrello. Tuttavia, l'esperienza dell'ospite non è adatta al servizio al tavolo: le persone si aspettano di pagare alla fine; chiedere il pagamento in anticipo risulta transazionale, non ospitale.
- Con Pay-Later, l'esperienza dell'ospite corrisponde a quella di un normale ristorante. L'operatore accetta un piccolo rischio che un ordine possa non essere pagato (un ospite se ne va, una carta fallisce) — lo stesso rischio che esiste oggi con qualsiasi servizio con conto cartaceo.
Molte catene iniziano con Pay-First ai banconi dell'asporto, per poi introdurre Pay-Later ai tavoli del servizio al tavolo una volta che il personale ha familiarità con l'admin.
Configurazione del flusso
Il flusso viene impostato per singolo tavolo o come impostazione predefinita del ristorante nel pannello admin. Un ristorante può combinare i flussi — ad esempio, tavoli del servizio al tavolo con Pay-Later, bancone dell'asporto con Pay-First, entrambi gestiti attraverso la stessa installazione di Fooodo.
Stati, in pratica
Gli ordini si spostano attraverso una macchina a stati. I nomi riportati di seguito sono esattamente quelli che appaiono nel pannello admin — utili sia per gli operatori che leggono i propri ordini sia per gli integratori che consumano gli eventi degli ordini.
Gli stati più importanti per gli operatori:
| Stato | Significato |
|---|---|
Created | Il carrello esiste, nessun articolo ancora confermato |
InProgress | Articoli inviati al POS, in attesa di ulteriori aggiunte o del pagamento |
ReadyToBePaid | L'ospite ha terminato di ordinare, pagamento in sospeso |
Paid | Pagamento riuscito, il POS ha registrato il pagamento |
Finished | Ordine chiuso, stato finale di successo |
Gli stati correlati agli errori:
| Stato | Significato |
|---|---|
Locked | Il POS ha l'ordine aperto (un cameriere lo sta modificando). Nuovi tentativi automatici con backoff. |
Error | L'esportazione verso il POS è fallita dopo tutti i tentativi. Richiede intervento manuale. |
Cancelled | L'ordine è stato annullato o è scaduto senza pagamento |
La maggior parte degli stati Locked si risolve in pochi secondi. Un Locked persistente di solito significa che un cameriere ha l'ordine aperto nel POS e ha dimenticato di chiuderlo.
Error è l'unico stato che richiede attenzione umana. I log degli errori del connettore registrano cosa è andato storto; la risoluzione tipica consiste nel ricreare l'ordine al terminale POS.
Cosa viene eseguito in background
Un piccolo insieme di job pianificati mantiene il livello degli ordini sincronizzato — gli operatori non hanno bisogno di memorizzarli, ma gli integratori che consumano dati di Fooodo dovrebbero conoscere le cadenze:
| Cadenza | Job |
|---|---|
| Ogni minuto | Verifica della disponibilità del ristorante |
| Ogni minuto | Annullamento degli ordini scaduti senza pagamento |
| Ogni 2 min | Recupero degli aggiornamenti degli ordini dal POS |
| Ogni 4 min | Recupero dello stato dei tavoli dal POS |
| Ogni 5 min | Sincronizzazione della disponibilità degli articoli |
| Ogni giorno alle 09:00 | Sincronizzazione completa del menu |
Se il POS non è raggiungibile, i job riprovano con backoff esponenziale; gli ordini rimangono in coda nel loro stato corrente e vengono riconciliati quando il connettore si ripristina.
Architettura di Fooodo
Come è costruito Fooodo — la suddivisione in due servizi tra app menu e servizio di pagamento, il modello multi-tenancy azienda/ristorante/tavolo, il contratto di connettore POS-agnostico e dove si colloca UVS.
Connettore R-Keeper
L'implementazione di riferimento live del contratto di connettore POS di Fooodo — quali dati attraversano il confine, le cadenze di sincronizzazione, i prezzi fedeltà e come i fallimenti vengono ritentati in produzione.