Demo dei sistemi PMS per hotel: provate il sistema, non la presentazione

Ogni demo di PMS a cui assisterete è preparata. Funziona con dati fittizi e puliti, in una struttura senza cronologia, guidata da qualcuno che usa il software ogni giorno lavorativo e sa esattamente quale percorso seguire per evitare le schermate più scomode. Nulla di tutto ciò è disonesto. Si tratta semplicemente di una presentazione di vendita, e una presentazione di vendita è praticamente inutile per decidere con quale sistema PMS il vostro team sarà ancora in grado di lavorare alle undici di sabato sera tra diciotto mesi.

La soluzione non è assumere un atteggiamento conflittuale. È prendere il controllo dell’ordine del giorno. Portate i vostri scenari, i vostri dati disordinati e il vostro personale, e gli stessi quarantacinque minuti che vi avrebbero mostrato una presentazione patinata vi mostreranno invece come si comporta il prodotto quando si scontra con la realtà. Questo articolo tratta la valutazione in sé: cosa preparare, quali scenari mettono in luce i punti deboli, cosa chiedere, cosa ignorare e come valutare il tutto in seguito senza illudersi. Si ferma dove iniziano i termini commerciali, perché cosa verificare in un contratto PMS per un hotel è un lavoro a sé stante, così come lo è la questione se un motore di prenotazione integrato faccia davvero parte della licenza.

Quanto segue si riferisce a una struttura indipendente o a un piccolo gruppo senza un reparto acquisti. Se ne avete uno, la maggior parte di questi consigli vale comunque; ci saranno semplicemente più persone presenti nella sala.

Perché ogni demo sembra ottima

Capire perché le demo presentano il software in modo lusinghiero è la base fondamentale per valutarne una correttamente. Ci sono quattro fattori che giocano a vostro sfavore, e nessuno di essi richiede che qualcuno si comporti male.

I dati sono perfetti. Le strutture utilizzate per le demo hanno profili ospiti ordinati, nessun duplicato, codici tariffari coerenti e nessun accumulo quindicennale di record migrati a metà. Quasi tutte le vere difficoltà in un sistema alberghiero derivano da dati errati, ambigui o obsoleti. Non è possibile capire come un prodotto gestisca tali situazioni osservandolo mentre gestisce dati che non presentano nessuna di queste caratteristiche.

Nulla del secondo punto è specifico del software. Il presentatore è un utente esperto, e gli utenti esperti fanno sembrare coerente qualsiasi interfaccia. Sanno che ciò che non riesci a trovare si trova dietro un clic con il tasto destro, che il report si trova in un menu diverso da quello che ti aspetteresti e che è meglio evitare una certa schermata. Il vostro revisore notturno non saprà nulla di tutto ciò nella prima settimana, e il divario tra esperto e principiante è esattamente ciò che una demo nasconde.

Il percorso è preparato. Una demo segue un itinerario scelto perché funziona. Ogni prodotto presenta aree più datate, meno intuitive o incomplete, e nessun presentatore vi si addentra volontariamente. L’assenza di un argomento è di per sé un’informazione, e ci vuole uno sforzo consapevole per notare ciò che non vi è stato mostrato.

Sei predisposto ad apprezzarlo. Quando arrivi a una demo, di solito hai già trascorso settimane a stilare una rosa di candidati e vuoi che la ricerca finisca. Vedere un presentatore competente risolvere i problemi con disinvoltura è davvero persuasivo. Quella sensazione non è una prova.

Cosa fare prima di fissare qualsiasi appuntamento

La parte più preziosa di una valutazione avviene prima ancora di parlare con un singolo fornitore, ed è la parte che più spesso viene saltata perché sembra un ritardo.

Annotate cosa non funziona effettivamente oggi. Non le funzionalità che vorreste, ma le cose specifiche che vi sono costate tempo o denaro questo mese. Un elenco utile potrebbe essere: ci vogliono due ore per inserire manualmente l’elenco delle sistemazioni di gruppo, il pannello delle pulizie è un foglio stampato che è già obsoleto di dieci giorni, non possiamo vedere i ricavi netti per canale senza un foglio di calcolo e l’audit notturno fallisce ogni volta che un folio viene lasciato aperto. Quell’elenco vale più di qualsiasi matrice delle funzionalità, perché è l’unica cosa che vi dirà in seguito se un sistema ha risolto i vostri problemi o se aveva semplicemente molte funzionalità.

Quindi suddividete l’elenco in tre gruppi. Cose che devono funzionare, altrimenti la struttura non può operare. Cose che consentirebbero di risparmiare tempo reale e quantificabile. E cose che sarebbero semplicemente piacevoli. Siate rigorosi, perché tutto tende a salire di livello se glielo permettete, e un elenco di requisiti in cui tutto è essenziale non fornisce alcuna base per scegliere tra due prodotti che soddisfano entrambi la maggior parte di essi.

Altri due passaggi preparatori si ripagano da soli. Annotate le integrazioni con i PMS alberghieri di cui non potete davvero fare a meno, indicando i prodotti e le versioni specifiche, poiché il logo di un partner su un sito web non equivale a una connessione certificata e operativa. E decidete chi prenderà la decisione prima di iniziare, perché una valutazione che finisce in un comitato senza un responsabile tende a concludersi senza alcuna decisione, oppure con l’opzione preferita dalla persona più chiassosa.

Prendete il controllo dell’ordine del giorno

Quando prenotate la demo, inviate al fornitore una breve nota scritta con alcuni giorni di anticipo. Da quattro a sei scenari tratti dalla vostra attività, una frase per ciascuno, oltre alla vostra lista delle funzionalità indispensabili e alla lista delle integrazioni. Se riuscite a produrre un campione anonimizzato dei vostri dati, inviate anche quello.

Spiega chiaramente come desideri che si svolga la sessione. Qualcosa del tipo: venti minuti per la presentazione generale standard, poi esamineremo i nostri scenari e vorremmo che un membro del nostro team conducesse l’ultima parte. La maggior parte dei fornitori accetta di buon grado, e quelli che oppongono resistenza ti hanno già fornito un’informazione utile prima ancora che l’incontro abbia inizio.

Questo non serve a tendere un'imboscata a nessuno. Serve perché una demo preparata dei vostri scenari è di gran lunga più informativa di una improvvisata, e perché il modo in cui un fornitore gestisce il brief è di per sé un segnale. La risposta giusta è una telefonata prima dell’incontro per chiedere cosa intendi con due degli scenari. È così che sarà l’implementazione: qualcuno che cerca di capire il tuo modo di operare invece di adattarlo al proprio modello.

Una nota pratica sulla registrazione. Chiedete se potete registrare la sessione e, se la risposta è sì, fatelo. Tre dimostrazioni si confondono tra loro nel giro di due settimane, e la risposta specifica a una domanda specifica è esattamente ciò che vorrete verificare in seguito, in particolare se si rivelerà essere stata ottimistica.

Gli scenari che rivelano davvero un sistema

I buoni scenari hanno una caratteristica in comune: sono normali in un hotel e complicati nel software. Qualsiasi sistema può gestire una prenotazione semplice. Ciò che distingue i sistemi è ciò che accade quando la situazione è complessa, ovvero nella maggior parte dei casi.

L’arrivo che non corrisponde alla prenotazione

Un ospite arriva con un giorno di anticipo, per tre notti anziché due, desidera una tipologia di camera diversa e la prenotazione è stata effettuata tramite un’agenzia a una tariffa che non si applica alle nuove date. Chiedete loro di gestire la situazione dall’inizio alla fine.

Verificate se la prenotazione viene modificata o cancellata e ricreata, poiché la ricreazione comporta la perdita della cronologia e della prova della tariffa originale. Verificate cosa succede alla commissione dell’agenzia, se la tariffa viene ricalcolata o deve essere modificata manualmente, e se tale modifica richiede l’intervento di un responsabile. Poi ponete la domanda fondamentale: domani potrete vedere com’era originariamente questa prenotazione e chi l’ha modificata? I sistemi che gestiscono le modifiche cancellando i dati precedenti rendono le controversie irrisolvibili.

Il conto che nessuno vuole dividere

Due colleghi condividono una camera doppia. L’azienda paga la camera e la colazione per entrambi, loro pagano i propri extra e uno dei due ha già versato un acconto online. Al momento del check-out, uno desidera una fattura unica intestata al proprio datore di lavoro e l’altro vuole una ricevuta personale.

Si tratta di una situazione di routine in qualsiasi hotel che si occupi di clienti aziendali, dove il saldo di solito ricade sull’city ledger (conto aziendale), ed è qui che le carenze dal punto di vista contabile emergono immediatamente. È possibile indirizzare gli addebiti per tipologia prima dell’arrivo, anziché doverli districare al momento del check-out? È possibile suddividere un conto tra i diversi pagatori senza dover reinserire i dati? L’acconto viene applicato alla voce corretta? È possibile emettere due documenti con il corretto trattamento fiscale su entrambi? Se questo richiede all’utente esperto diversi minuti e una soluzione alternativa, ricordate che il vostro addetto alla reception dovrà farlo con una fila di clienti in attesa alle spalle.

Il gruppo che cambia due volte

Un blocco di quindici camere scende a undici entro il termine ultimo, poi cambiano due nomi e una diventa una camera doppia. Chiedete di vedere l’intero percorso: configurazione del blocco, elenco delle sistemazioni, la riduzione, il rilascio dell’inventario e come si presenta il conto del gruppo alla fine.

Gli aspetti specifici da tenere d’occhio sono se le camere rilasciate tornano automaticamente in vendita, se l’elenco delle sistemazioni può essere importato o deve essere digitato a mano e se le cancellazioni vengono tracciate in base al contratto o rimangono solo nella memoria di qualcuno. La gestione dei blocchi per gruppi alberghieri rappresenta uno dei divari di qualità più ampi tra i sistemi alberghieri e uno degli argomenti meno probabili da vedere in una demo standard.

Il controllo notturno e il giorno dopo

Chiedete di assistere a un audit notturno in cui sia presente un errore: un conto aperto, un addebito non registrato, un’autorizzazione della carta non andata a buon fine. Chiedete poi come si presenta il report del mattino.

Le domande utili sono se l’audit si blocchi sull’errore o lo riporti silenziosamente, se possa essere rieseguito in caso di omissioni e a chi spetti correggere ciò che rileva. Chiedete anche cosa succede se non viene eseguito affatto, cosa che accade più spesso di quanto si ammetta. Un sistema che considera l’audit notturno come una cerimonia irreversibile è più difficile da gestire rispetto a uno che lo tratta come un processo ripetibile.

Se avete tempo, vale la pena aggiungere altri due scenari: una modifica delle tariffe che deve raggiungere tutti i canali, in modo da poter vedere il percorso di distribuzione dall’inizio alla fine e quanto tempo impiega a propagarsi, ed è qui che emergono i problemi di sincronizzazione tra channel manager e PMS; e una cancellazione in giornata con addebito sulla carta, un rimborso parziale e un reclamo da parte dell’ospite, che vi mostra contemporaneamente il percorso di pagamento e la traccia di audit.

Conta i clic, non le schermate

Prevedete un modo per registrare due numeri per ogni scenario: quanti passaggi sono stati necessari e quanto tempo ci è voluto. Non per costringere nessuno a usare un cronometro, ma perché quei numeri sono l’unica parte di una demo che sia comparabile tra tre fornitori due settimane dopo, quando tutto il resto sarà diventato solo un ricordo.

Mettete in relazione il risultato con la frequenza. Il check-in avviene centinaia di volte al mese. Se un sistema richiede quattro clic e un altro ne richiede nove, quella differenza si traduce in lavoro reale, ripetuto da persone stanche, all’infinito. Un rapporto mensile che richiede due minuti in più ha un’importanza di gran lunga minore. La ponderazione in base alla frequenza è ciò che impedisce che un esercizio di valutazione sia dominato dalla funzionalità che è stata dimostrata in modo più impressionante.

Presta attenzione a tre aspetti specifici mentre conti. Quanta parte del lavoro avviene su una sola schermata anziché su più schermate, perché è proprio nel cambio di contesto che si verificano gli errori. Se il sistema previene gli errori o si limita a segnalarli a posteriori, poiché un avviso prima di una doppia prenotazione vale molto di più di un rapporto che la elenca. E come si comporta il prodotto quando qualcosa va storto: un messaggio chiaro che spiega cosa è successo e cosa fare dopo è segno di un prodotto maturo, mentre un avviso di errore generico è segno del contrario.

Chi dovrebbe essere presente

L’errore più comune nella valutazione è che venga effettuata dalla persona che utilizzerà meno il sistema. I manager scelgono, e gli addetti alla reception devono conviverci.

Coinvolgi le persone che lo useranno quotidianamente. Un responsabile della reception, chi gestisce il servizio di pulizia, chi si occupa della contabilità e, se presente, chi si occupa di ricavi e distribuzione. Ognuno di loro porrà una domanda a cui non avreste pensato e noterà cose che a voi sfuggono: il vostro revisore notturno individuerà in novanta secondi che la procedura di chiusura presenta un passaggio che non può essere annullato.

Fornite loro un brief specifico piuttosto che un semplice invito a partecipare. Chiedete a ciascuno di valutare un aspetto, di annotarlo durante la sessione e di condividerlo subito dopo. Altrimenti la riunione produce solo un’impressione generale, e le impressioni generali sono dominate da chi parla per primo.

C’è un secondo vantaggio, più discreto. Le persone che sono state consultate durante la fase di selezione si comportano in modo diverso durante l’implementazione. La resistenza al cambiamento negli hotel spesso non riguarda affatto il software; riguarda piuttosto il fatto che una decisione sia stata presa altrove e imposta dall’alto. Un’ora dedicata a una demo garantisce in seguito una quantità sorprendente di buona volontà.

Domande che ottengono risposte sincere

Le domande aperte ottengono risposte di marketing. Le domande specifiche ottengono informazioni. La differenza sta interamente nella formulazione.

Ci sono due domande che vale la pena porre a ogni fornitore, perché le risposte sono molto rivelatrici. In cosa non siete bravi, o cosa chiedono più spesso i clienti che voi non fate? Un fornitore che cita qualcosa di specifico vi sta dicendo la verità ed è solitamente il partner più affidabile. Un fornitore a cui non viene in mente nulla o non sta ascoltando i propri clienti o non ve lo sta dicendo.

E ancora: quale tipo di hotel non fa per voi? Ogni prodotto ha una sua specificità. Un sistema progettato per hotel business in centro città gestirà male un resort con attività, trattamenti termali e mezza pensione; i fornitori validi lo sanno e ve lo diranno, piuttosto che vendervi un primo anno difficile.

Segnali di allarme durante una demo

Alcuni segnali meritano maggiore attenzione rispetto all’elenco delle funzionalità, e la maggior parte di essi riguarda il comportamento piuttosto che il software.

Rinviare uno scenario a una sessione successiva. Una volta va bene, poiché potrebbe effettivamente essere necessario configurare qualcosa. Rinviare ripetutamente gli scenari più complessi significa che tali scenari sono problematici per il prodotto stesso.

Rispondere a una domanda sulle funzionalità con una data della roadmap. Trattate tutto ciò che non è ancora stato rilasciato come se non esistesse. Potrebbe arrivare; nel frattempo, però, non potete gestire un hotel basandovi su quello.

Diapositive al posto di una schermata. Se un modulo viene presentato come diagramma anziché come schermata funzionante, chiedete di vederlo in azione. A volte la risposta è che è in versione beta: è bene saperlo, ma è costoso darlo per scontato.

Pressioni legate a una scadenza. Gli sconti che scadono questa settimana sono una tecnica di vendita, non una realtà commerciale. Un fornitore che ha fiducia nel proprio prodotto non ha bisogno che tu prenda una decisione prima di aver finito di valutarlo, e questo vale la pena ricordarlo quando si arriva alla fase contrattuale.

Vaghezza su chi svolgerà il lavoro. Chiedete chi si occuperà della vostra implementazione, se si tratta di dipendenti del fornitore o di un partner, e quante proprietà gestiscono contemporaneamente. La qualità dell’implementazione varia di più da persona a persona che da prodotto a prodotto.

Mancanza di disponibilità a concedervi l’accesso. Un fornitore che non vi permette di accedere a un ambiente di test vi sta chiedendo di acquistare un sistema che il vostro team non ha mai provato.

L’ambiente di test è il luogo in cui si nasconde la verità

Se c’è una cosa da ricordare di questo articolo, è proprio questa. Una demo guidata vi mostra cosa può fare il software. Un ambiente di prova vi mostra cosa può fare il vostro team, senza assistenza, e solo quest’ultimo permette di prevedere se l’implementazione avrà successo.

Chiedete un ambiente di prova per i vostri due finalisti, idealmente caricato con un campione dei vostri dati, per una o due settimane. Il caricamento di quel campione è anche un primo indicatore di come andrebbe effettivamente una migrazione del PMS. Poi affidate al vostro team un lavoro reale da svolgere al suo interno, piuttosto che lasciare che lo esplorino. L’esplorazione non è un’attività e non produce nulla di paragonabile.

Imposta lo stesso breve elenco di attività in entrambi i sistemi: creare e registrare una prenotazione, suddividere un folio, modificare un gruppo, eseguire un audit notturno, produrre il report che il proprietario richiede ogni mese. Chiedi a ciascuna persona di annotare dove si è bloccata e su cosa ha dovuto chiedere chiarimenti. Quindi confronta le note piuttosto che le opinioni.

Presta particolare attenzione a chi ha difficoltà. Se la tua addetta alla reception più esperta trova qualcosa di confuso, si tratta di un problema del prodotto. Se il membro del personale meno sicuro di sé ha difficoltà con tutto, si tratta di una questione di formazione e di un tipo diverso di costo, che vale comunque la pena conoscere prima di impegnarti.

Fai attenzione a una trappola. Un sistema che sembra familiare non è la stessa cosa di un sistema che è valido, e i team tendono inevitabilmente a preferire ciò che più assomiglia a ciò che già utilizzano. Chiediti se qualcosa è davvero peggiore o semplicemente diverso, e sii onesto nella risposta, perché la familiarità svanisce nel giro di poche settimane, mentre un cattivo design no.

Chiamate di riferimento e come andare oltre la «lista dei clienti soddisfatti»

Ogni fornitore tiene un elenco di clienti disposti a dire cose positive. Non è uno scandalo; lo fareste anche voi. Il compito è ricavare informazioni utili da una conversazione organizzata dal fornitore.

Chiedete referenze simili alla vostra realtà: dimensioni simili, segmento simile, integrazioni simili e, idealmente, un caso che sia entrato in produzione negli ultimi dodici mesi, in modo che il ricordo dell’implementazione sia ancora fresco. Poi ponete domande a cui non si possa rispondere con un semplice “sì” o “no”.

Cosa vi ha sorpreso dopo la messa in produzione? Quanto tempo ha richiesto effettivamente l’implementazione rispetto alla stima? A cosa avete rinunciato nel tentativo di farlo nel sistema? Raccontatemi di una volta in cui l’assistenza è stata davvero fondamentale e cosa è successo. Cosa verifichereste se doveste scegliere di nuovo? Ognuna di queste domande produce una storia piuttosto che una valutazione, e le storie contengono dettagli che le valutazioni non hanno.

Poi vai leggermente oltre l’elenco. Chiedi direttamente al fornitore se qualche cliente se n’è andato nell’ultimo anno e perché: è una domanda che produce o una risposta sincera o un silenzio eloquente. Vale anche la pena chiedere alle comunità alberghiere indipendenti e alle associazioni regionali, e una singola conversazione con qualcuno che gestisce esattamente la tua stessa combinazione di sistemi vale più di qualsiasi quantità di materiale pubblicato.

Come considerare una promessa contenuta nella roadmap

Ad un certo punto di ogni valutazione, a una lacuna verrà data risposta con un piano. La risposta giusta non è né quella di ignorarla né quella di fare affidamento su di essa.

Acquistate il prodotto così com’è oggi. Se la lacuna è davvero fondamentale, la conclusione onesta è che questo sistema non è ancora adatto, per quanto credibile possa essere il piano. Le tempistiche dei software subiscono ritardi in ogni settore e una data di consegna fornita durante un processo di vendita è un’intenzione, non un impegno.

Se decidete comunque di procedere, fate in modo che la promessa diventi concreta. Ottenetela per iscritto con una data, allegatela al contratto come allegato e chiedete cosa succederà se non verrà rispettata. Un fornitore sinceramente impegnato a rilasciare qualcosa nei prossimi due trimestri di solito lo metterà per iscritto. Chi non lo fa vi ha già rivelato quanto sia solido il piano.

Una domanda utile per valutare la situazione non costa nulla: cosa avete consegnato negli ultimi dodici mesi e cosa era previsto nella roadmap un anno fa che non è stato ancora realizzato? Un fornitore che risponde con disinvoltura a questa domanda è una scelta più sicura rispetto a chi parla solo di ciò che è in arrivo.

Valutare senza illudersi

Le matrici di valutazione sono utili per un motivo e pericolose per un altro. Costringono il team a registrare i giudizi mentre la memoria è ancora fresca, il che è davvero prezioso. Producono però anche un numero che sembra oggettivo ma non lo è, perché le ponderazioni sono state scelte da persone con le proprie preferenze.

Mantenete le cose semplici. Assegnate i punteggi in base alla lista dei requisiti indispensabili che avete stilato prima di parlare con chiunque, ponderandoli in base alla frequenza con cui l’elemento si verifica, con ogni partecipante che valuta la propria area di competenza anziché tutto il resto. Registrate il numero di clic e le note della sandbox accanto ai punteggi, anziché incorporarle in essi.

Considerate poi il totale come uno spunto, non come un verdetto. Se il vincitore in base ai punti non è quello che il vostro team vuole utilizzare, non ignorate semplicemente il parere del team; cercate di capire perché esiste questo divario. Di solito si tratta di una delle tre cose seguenti: qualcosa di importante è stato tralasciato dalla matrice, una ponderazione è errata, oppure la preferenza è dettata dalla familiarità piuttosto che dalla qualità. Vale la pena conoscere tutte e tre le cause e nessuna di esse si risolve con la semplice aritmetica.

Vale la pena imporre una regola. Scrivete un breve paragrafo che spieghi la decisione prima di firmare qualsiasi cosa, indicando a cosa state rinunciando non scegliendo le altre opzioni. Se quel paragrafo è difficile da scrivere, la valutazione non è completa. Se invece è facile, sarete felici di averlo tra diciotto mesi quando qualcuno vi chiederà perché l’hotel offre proprio quei servizi.

Trasformare una valutazione in una decisione

Le valutazioni di solito non falliscono perché ha vinto il sistema sbagliato. Falliscono perché non finiscono mai: la rosa dei candidati si allunga, compare una nuova opzione, la persona che ne è responsabile si fa prendere da altro e, un anno dopo, l’hotel utilizza ancora lo stesso sistema di prima, con gli stessi problemi nella stessa lista.

Stabilite il calendario all’inizio e rispettatelo. Per una struttura indipendente, da una a due settimane di preparazione, due o tre settimane di demo preparate, da una a due settimane di fase di test con chiamate di riferimento in parallelo, poi una settimana per decidere. Si tratta all’incirca di sei-otto settimane, ed è sufficiente. Comprimere i tempi di solito significa tralasciare la fase di test, che è proprio la parte che permette di prevedere l’esito. Prolungare il processo oltre un trimestre significa ricominciare da capo.

Ci sono due aspetti che vale la pena definire prima della riunione finale. Quali sarebbero i motivi per rinunciare al candidato favorito, concordati in anticipo in modo che non possano essere giustificati a posteriori. E chi firmerà, in modo che la decisione abbia un responsabile piuttosto che un comitato. Anche il prezzo deve essere discusso in quella sede, ma come costo totale di proprietà per l’intera durata del contratto piuttosto che come canone mensile.

Passate quindi alla fase commerciale tenendo ancora a portata di mano la valutazione. Tutto ciò che avete appreso sui tempi di risposta, l’ambito di implementazione, la certificazione di integrazione e gli impegni relativi alla roadmap deve trovare posto nei documenti, piuttosto che nel ricordo di una riunione andata bene. Il divario tra ciò che è stato detto durante una demo e ciò che compare in un accordo è la vera fonte della maggior parte delle delusioni post-acquisto, e colmarlo è l’ultimo compito che la valutazione deve svolgere per voi.