Un POS alberghiero viene valutato in base a un criterio che un registratore di cassa da ristorante non deve mai soddisfare: deve addebitare l’importo sul conto dell’ospite corretto, nel centro di ricavo del punto vendita giusto, prima che l’audit notturno chiuda la giornata. Se si commette un errore, il denaro non scompare, ma si trasforma semplicemente in un lavoro di riconciliazione per qualcuno alle 3 del mattino. Ecco perché il software che gestisce un bistrot nella hall, un bar a bordo piscina e una sala banchetti è ben diverso da quello che gestisce un bar in centro, ed ecco perché le liste dei candidati per le piattaforme POS alberghiere tendono a svanire nel momento in cui qualcuno chiede come vengono effettivamente registrate le spese delle camere.
La maggior parte delle strutture non si pone questa domanda perché desidera nuovi registratori di cassa. Se ne parla perché quelli vecchi sono diventati un peso: un server in cantina che nessuno vuole toccare, quattro punti vendita con quattro database di menu e un contratto di assistenza che fa sì che un guasto del sabato sera diventi un problema del lunedì mattina. Un moderno sistema POS per ristoranti fornito dal cloud risolve una serie specifica di questi problemi e, onestamente, ne lascia alcuni irrisolti. Questo è un tentativo di chiarire quali siano gli uni e quali gli altri.
Attenzione a ciò che i fornitori chiamano «integrazione»
Prima di addentrarci nei dettagli operativi, un avvertimento che vi farà risparmiare un ciclo di approvvigionamento. Quasi tutti i fornitori di POS che operano nel settore dell’ospitalità vi diranno di integrarsi con il vostro sistema di gestione della struttura. Il termine copre una gamma che va da «interfaccia bidirezionale certificata, attiva in 400 hotel» a «possiamo esportare un file CSV che il vostro revisore notturno inserisce manualmente». Entrambe le soluzioni vengono descritte come «integrazione» in una presentazione.
Non esiste un registro neutrale da consultare, quindi spetta a voi fare le verifiche: chiedete il nome del programma di certificazione, il numero di versione e due strutture di riferimento che utilizzino esattamente il vostro PMS con la vostra esatta combinazione di punti vendita. Se la risposta consiste in un logo del partner anziché in un numero di versione, consideratela come se l’integrazione non fosse stata realizzata. Ho visto un resort scoprire, nella terza settimana di implementazione, che l’«integrazione con Opera» significava un file batch notturno, che è una cosa utile da avere ma inutile quando un ospite è al bar e vuole firmare per la camera 412.
Il conto deve essere registrato su un folio, non solo su una carta
In un ristorante, il conto può concludersi in diversi modi: carta, contanti, buono, omaggio. In un hotel, c’è una quinta opzione che supera le altre nella maggior parte dei punti vendita, ed è proprio quella che complica il funzionamento del POS alberghiero. L’ospite firma e l’addebito viene indirizzato al suo conto per essere saldato al momento del check-out.
Per farlo correttamente, il POS deve rispondere a domande a cui non può rispondere da solo. La camera 412 è occupata stasera? Il nome appena fornito dall’ospite corrisponde a quello dell’ospite registrato? Esiste un limite di credito e questo conto lo ha già superato? Questo addebito deve essere indirizzato al conto personale dell’ospite o a un conto aziendale che copre solo la camera e la colazione? Questo ospite ha un pacchetto in cui sono già incluse due colazioni al giorno?
Tutte queste risposte si trovano nel PMS. Pertanto, il modello mentale più utile non è «POS più un’integrazione». È piuttosto che il POS sia un terminale collegato al registro degli ospiti, e la qualità di tale connessione determina il limite massimo di efficienza con cui i punti vendita possono operare. Un POS cloud non è automaticamente migliore in questo. Ciò in cui tende a eccellere è la certificazione rispetto alle piattaforme PMS cloud verso cui gli hotel si stanno comunque orientando, e nella distribuzione delle correzioni senza necessità di un intervento in loco.
Cosa cambia effettivamente con il cloud quando si gestiscono sei punti vendita
L’argomento a favore del cloud per un singolo punto vendita riguarda principalmente il fatto di non possedere hardware. L’argomento per più punti vendita è diverso e molto più forte, e si riduce a un unico database.
Contate i punti in cui oggi un hotel duplica il lavoro. Un aumento di prezzo della birra chiara alla spina deve essere inserito nei sistemi del bar, del ristorante, del punto vendita a bordo piscina e nelle schermate del servizio in camera. Una nuova dichiarazione sugli allergeni deve essere aggiornata in ciascuno di essi. Un membro del personale che si sposta dalla terrazza al bar della hall ha bisogno di un secondo set di credenziali. Una politica di sconti approvata dal direttore generale si traduce in quattro pulsanti di sconto configurati separatamente che si sono silenziosamente discostati l’uno dall’altro, ed è proprio così che si finisce per non riuscire a spiegare una discrepanza. Niente di tutto ciò è difficile. È solo che si ripete all’infinito, ed è proprio nella ripetizione che le strutture perdono margine senza mai vederne una voce di bilancio.
Con un’unica configurazione ospitata, una voce esiste una sola volta e appare ovunque sia autorizzata ad apparire. Ciò significa anche che una modifica al menu effettuata alle 10:00 è attiva a bordo piscina alle 10:00, non nel momento in cui qualcuno si ricorda di andarci. Se volete conoscere i meccanismi del modello di hosting stesso, abbiamo spiegato separatamente come funziona il POS cloud. Il vantaggio specifico per gli hotel è che sei punti vendita smettono di essere sei sistemi che per caso condividono un logo.
Anche la reportistica si consolida allo stesso modo, e questo è più importante di quanto possa sembrare. Confrontare il numero di coperti e la spesa pro capite tra le diverse sedi su un unico schermo permette di notare, ad esempio, che la terrazza sta generando il volume del ristorante con la spesa tipica del bar, oppure che il brunch domenicale ha cannibalizzato la colazione del servizio in camera, su cui si realizza un margine migliore. Questi confronti si basano sul fatto che i dati siano raccolti allo stesso modo in ogni punto vendita, cosa che quattro database separati impediscono di fare. Il tasso di acquisizione e l’aspetto RevPASH di tale analisi costituiscono un argomento a sé stante, che richiede una trattazione più approfondita.
Registrazione dei costi delle camere e i problemi che infastidiscono gli ospiti
Supponiamo che l’interfaccia funzioni. Ci sono comunque quattro modi in cui le cose possono andare storte in una serata affollata, e conoscerli vi permette di valutare correttamente una demo.
Ricerca troppo lenta o troppo rudimentale. Un barista con cinque persone in attesa deve trovare un ospite in circa due secondi, per numero di camera, per cognome, idealmente scansionando una chiave magnetica. Se il flusso prevede di inserire il numero di camera, confermare il cognome e poi attendere l’icona di caricamento, il bar inizierà a scrivere i numeri di camera su un foglio di carta per registrarli in un secondo momento. Ogni hotel che agisce in questo modo ne scopre il costo al momento del check-out, quando un ospite contesta un addebito che nessuno è in grado di documentare.
Registrazione nel momento sbagliato. Alcuni sistemi registrano sul conto quando il conto viene chiuso, altri quando il turno viene chiuso, altri ancora in batch a fine giornata. Più tardiva è la registrazione, maggiore è la probabilità che un ospite effettui il check-out prima che venga addebitato il suo drink della buonanotte. Quell’addebito diventa una fattura post-partenza, che è un eufemismo per indicare denaro che probabilmente dovrete cancellare.
Mancata gestione di una registrazione rifiutata. Camera lasciata, limite di credito raggiunto, conto chiuso. Se il POS accetta l’addebito ma fallisce silenziosamente in background, il conto appare chiuso al punto vendita e il ricavo, di fatto, non esiste. Ciò che serve è un rifiuto immediato al terminale, mentre l’ospite è ancora lì.
Un percorso di elaborazione che ignora il pacchetto. Un ospite in mezza pensione che firma per la cena dovrebbe consumare la propria quota, non creare un nuovo addebito. Se si commette questo errore, si avrà sia un ospite insoddisfatto sia una visione distorta di quali punti vendita stiano generando ricavi rispetto a quelli che assorbono trasferimenti interni.
Nessuna di queste situazioni è insolita. Tutte emergono in una demo condotta in modo adeguatamente critico, motivo per cui la demo dovrebbe essere eseguita dal responsabile del bar che dovrà conviverci, non dal responsabile finanziario che ne leggerà i report.
Quando il POS e il PMS provengono dalla stessa azienda
Per trasparenza, poiché tutto quanto sopra dipende dalla qualità dell’interfaccia. Tableview è la società sorella di Prostay, un PMS alberghiero sviluppato appositamente, ed entrambi sono stati realizzati sulla base di un modello di dati condiviso anziché essere collegati a posteriori tramite un connettore. Ciò elimina quella parte del problema derivante dalla necessità che due fornitori si mettano d’accordo: non c’è alcun programma di certificazione da attendere, nessuna tariffa di interfaccia da negoziare, nessun numero di versione da tenere d’occhio e nessuno a fungere da arbitro quando un trasferimento dati fallisce e ciascuna parte punta il dito contro l’altra.
La differenza emerge nelle modalità di errore elencate sopra. La ricerca di un ospite è una query sul medesimo record dell’ospite, anziché un’operazione di andata e ritorno verso l’API di un’altra azienda, quindi non dipende dal tempo di attività di terzi. Un invio rifiutato viene segnalato sul terminale mentre l’ospite è ancora lì davanti, poiché lo stato del folio non è una copia arrivata pochi secondi prima. Le franchigie dei pacchetti si comportano esattamente come previsto dal PMS, poiché esiste un’unica definizione di mezza pensione su cui non ci possono essere divergenze. Il funzionamento di tale abbinamento tra diversi tipi di punti vendita è trattato nel nostro articolo sui sistemi POS per il settore alberghiero.
Nulla di tutto ciò rende un’interfaccia certificata di terze parti la risposta sbagliata. Molte strutture utilizzano Opera o Mews in tutta la loro rete senza alcun problema e, se questo è il vostro caso, le domande poste all’inizio di questo articolo sono quelle giuste da porre a un fornitore. Il punto più specifico è che una parte consistente del rischio in un progetto POS alberghiero risiede nel punto di congiunzione tra due fornitori, e tale punto di congiunzione non è obbligatorio.
L’audit notturno è una scadenza che non si può posticipare
I ristoranti chiudono la giornata quando se ne va l’ultimo tavolo. Gli hotel chiudono la propria giornata a un orario prestabilito, solitamente tra l’1 e le 4 del mattino, e tutte le questioni finanziarie devono essere sistemate entro quel momento. La revisione contabile aggiorna la data contabile, registra i costi delle camere e le imposte, e produce i dati rispetto ai quali verrà valutata la giornata successiva.
Un conto aperto in un punto vendita blocca tutto questo. Non in senso figurato: un conto non chiuso al bar può ritardare il passaggio di consegne, e le opzioni del revisore notturno sono quelle di rintracciare il responsabile di turno o di forzare l’operazione creando una discrepanza che qualcuno dovrà spiegare in seguito. Moltiplicate questo per una struttura in cui il personale della terrazza se ne va senza chiudere i conti e avrete una discussione ricorrente alle 2 del mattino che non ha nulla a che vedere con l’ospitalità.
Ciò che un buon software fa in questo caso è poco affascinante, ma vale la pena pagarlo. Mostra i conti aperti di ogni punto vendita su un’unica schermata prima che venga eseguito il controllo, segnala i punti vendita che non hanno effettuato la chiusura di cassa e fornisce un totale pulito per centro di ricavo. La logica di riconciliazione è la stessa del report Z che un ristorante genera ogni notte, con l’ulteriore vincolo che un altro sistema è in attesa di voi. Il cloud aiuta in modo concreto: il revisore notturno può visualizzare e risolvere lo stato dei punti vendita dalla reception, senza doversi recare a quattro terminali con quattro set di chiavi.
Funzionalità offline, perché «cloud» non significa «Internet o niente»
Questa è l’obiezione che affossa il POS cloud negli appalti alberghieri, solitamente sollevata da un responsabile IT che ha avuto brutte esperienze. Merita una risposta diretta piuttosto che una rassicurazione.
Un POS cloud ben costruito continua a funzionare quando la connessione si interrompe, perché il terminale conserva una copia locale del menu, dell’elenco del personale, dei conti aperti e dei prezzi, e mette in coda le transazioni da sincronizzare quando la connessione viene ripristinata. L’acquisizione degli ordini, la stampa in cucina, la suddivisione del conto e la chiusura per l’incasso continuano a funzionare. Questo è il minimo indispensabile, e dovreste verificarlo chiedendo a qualcuno di scollegare il router durante la dimostrazione. Qualsiasi fornitore che si opponga a questo test vi ha già detto qualcosa.
Due aspetti subiscono un vero e proprio deterioramento, e nessuna architettura ne è immune. L’autorizzazione delle carte richiede una rete, quindi i terminali ricorrono alla modalità “store and forward”, che trasferisce su di voi il rischio di un rifiuto. Più specificamente per gli hotel: la ricerca di un ospite nel PMS non può avvenire mentre il collegamento è interrotto, poiché la risposta risiede in un altro sistema. I sistemi migliori memorizzano nella cache l’elenco degli ospiti interni, così è comunque possibile addebitare una camera a un occupante noto e riconciliare l’operazione al ripristino della connessione. Quelli più deboli rifiutano semplicemente gli addebiti per le camere, il che in un resort significa che il bar della piscina smette di funzionare.
Quindi, a dirla onestamente, il cloud trasforma il guasto da totale a parziale. Un sistema legacy con un server locale fuori uso perde tutto fino all’arrivo di un tecnico, il che di domenica significa lunedì. Un sistema cloud su una linea fuori uso continua a vendere e perde una sola funzionalità. Chiedetevi esattamente quale funzionalità, poi decidete se la vostra connettività merita una seconda linea.
Il bar a bordo piscina che esiste solo per quattro mesi
La stagionalità è il contesto in cui possedere hardware e licenze perpetue smette di avere senso, ed è l’argomento a cui i resort rispondono più rapidamente.
Una struttura che gestisce otto punti vendita in agosto e quattro in febbraio, secondo il vecchio modello, ha acquistato l’hardware e le licenze per il mese di agosto. Quei terminali rimangono in un magazzino per cinque mesi, continuando ad ammortizzarsi, rimanendo soggetti ad aggiornamenti e venendo comunque conteggiati in un audit delle licenze. Il chiosco sulla spiaggia che opera novanta giorni all’anno comporta dodici mesi di costi.
Il prezzo mensile per terminale cambia questa aritmetica: si attiva il chiosco a giugno e lo si disattiva a settembre. C’è anche un vantaggio pratico, che gli operatori notano più del risparmio. Avviare un punto vendita temporaneo per un weekend di nozze o un festival diventa un’operazione di configurazione che richiede pochi minuti, utilizzando un tablet che già possiedi, anziché un ordine di acquisto. Questo cambia ciò che si è disposti a provare, e proprio il fatto di sperimentare è ciò che fa crescere i ricavi nel settore F&B. Se si valuta correttamente l’aspetto economico, vale la pena esaminare i meccanismi dei costi dei sistemi POS tenendo a portata di mano un calendario stagionale.
I banchetti vengono fatturati in modo diverso, e molti sistemi non riescono a gestirli correttamente
Per molte strutture, i ricavi derivanti da conferenze ed eventi eguagliano o superano quelli di tutti i punti di ristoro messi insieme. Inoltre, la fatturazione avviene in un modo per cui la logica dei POS al dettaglio non è mai stata progettata.
Un matrimonio non è un conto da pagare. È un evento concordato con un acconto versato mesi prima, una spesa minima, un prezzo a persona per un menu concordato in un foglio di programma, consumazioni che possono o meno avere un limite massimo, un costo di servizio trattato in modo diverso rispetto ai ristoranti e una fattura finale che va a un organizzatore a condizioni di credito piuttosto che a una carta di credito al tavolo. La cucina ha bisogno dei numeri per portata e delle variazioni dietetiche per tavolo, non di un flusso continuo di scontrini.
Ciò che serve dal POS è più limitato di quanto i fornitori suppongano. Raramente deve gestire l’evento in prima persona: questo spetta al sistema di gestione eventi o alle vendite. Deve registrare in modo chiaro gli extra della serata, il conto del bar che va oltre l’orario di chiusura concordato, il vino di categoria superiore, i tartine servite in ritardo, e addebitarli sul conto principale dell’evento in modo che compaiano sulla fattura finale invece di finire in una nota cartacea. Se sbagliate questo aspetto, perdete il fatturato più redditizio dell’intero locale: la spesa non pianificata. Gli aspetti commerciali di una corretta gestione di questi eventi sono trattati nel nostro articolo sul catering e sugli eventi privati.
Chi è il responsabile della sala nel seminterrato
C’è un argomento relativo all’IT e al rischio che i direttori finanziari tendono a trovare più persuasivo di qualsiasi altro di natura operativa, e riguarda principalmente ciò di cui si smette di essere responsabili.
Un POS in loco implica un server di vostra proprietà, su una rete che dovete proteggere, su cui gira una versione del database a cui qualcuno deve applicare le patch, con un backup che qualcuno deve controllare. I dati delle carte che transitano attraverso la propria rete ne trascinano una grande quantità nell’ambito della conformità PCI, e l’ambito di applicazione è la parte costosa della conformità. Il software in hosting con terminali crittografati punto a punto restringe sostanzialmente tale ambito, poiché i dati delle carte non passano più attraverso i sistemi di proprietà dell’azienda.
L’altra metà riguarda le patch e lo scostamento delle versioni. Una piattaforma in hosting si aggiorna centralmente, quindi la versione in esecuzione nel bar è la stessa in esecuzione nel ristorante, e una correzione di sicurezza non richiede un intervento in loco. Chiunque abbia gestito una struttura in cui un terminale era rimasto indietro di tre versioni perché l’aggiornamento aveva compromesso un driver della stampante sa bene quanto costi tale divergenza. Vale la pena dirlo chiaramente: questo trasferisce la responsabilità, non la elimina. Ora si dipende dall’uptime del fornitore e dalle sue pratiche di divulgazione, quindi la cronologia dello stato e i resoconti degli incidenti diventano elementi che si leggono effettivamente prima di firmare.
Più di una struttura e la visione d’insieme del patrimonio
Tutto quanto sopra si aggrava per i gruppi, ed è qui che una piattaforma ospitata smette di essere una preferenza e inizia a essere l’unica opzione sensata.
Configurate una volta sola, implementate in dodici hotel. Inviate un menu stagionale a tutte le strutture la stessa mattina. Confronta il margine lordo delle bevande tra le diverse proprietà sulla base di dati generati in modo identico: è l’unico modo in cui tale confronto abbia un senso. Apri un nuovo hotel clonando una configurazione invece di mettere in funzione un server. I modelli di gestione sono comuni a qualsiasi problema di gestione multi-sede, con l’ulteriore complicazione che ogni struttura ha la propria istanza PMS e il proprio audit notturno da soddisfare.
Un avvertimento basato sull’esperienza, poiché il controllo centralizzato presenta un punto debole. I gruppi che bloccano completamente la configurazione finiscono per avere un responsabile del bar a Palma che non può aggiungere un vermouth locale senza inviare una richiesta alla sede centrale. Le strutture che gestiscono correttamente questo aspetto centralizzano gli elementi che devono essere comparabili (la struttura degli articoli, i centri di ricavo, la gerarchia di rendicontazione) e lasciano ai team locali lo spazio per vendere ciò che i loro ospiti desiderano realmente.
Quanto costa, senza abbellimenti
Il POS cloud viene solitamente venduto per terminale al mese, e la cifra principale è la parte più piccola della decisione. Prevedete un budget per quattro elementi oltre a questo.
L’interfaccia con il PMS comporta quasi sempre un costo aggiuntivo, a volte una tariffa una tantum per la certificazione, a volte un canone mensile, occasionalmente fatturato dal fornitore del PMS anziché da quello del POS. Chiedete chi fattura cosa prima di elaborare qualsiasi modello. L’hardware va acquistato anche quando il software è in noleggio, e gli hotel sottovalutano la spesa legata all’ambiente: un terminale al bar della piscina deve essere protetto dal cloro e dal sole, una terrazza necessita di una stampante resistente all’umidità. La migrazione dei dati e la configurazione sono un lavoro vero e proprio, poiché qualcuno deve ricostruire menu, modificatori, centri di ricavo e regole fiscali, e una struttura con sei punti vendita e un servizio di banchetti non è un lavoro da un fine settimana. La formazione è la voce più spesso tagliata e di cui ci si pente più spesso, perché un hotel ha un elevato turnover stagionale e ha bisogno che la formazione sia ripetibile piuttosto che un evento di lancio una tantum.
A fronte di ciò, considerate ciò che viene eliminato: l’hardware dei server con il ciclo di aggiornamento, il contratto di manutenzione, gli interventi dei tecnici, il progetto di aggiornamento della versione che richiede due settimane ogni pochi anni e la lenta e faticosa gestione manuale di quattro database dei menu. Le strutture che gestiscono impianti davvero obsoleti spesso scoprono che il confronto è più vicino di quanto si aspettassero, anche se sarei scettico nei confronti di qualsiasi modello di fornitore che mostri un risparmio nel primo anno. Il primo anno comprende la migrazione.
Come condurre la valutazione senza un comitato che impiega sei mesi
Le decisioni relative al software alberghiero tendono a complicarsi facilmente. Una sequenza più rigorosa, ordinata in modo che le scoperte più costose avvengano per prime:
Iniziate dal PMS, non dal POS. Richiedete per iscritto al vostro fornitore di PMS l’elenco delle interfacce certificate e utilizzatelo come lista preliminare. Questo inverte il modo in cui la maggior parte delle strutture effettua la ricerca ed elimina i candidati irrealistici fin dal primo giorno.
Poi annotate il vostro mix di punti vendita e i casi più complessi, perché sono proprio questi ultimi a determinare la scelta. Indennità di mezza pensione, un bar riservato ai soci, pasti del personale, un bar della spa che addebita i costi sui conti dei trattamenti, un conto principale per gli eventi. Chiedete a ciascun fornitore di dimostrare questi flussi specifici piuttosto che una generica demo del servizio al tavolo, e fate partecipare alla riunione il responsabile del bar e il revisore notturno. In venti minuti scopriranno ciò che un documento di appalto non riuscirebbe a individuare in due mesi.
Effettuate una fase pilota in un punto vendita prima di estenderla a tutta la struttura, e scegliete il secondo più trafficato piuttosto che quello più tranquillo, poiché quest’ultimo non dimostra nulla. Sottoponetelo a un ciclo completo di revisione notturna, a un fine settimana e a un’interruzione di connessione provocata intenzionalmente. Quindi organizzate l’implementazione in modo che il settore banchetti sia l’ultimo, poiché è quello più vincolato da contratti e meno tollerante. La struttura generale di un progetto di sostituzione dei sistemi POS rimane valida in questo caso, ampliata dai test di audit e di folio che un hotel aggiunge.
Da dove iniziare lunedì
Estraete i dati relativi agli addebiti post-partenza e agli assegni non registrati degli ultimi tre mesi e quantificateli. Quella singola cifra, ovvero il ricavo che è stato corrisposto da un ospite ma non è stato registrato sul conto, rappresenta solitamente il business case più veritiero dell’intera struttura, ed è un dato che potete ottenere senza l’aiuto di un fornitore.
Poi chiamate il vostro fornitore di PMS e chiedete l’elenco certificato delle interfacce POS. Due ore di lavoro vi diranno se si tratta di una semplice sostituzione o di un progetto con un rischio di integrazione al centro. Tutto il resto, il sistema di visualizzazione in cucina per i banchetti, l’integrazione della gestione delle scorte tra i vari punti vendita, la gerarchia dei report, è più facile da definire una volta che sapete quali piattaforme possono effettivamente comunicare con il vostro registro ospiti.
Leggi anche: servizio in camera, stack tecnologico del ristorante e ordinazioni al tavolo.
