Ramen Joe è nato come ristorante a Lisbona. Oggi sono cinque locali, un'app iOS pubblicata sull'App Store, un'app Android pubblicata su Google Play, un programma fedeltà con Apple Wallet e Google Wallet, e un back-office che governa le operazioni del gruppo. Tutto poggia su un'unica piattaforma.
Questo pezzo racconta cosa quella piattaforma ha risolto, cosa è costato costruirla invece di comprare un SaaS pronto all'uso, e dove sbaglia la maggior parte dei gruppi di ristorazione quando prova a fare lo stesso.
Sintesi esecutiva
Un gruppo di ristorazione con più di due sedi ha, tipicamente, tre problemi tecnici che nessuno dimensiona bene all'inizio. Prenotazioni frammentate per locale. Programma fedeltà che non segue il cliente tra i locali. Dati operativi che vivono in file locali e chat di WhatsApp.
Ramen Joe ha consolidato l'operatività in un solo sistema. Prenotazioni condivise, cliente unico, fidelizzazione, menù digitale, gestione dello staff e analisi centralizzata. Il risultato pratico è che il cliente che timbra a Lisbona vede lo stesso saldo a Porto, mentre il team amministra cinque locali — e può aggiungerne di nuovi — dallo stesso back-office.
Il costo di questa scelta non è banale. Ma il costo di non farla arriva dopo, travestito da churn, da staff che ripete lavoro e da decisioni di espansione prese alla cieca.
Il problema di business
Quando un singolo ristorante diventa un gruppo, il software che andava bene per un locale inizia a rompersi. Non perché sia scadente. Perché è stato pensato per un contesto che ormai non è più il tuo.
Il sintomo classico: ogni sede finisce con il proprio modulo di prenotazioni, spesso agganciato a Google o a un tool SaaS specifico. I clienti fidelizzati vivono in un database per locale, o peggio, in un quaderno cartaceo. Quando vuoi sapere quanti clienti ricorrenti hai nel gruppo, non c'è risposta. Solo stime.
Il punto critico è questo. In un locale solo, il CRM è il gestore. Conosce gli abituali, sa chi preferisce il tavolo in fondo, sa chi porta la famiglia la domenica. In cinque locali, quella memoria distribuita smette di funzionare. E il cliente lo nota.
Perché tutto questo conta
La fidelizzazione in ristorazione non è un dettaglio operativo. È la spina dorsale del modello. Il costo di acquisizione di un cliente nuovo è molte volte superiore al costo di riportare indietro un cliente esistente. Vale in quasi tutti i settori, e la ristorazione non fa eccezione.
Se il tuo programma fedeltà non segue il cliente tra i locali, stai trattando ogni visita come se fosse la prima. Non lo è. Il cliente se lo ricorda. Il sistema no.
Il secondo angolo è operativo. Un gruppo con cinque locali genera abbastanza dati per prendere decisioni di business informate. Quali orari si riempiono per primi. Quali giorni della settimana hanno bisogno di campagne. Quale sede ha più no-show. Senza una piattaforma unica, questi dati esistono, ma nessuno riesce a leggerli.
Cosa fa la piattaforma
L'architettura di Ramen Joe poggia su tre blocchi che dialogano tra loro. Un backend Express con database relazionale, un frontend Next.js pubblico per i clienti finali, e una serie di app native (iOS SwiftUI e Android) che replicano l'esperienza del sito in contesto mobile.
La scelta di avere app native invece di una PWA merita una spiegazione. Non è vanità tecnica. È stata una decisione di prodotto motivata da tre cose concrete.
- Apple Wallet e Google Wallet si integrano in modo pulito nelle app native — la carta fedeltà finisce direttamente nel wallet del telefono e riceve aggiornamenti automatici quando il saldo cambia.
- Le push notification su iOS hanno restrizioni che il web non consente di aggirare senza peggiorare l'esperienza.
- Il tap-to-scan dello staff nei ristoranti richiede una fotocamera con autofocus rapido e latenza quasi zero. Il web qui perde ancora.
Sul fronte delle prenotazioni, il sistema è disaccoppiato dal calendario di ogni locale. Quando un cliente prenota a Lisbona, il tavolo viene bloccato solo a Lisbona. Ma la scheda cliente, lo storico, la preferenza di tavolo — tutto questo è globale.
Menù digitale ed espansione senza dipendenza tecnica
La piattaforma centralizza anche il menù digitale delle cinque sedi. Il team gestisce prodotti, informazioni e configurazione di ogni locale nello stesso back-office, mantenendo l'esperienza coerente su sito e app senza duplicare il lavoro per canale.
La gestione multi-sede è stata progettata perché la crescita del gruppo non dipenda da un nuovo intervento tecnico. Il team stesso può registrare una sede, definire orari, contatti, menù, tavoli, regole di prenotazione e le altre configurazioni operative.
Una volta configurata, la nuova sede diventa disponibile sul sito e nelle applicazioni mobili a partire dalla stessa sorgente dati. Non serve sviluppare una nuova versione del sito o delle app solo per aggiungere un locale. Questo riduce il costo e il tempo tra la decisione di espansione e l'ingresso della nuova sede nei canali digitali.
Fidelizzazione tra i locali: la decisione che cambia tutto
Il punto di attrito più comune nei gruppi di ristorazione è questo. Ogni locale vuole avere il proprio programma. Ogni gestore vuole vedere i propri clienti fidelizzati. E ogni campagna di marketing tende a restare intrappolata in una sede.
Ramen Joe ha scelto l'opposto. Un solo programma, un solo portafoglio di punti, un solo cliente. Questo ha implicazioni non banali sul piano contabile — chi "paga" per il timbro dato a Lisbona e riscattato a Porto? — ma si risolve con regole interne di imputazione, non con la frammentazione del sistema.
Il cliente non dovrebbe doverci pensare. E, in effetti, non ci pensa. Installa l'app una volta, aggiunge la carta al Wallet, e l'esperienza è la stessa in qualsiasi locale del gruppo. Questo è product-market fit applicato alla fidelizzazione.
Il ruolo dello staff
Un sistema di fidelizzazione digitale funziona solo se lo staff collabora. Se timbrare digitalmente richiede più tempo del vecchio timbro su carta, lo staff sabota — non per cattiva volontà, ma per sovraccarico nelle ore di punta.
Lo scanner di Ramen Joe è stato progettato con questo vincolo in mente. Il membro dello staff loggato apre l'app, punta la fotocamera al QR del cliente, e il timbro viene assegnato in meno di due secondi. Nessun menu, nessuna conferma intermedia, niente da digitare.
Il permesso di timbrare è separato dal permesso di accedere al back-office. Un cameriere timbra. Un gestore consulta i report. Un amministratore del gruppo modifica le regole. Questa separazione è banale nel SaaS aziendale, ma viene spesso ignorata nel software per la ristorazione — e poi ci si chiede perché è avvenuta una frode interna sui punti.
Prenotazioni: meno automazione, più controllo
C'è una tentazione in qualsiasi sistema di prenotazioni moderno: automatizzare tutto. Conferma automatica, promemoria automatico, risposta automatica alle modifiche. Nella maggior parte dei casi, funziona bene.
Nella ristorazione di qualità funziona meno bene. Una prenotazione per dodici persone il sabato sera non dovrebbe essere confermata in automatico senza che qualcuno guardi la sala. Una richiesta di tavolo specifico dovrebbe passare per qualcuno che conosce il locale. E le eccezioni dell'ultimo minuto richiedono un umano.
La piattaforma di Ramen Joe permette entrambi i modelli, locale per locale. Le prenotazioni standard sono automatiche. Quelle grandi o con richieste speciali entrano in una coda di approvazione. E c'è un canale SMS via Telnyx che invia promemoria un'ora prima della prenotazione, riducendo i no-show senza generare spam.
L'SMS è breve per scelta. Nome, orario, locale. Un link per cancellare. Nient'altro. Il pacchetto commerciale è stato dimensionato con una stima iniziale di 1.500 SMS all'anno, calcolata a partire dal volume atteso di prenotazioni. Non è un limite tecnico: la capacità può essere ricalibrata mentre l'operatività cresce.
Le app: iOS e Android lanciate in contemporanea
Le versioni per iOS e Android sono state lanciate in contemporanea. L'app Android è arrivata dopo perché il processo di revisione di Google Play ha richiesto più tempo, non per una scelta di rilascio a fasi o per privilegiare una piattaforma.
Le due applicazioni sono state sviluppate in parallelo, con la stessa proposta di valore: prenotazioni, fidelizzazione ed esperienza coerente sulle due piattaforme. La differenza nel momento in cui sono diventate visibili sugli store è dipesa solo dai tempi di approvazione di ciascun marketplace.
Il costo è evidente: due codebase native invece di un framework cross-platform come React Native o Flutter. È stato un trade-off consapevole. Il guadagno è un'app che si comporta come chiede la piattaforma, non come consente il minimo comune denominatore.
Cosa va storto in questi progetti
La maggior parte dei gruppi di ristorazione che prova a costruire una piattaforma così commette gli stessi tre errori. Vale la pena nominarli.
- Partono dall'app. Senza un backend maturo e senza regole di business chiare, l'app diventa un guscio elegante che replica il caos operativo su schermi mobili.
- Si affidano a plugin WordPress per prenotazioni e fidelizzazione. Regge per un locale. Salta a cinque.
- Ingaggiano agenzie che costruiscono a progetto e poi spariscono. Il software non finisce al lancio. Lì inizia.
L'antidoto per tutti e tre è lo stesso. Tratta il software come infrastruttura, non come campagna. Investi prima nelle fondamenta — backend, database, autenticazione, permessi, deploy continuo — e solo dopo nella superficie visibile.
Buone pratiche che sono valse la pena
Alcune decisioni sembrano minori ma hanno avuto un impatto sproporzionato sul funzionamento del sistema in produzione.
Primo: git come unica fonte di verità. Ogni modifica passa da un commit, ogni deploy è automatico via GitHub Actions. Questo elimina la categoria di bug del "funziona sul mio computer" e permette di tornare indietro in pochi minuti se qualcosa si rompe in produzione. La documentazione ufficiale di GitHub sul continuous deployment copre bene i principi.
Secondo: internazionalizzazione fatta sul serio. Il sito funziona in portoghese e inglese, con stringhe centralizzate in file di traduzione. Sembra eccessivo per un ristorante a Lisbona, finché non ti rendi conto che il 30% dei clienti nelle zone turistiche non parla portoghese. E che espandersi in una nuova città è più semplice quando il sistema supporta già più lingue.
Terzo: separare sandbox e produzione con regole chiare. Ramen Joe ha una versione sandbox che rispecchia la produzione ma con dati di test. Qualsiasi modifica passa prima da lì. Questo riduce la probabilità di rompere una prenotazione reale mentre si prova una nuova funzionalità.
Dove si applica questo modello
L'architettura di Ramen Joe non è specifica del ramen. Si applica a qualsiasi attività di retail o hospitality con più sedi e una base di clienti ricorrenti. Gruppi di ristoranti, catene di caffetterie, reti di barbieri, cliniche con più unità, palestre con più di un polo.
Il denominatore comune è questo: il cliente è uno solo, ma l'operatività è distribuita. Se il tuo software non riflette questa realtà, stai pagando in attrito operativo quello che dovresti guadagnare in fidelizzazione.
Key takeaways
- Un gruppo di ristorazione con più locali ha bisogno di una piattaforma unificata — le prenotazioni frammentate costano più del software per consolidarle.
- Una piattaforma davvero multi-sede permette di registrare nuove sedi, menù e regole operative senza chiedere modifiche tecniche al sito o alle app.
- La fidelizzazione tra i locali non è opzionale se vuoi retention reale. Al cliente non importa in quale locale ha speso.
- Le app native si giustificano quando Wallet, push notification e fotocamera rapida sono parte centrale dell'esperienza.
- Lo staff è utente del sistema tanto quanto il cliente. Se il flusso richiede più tempo del vecchio processo, il sistema viene sabotato per sovraccarico.
- Git come unica fonte, sandbox separato dalla produzione e i18n dal primo giorno. Sono decisioni di fondazione che evitano refactor costosi più avanti.
- L'errore più caro è partire dall'app prima di avere un backend maturo.
Il passo naturale successivo per un gruppo in questa fase non è aggiungere altre funzionalità. È misurare. Quali timbri si convertono in una seconda visita. Quali locali trattengono meglio. Quali campagne muovono davvero l'ago. Una piattaforma unificata rende possibile questa analisi. Poi è questione di guardare.