Database clienti ristorante: costruirlo in automatico

Il database clienti di un ristorante si costruisce da solo, a una condizione: che le prenotazioni entrino già in forma digitale. Ogni telefonata gestita dall'agente vocale, ogni chat WhatsApp e ogni form compilato lasciano nome, numero, data e coperti nella stessa scheda. A te resta una cosa sola da fare bene: raccogliere il consenso giusto al momento giusto. E sapere cosa quel consenso ti permette di fare dopo.

Quasi ogni locale ha già un archivio clienti. Solo che è sparso. I numeri stanno nella rubrica del telefono di sala, i nomi sul quaderno delle prenotazioni, le email dentro il portale che gestisce le prenotazioni online. I gruppi ricorrenti vivono nella testa del maître. Dati che esistono e che non puoi usare, perché nessuno li può interrogare insieme. Ecco perché a gennaio nessuno sa dire quanti clienti sono tornati tre volte l'anno prima.

Database clienti

È l'anagrafica unica del locale: una scheda per persona, alimentata da tutti i canali di prenotazione, con lo storico delle visite e le preferenze. Si distingue dall'elenco di contatti perché non è una lista piatta di numeri, ma un insieme di schede che tengono la memoria del rapporto. Quante volte è venuto, con quante persone, cosa non mangia, da dove è arrivato la prima volta.

Perché il database clienti del ristorante non si costruisce a mano?

Perché l'inserimento manuale salta al primo sabato pieno. Chiunque abbia provato a compilare un file Excel dei clienti sa già come finisce: due settimane di disciplina, poi un servizio difficile e la colonna resta vuota per sempre. È la prima cosa che si molla quando la sala si riempie, ed è esattamente allora che arrivano i clienti che varrebbe la pena registrare.

L'alternativa è smettere di considerare l'anagrafica un'attività a parte. Se la prenotazione nasce già in forma di dato, la scheda esiste automaticamente: nome e numero arrivano dal canale, la data e i coperti dall'agenda, e la visita successiva si attacca alla stessa persona perché il numero coincide. Nessuno digita niente. L'archivio cresce alla velocità del servizio.

Da quali canali arriva il database clienti del ristorante?

Da quattro rubinetti, e tre di questi non chiedono lavoro in più a nessuno.

I primi tre rubinetti sono automatici: agente vocale al telefono, chat e form di prenotazione sul sito. Non chiedono nulla in più a chi lavora. Il quarto chiede una piccola disciplina: annotare sulla scheda l'allergia, il tavolo preferito, l'abitudine. Che quel signore venga sempre con la moglie il giovedì lo sa solo chi era in sala, e nessun sistema può dedurlo.

Il punto critico è che tutti e quattro scrivano nello stesso posto. Quattro canali con quattro archivi diversi producono lo stesso caos di prima, solo digitale. È la ragione per cui il database clienti di un ristorante vive dentro un CRM per ristoranti collegato all'agenda, non in uno strumento a fianco.

Quali dati salvare nel database clienti del ristorante?

La tentazione è raccogliere tutto. È un errore: ogni campo in più è un campo che nessuno compila e un dato in più da proteggere. Il set minimo che serve davvero sta in poche voci.

• Nome e numero di telefono, con il prefisso internazionale. Il numero è la chiave: è quello che unisce le visite di anni diversi in una sola scheda.
• Email, quando il cliente la lascia spontaneamente. Serve per i contenuti lunghi, non per i messaggi rapidi.
• Storico visite: data, coperti, canale di prenotazione, servizio (pranzo o cena).
• Preferenze e restrizioni: allergie, intolleranze, tavolo, piatto abituale.
• Consenso al marketing, con data e origine. Non è un dettaglio burocratico, è la riga che ti autorizza a fare tutto il resto.

Fuori restano i dati che non ti servono e che alzano il rischio. Documenti, dati di pagamento conservati in chiaro, note personali su chi paga poco o si lamenta. Se un campo non lo useresti mai per prendere una decisione, non raccoglierlo.

Ogni canale di prenotazione scrive nella stessa scheda cliente, invece di alimentare archivi separati.

Serve il consenso per scrivere ai clienti del ristorante?

Dipende da cosa scrivi, e la distinzione è netta. Registrare la prenotazione di una persona è trattamento necessario per erogare il servizio, e non richiede una firma su un modulo. Mandarle un messaggio promozionale sei mesi dopo è un'altra faccenda. Lì serve un consenso specifico, libero e documentato, come chiede il Regolamento europeo sulla protezione dei dati.

In pratica significa quattro cose, tutte semplici da rispettare se le imposti all'inizio.

Il consenso al marketing va chiesto separatamente dalla prenotazione, con una casella non prespuntata e una frase che dice cosa riceverà e su che canale. Deve essere altrettanto facile tornare indietro: un modo evidente per dire basta, e la richiesta va onorata subito, non alla campagna dopo.

Vale il principio di minimizzazione: raccogli solo quello che ti serve davvero, e tienilo per il tempo in cui ha senso. Una scheda ferma da cinque anni, senza visite né interazioni, non è un patrimonio. È un rischio inutile.

Infine, le liste comprate o rastrellate altrove non si usano. Mancano di base giuridica, ti espongono a segnalazioni e sui canali di messaggistica bruciano la reputazione del numero. Nessuna scorciatoia vale questo prezzo.

Dai dati ai segmenti che si usano davvero

Un database clienti del ristorante serve quando lo puoi tagliare. Bastano quattro segmenti per coprire quasi tutto: prima visita, in costruzione, habitué, a rischio. Conviene usare i nomi di una tassonomia sola, quella descritta in retention marketing per ristoranti.

Tutti e quattro si ricavano da due campi che hai già: il numero di visite e la data dell'ultima. Gli habitué sono il gruppo da proteggere e la base naturale del programma fedeltà. Chi finisce nel segmento a rischio va lavorato con un messaggio personale, ed è il tema di riattivare i clienti dormienti. Le soglie che separano un gruppo dall'altro non sono universali e vanno lette sul ritmo reale dei tuoi clienti.

Ogni segmento vuole un canale suo. E prima del canale conta il consenso: puoi scrivere solo a chi ha detto sì, e solo dove ha detto sì. Su come si scrive alla lista una volta che i segmenti esistono, il quadro sta in email marketing per ristoranti.

Gli errori che rendono inutile il database clienti di un ristorante

Tre cose svuotano di senso un database anche ben popolato. I duplicati nascono quando lo stesso cliente entra da due canali con due formati di numero diversi. La deduplica va quindi fatta in automatico sul numero normalizzato, altrimenti la tua cliente più fedele risulta venuta una volta sola per cinque persone diverse.

Gli export personali sono il secondo. Il file scaricato sul portatile di qualcuno, aggiornato una volta e mai più, continua a girare come se fosse la verità. La verità sta in un posto solo, ed è quello collegato all'agenda.

Il terzo è la dipendenza da un archivio che non controlli. Se i contatti vivono dentro un portale di prenotazione, quei clienti sono suoi prima che tuoi, e il giorno che cambi strumento non te li porti dietro. È l'argomento centrale di chi cerca un'alternativa a TheFork. I tuoi clienti restano tuoi solo se le loro schede stanno in casa tua.

Il primo rubinetto da collegare

Non serve un progetto. Serve chiudere il rubinetto che perde. Scegli il canale da cui arrivano più prenotazioni oggi e fai in modo che scriva in anagrafica da solo, con la casella del consenso nello stesso passaggio. Poi lascialo lavorare: in una settimana avrai le prime schede vere, in un mese abbastanza storico per riconoscere gli habitué.

Poi una sera succede una cosa piccola. Qualcuno prenota, e sullo schermo compare il nome con accanto il numero di visite e l'allergia della volta scorsa. Nessuno ha dovuto ricordarsela: da lì in avanti il database clienti del ristorante lavora al posto della memoria di chi sta in sala.