L'asporto è un'attività diversa dalla cena al tavolo. I clienti non si siedono. Non c'è un tavolo a cui parcheggiarli. Vogliono sapere due cose: quando sarà pronto il cibo e come pagare. Qualsiasi cosa che si frapponga a quelle due domande è attrito, e l'attrito fa perdere ordini al concorrente con un processo più agevole.
Negli ultimi anni il modello di asporto si è spostato dalle telefonate e dai banconi walk-in verso un flusso di lavoro QR-e-coda che scala. I clienti prendono un numero di coda, costruiscono il loro ordine sul proprio telefono, pagano caricando una ricevuta di bonifico bancario e ritirano quando viene chiamato il loro numero. Il tutto funziona in un browser, nessuna app, nessun banco di accoglienza, nessun auricolare.
Questo articolo illustra le decisioni pratiche che fanno funzionare questo flusso di lavoro in un ristorante reale.
Prezzi separati per l'asporto
La prima decisione è se i prezzi per l'asporto debbano essere gli stessi di quelli per la cena al tavolo. In molti paesi la risposta è no. La cena al tavolo include piatti, bicchieri, servizio al tavolo e un'esperienza. L'asporto include imballaggi e il presupposto che il cliente mangerà altrove. Le strutture dei costi sono diverse, e la disponibilità a pagare è diversa.
Uno schema comune è un piccolo supplemento per l'asporto, forse del dieci-quindici per cento, per coprire gli imballaggi e il lavoro marginale di imballaggio e consegna. Alcuni ristoranti fanno il contrario e offrono un piccolo sconto per l'asporto perché risparmiano sul lavaggio dei piatti e sul turnover dei tavoli. In ogni caso, il sistema del menu deve supportare un campo prezzo separato per voce, distinto dal prezzo per la cena al tavolo, che appare solo quando il cliente sta ordinando per il ritiro.
Le voci necessitano anche di un flag di disponibilità separato per l'asporto. Alcuni piatti non si trasportano bene. Un soufflé, un delicato carpaccio, un dolce al piatto multicomponente: nessuno di questi appartiene a un menu da asporto. Dovrebbero rimanere nel menu per la cena al tavolo ma essere nascosti dall'elenco dell'asporto con un singolo pulsante, non mantenendo due menu paralleli.
La conferma dell'ordine in due fasi
L'errore classico è trattare un ordine di asporto come un checkout di un sito web, dove il cliente conferma tutto alla fine. In pratica questo fallisce perché il passaggio del pagamento è il più lento e soggetto a errori. I bonifici bancari richiedono tempo. Il cliente potrebbe inserire un importo sbagliato. La ricevuta potrebbe essere illeggibile. Se l'ordine è bloccato prima che il pagamento sia confermato, la cucina inizia a cucinare cibo per il quale il ristorante potrebbe non essere mai pagato.
Un flusso di lavoro migliore è una consegna in due fasi. Fase uno: il cliente effettua l'ordine. Il sistema registra le voci, calcola il totale e mostra un totale chiaro nella stessa valuta in cui sta pagando. Fase due: il cliente carica una ricevuta di pagamento. Fino a quando il ristorante non conferma manualmente che la ricevuta è valida, l'ordine rimane in uno stato di "attesa di conferma". La cucina non inizia. Il badge di stato del cliente dice "In attesa che il ristorante confermi il pagamento" in modo che sappia che la palla è nel campo del ristorante, non nel suo.
Sembra lento. In pratica la conferma del personale richiede dieci secondi: aprire il pannello di controllo, dare un'occhiata all'immagine della ricevuta, toccare un pulsante. La cucina vede l'ordine nel momento in cui il pagamento è confermato, non prima, che è esattamente il momento giusto.
Upload delle ricevute di pagamento che funzionano
La modalità di guasto più comune per i caricamenti delle ricevute sono i permessi. I telefoni dei clienti usano indirizzi IP casuali. Le dimensioni delle immagini variano da 200 KB a 10 MB. Alcuni clienti fanno uno screenshot dell'app bancaria, altri fotografano la ricevuta stampata con la fotocamera, altri ancora incollano un'immagine inoltrata da una chat. Il sistema di caricamento deve assorbire tutto questo senza generare errori.
Alcune regole pratiche. Primo, accettare più formati di immagine: JPEG, PNG e WebP coprono essenzialmente ogni fotocamera del telefono e strumento di screenshot. Secondo, usare URL di caricamento pre-firmati che scadono in pochi minuti, in modo che il caricamento avvenga direttamente dal telefono del cliente allo storage senza che il server sia nel mezzo. Terzo, convalidare il tipo di file lato server prima di emettere l'URL. Quarto, archiviare le ricevute in un percorso chiaramente denominato in modo da poterle verificare in seguito se un pagamento è contestato.
L'interfaccia rivolta al cliente dovrebbe essere un unico grande pulsante etichettato "Carica ricevuta di pagamento", non un modulo multi-step. Dopo il caricamento, mostrare una miniatura della ricevuta al cliente con un'opzione "Sostituisci" nel caso abbia caricato lo screenshot sbagliato. Il badge di stato dovrebbe passare immediatamente a "In attesa che il ristorante confermi" in modo che sappia che il caricamento è andato a buon fine.
Codici di riferimento per il ritiro
Quando il cliente arriva a ritirare, è necessario un modo rapido per abbinare il suo telefono all'ordine sullo schermo. Chiamare un numero di coda funziona in un ristorante tranquillo, ma fallisce in un negozio di bubble tea rumoroso con cinque numeri 12 in fila.
Un codice di riferimento breve, sei caratteri da un set di caratteri privo di ambiguità, risolve questo problema. Lo si generi lato server al momento dell'inserimento dell'ordine. Lo si mostri sul telefono del cliente accanto al numero di coda. Lo si mostri anche nel pannello di controllo del personale. Quando il cliente arriva, mostra il telefono, si confrontano i codici e si consegna il sacchetto. L'intero scambio richiede tre secondi e non dipende mai da nomi urlati.
Il codice di riferimento funge anche da anti-frode. Un cliente non può affermare "sono il numero 42" senza mostrare il codice che corrisponde al numero 42. Due persone casuali non possono collidere sullo stesso codice nello stesso giorno in nessuno scenario plausibile.
Riconciliazione di fine giornata
I ricavi dell'asporto devono riconciliarsi con i bonifici bancari ogni giorno. Il modo più semplice per farlo è una visualizzazione Storico nel pannello di controllo della coda che elenca ogni ordine contrassegnato come Servito in un determinato giorno, con il numero di coda, il codice di riferimento, l'orario, il totale e un link all'immagine della ricevuta. Si scelga una data, si veda l'elenco, si veda il totale giornaliero, lo si incrocia con l'estratto conto bancario. Cinque minuti al giorno, idealmente come parte della routine di chiusura.
Lo storico deve gestire correttamente il fuso orario. Un ristorante a Bangkok che chiude a mezzanotte ora locale dovrebbe vedere tutti gli ordini di quel giorno di calendario raggruppati insieme, non divisi a mezzanotte UTC nel mezzo del servizio serale. Il sistema dovrebbe conoscere il paese del ristorante e usare il fuso orario locale per il raggruppamento.
Cosa fare quando qualcosa va storto
In qualsiasi flusso di lavoro reale, si verificano casi limite. Il cliente paga l'importo sbagliato. La ricevuta è illeggibile. Il cliente non si presenta. La cucina esaurisce una voce tra l'ordine e la conferma.
Per ciascuno di questi, si progetti un percorso chiaro. Importo sbagliato: il personale apre l'ordine, vede il problema e accetta un pagamento parziale con una nota oppure chiede al cliente di ripagare. Ricevuta illeggibile: il personale contatta il cliente (se si ha il suo numero di telefono) o semplicemente non conferma; il cliente nota che il suo stato è bloccato e ri-carica. Mancata presentazione: la voce della coda rimane in "in preparazione" fino a quando non viene contrassegnata manualmente come Servita o Annullata, a quel punto esce dall'elenco attivo.
L'esaurimento delle scorte tra l'ordine e la conferma è il caso più doloroso. La risposta più pulita è un rimborso rapido al conto bancario del cliente, con le scuse e una nota. I sistemi dovrebbero rendere questo semplice: un pulsante Annulla sull'ordine che si può usare dopo aver visto la ricevuta, con il telefono del cliente che riflette immediatamente la cancellazione.
Non ottimizzare il percorso ideale in modo eccessivo
La tentazione quando si progetta un flusso di asporto è assumere che ogni ordine vada alla perfezione, e progettare l'interfaccia di conseguenza. Questa è una trappola. La maggior parte degli ordini va alla perfezione, ma quelli che vanno male consumano tempo sproporzionato e creano il maggior lavoro di customer service. Si costruisca il flusso di lavoro attorno ai casi negativi per primi, e quelli positivi si gestiranno da soli.
Un badge di stato chiaro che il cliente può leggere in tre secondi. Un pannello di controllo che mostra tutto ciò di cui il personale ha bisogno a colpo d'occhio. Codici di riferimento per consegne rapide. Una visualizzazione storico per la riconciliazione di fine giornata. Più un'aspettativa predefinita che alcuni ordini richiederanno un intervento manuale, e che il sistema rende quell'intervento facile piuttosto che impossibile. Faccia bene tutto questo e avrà un'operazione di asporto che scala.
