Nell'articolo precedente abbiamo parlato di distribuire i clienti sui vari orari della serata. Qui facciamo un passo indietro e guardiamo il motore: come un sistema decide se c'è posto. È lì che si vede se un software di prenotazioni è buono.
Prima scena. Venerdì, le sette e mezza. Una coppia prenota dal sito: un tavolo per due alle nove. Risposta: «completo». Tu, in sala, sai che alle nove ci sono tre tavoli che si libereranno molto prima. Il sito non lo sa, e la coppia ha già prenotato altrove.
Seconda scena, in un altro locale. Un cliente prenota dal sito un tavolo per quattro alle otto e mezza. Nello stesso momento un altro prenota al telefono per sei, sempre alle otto e mezza. Sulla carta tutti e due hanno un tavolo: in sala ce n'è uno solo adatto. Qualcuno aspetterà al bancone, e non sarà contento.
Sono due facce dello stesso problema. Nel primo caso dici no a chi potevi far sedere. Nel secondo dici sì a chi non puoi far sedere. Un buon sistema deve evitare il secondo, sempre, e ridurre il più possibile il primo.
Questa è la base, e non è negoziabile. Tutte le prenotazioni, quelle del sito, quelle del telefono, quelle che scrivi tu a mano al banco, devono finire nello stesso registro. Un solo registro, non due agende che si sincronizzano ogni tanto.
Poi c'è il caso più subdolo: due clienti che prenotano nello stesso istante l'ultimo tavolo disponibile. In un sistema fatto bene ci riesce uno solo. L'altro vede subito che quell'orario non è più libero e gli vengono proposti altri orari. Nessuno riceve una conferma che poi bisogna ritirare.
Sembra ovvio, ma non lo è. Quando sito e telefono hanno due agende separate, o quando il sito controlla la disponibilità e conferma in due momenti diversi, la doppia prenotazione è questione di tempo. Un software che non garantisce questo punto non andrebbe usato, qualunque altra cosa sappia fare.
Garantire che non ci siano doppioni è facile: basta essere prudenti e dire «completo» al primo dubbio. Il guaio è che così si rifiutano clienti che potevi far sedere, e ogni cliente rifiutato a torto è un incasso perso, spesso per sempre. Il secondo livello è questo: dentro il vincolo di non sbagliare mai, far entrare più gente possibile.
Le prenotazioni arrivano una alla volta, in ordine sparso, e ogni volta che assegni un tavolo a qualcuno cambi le possibilità di tutti quelli che arriveranno dopo.
Il metodo tradizionale è semplice: appena arriva una prenotazione, le dai un numero di tavolo e quello resta suo. Prima arrivata, prima sistemata. Lo fa il quaderno. E funziona, finché la sera è tranquilla.
Quando si riempie, il metodo mostra il suo limite. Un esempio da sabato sera: tre persone prenotano per prime e prendono il tavolo da sei, perché era il primo libero. Più tardi telefona una famiglia di sei. Non c'è più nessun tavolo adatto: «siamo pieni». Con un'altra sistemazione, i tre sarebbero stati a un tavolo da quattro e la famiglia avrebbe avuto il suo.
Altro esempio: due tavoli da due vengono prenotati separatamente da due coppie. Poi arrivano quattro amici, che avrebbero potuto sedersi unendo i due tavoli. Ma i due tavoli sono già «di qualcuno», e il sistema risponde di no.
In entrambi i casi la sala avrebbe potuto ospitare tutti. Il sistema non ha sbagliato un calcolo: ha preso una decisione troppo presto. Il tavolo è stato fissato nel momento in cui il cliente ha prenotato, quando non si sapeva ancora chi sarebbe arrivato dopo.
C'è poi un secondo problema, più umano. Le combinazioni possibili di tavoli, orari e gruppi, in una sera piena, sono così tante che nessuno riesce a tenerle in testa mentre risponde al telefono. Neanche il ristoratore più esperto. È un lavoro da macchina.
Quello che puoi aspettarti da un buon sistema si riassume in poco. Fa sedere più clienti di quanti ne farebbe sedere dando a ogni prenotazione il primo tavolo libero. Risponde a un cliente in pochi secondi. E non sposta mai chi è già seduto, né un tavolo che hai scelto tu a mano.
Alla fine, tutto si riduce a una domanda:
quando il sistema dice «completo», è davvero completo?
Un buon sistema rifiuta un cliente solo quando, in qualsiasi modo si disponga la serata, quel cliente non ci sta. E non dovrebbe vendere due volte lo stesso tavolo. Se un sistema rifiuta prima di aver provato le altre sistemazioni, ti costa clienti. Se accetta senza controllare, ti costa serate rovinate. Un buon software sta nel mezzo, e questo dipende da come è progettato, non da quante funzioni elenca sulla brochure.
Ecco cosa chiedere a chi te lo vende. Non servono prove da fare in casa: sono domande sulla progettazione, e un fornitore serio sa rispondere.
Se ne vuoi una quarta, chiedi in quanto tempo risponde il sito al cliente. La risposta giusta si conta in secondi.
Se una risposta è vaga, o se è «prima arrivata, prima sistemata e basta», sai già come si comporterà il sistema il sabato sera, quando conta di più. Se invece le risposte sono precise, hai davanti un fornitore che ha pensato al problema vero.
Bientenu è un software di prenotazione per piccoli ristoranti. Nelle nostre simulazioni, circa 125.000 prenotazioni online non hanno prodotto nemmeno una prenotazione di troppo, e in un ristorante di medie dimensioni (15–20 tavoli) i clienti rifiutati a torto si dimezzano rispetto a un metodo che assegna un tavolo a ogni prenotazione in ordine di arrivo. Sono simulazioni nostre, non uno studio indipendente: in un locale vero i numeri dipendono dalla sala e dai clienti.
Guarda la demo oppure provalo con il tuo ristorante.
