Cosa chiedere a chi realizzerà il progetto
Quando arriva il momento di parlare con un fornitore, il rischio è prevedibile. La conversazione parte dalla tecnologia — quale motore, quale piattaforma, quale modello, quale integrazione. Per chi dirige un hotel gran parte di queste parole è poco utile per capire se il progetto funzionerà. La domanda migliore è un'altra: cosa succederà all'ospite quando farà una domanda? Da lì conviene partire, perché un sito conversazionale può essere raccontato in modo sofisticato e restare, nella pratica, poco più di una chat appoggiata sopra un sito tradizionale; oppure può sembrare semplice e avere dietro un lavoro serio su contenuti, coerenza, contesto e responsabilità. Il compito della struttura non è valutare il codice. È capire il comportamento.
Mostratemi una richiesta reale
Una delle domande più utili è anche una delle più semplici: «fatemi vedere cosa succede quando un ospite chiede qualcosa che attraversa più parti dell'hotel». Per esempio: «siamo 2 adulti e 2 ragazzi di 14 e 17 anni, vorremmo stare 4 notti, mangiare spesso in hotel e avere qualcosa da fare se piove». Una dimostrazione del genere dice più di trenta slide. Il sistema mostra una pagina generica o seleziona camere compatibili? Tiene conto dell'età dei ragazzi? Collega il ristorante? Chiede qualcosa se manca un'informazione importante? Qui si vede subito se stiamo parlando di conversazione vera o soltanto di una nuova interfaccia.
Attenzione, però, alle dimostrazioni troppo perfette. Tre domande, tre risposte impeccabili, una pagina che cambia. Bellissimo. Poi arriva un ospite vero: «io e mia moglie verremmo con mia suocera che usa il bastone, nostro figlio forse ci raggiunge il secondo giorno e abbiamo un cane, però non sappiamo ancora se arriveremo in auto». Il mondo reale ha questa cattiva abitudine. È disordinato. La dimostrazione dovrebbe includere richieste meno pulite — ambiguità, cambi di idea, informazioni mancanti, domande fuori perimetro — perché è lì che si vede il comportamento del sistema. E quando ricevete una risposta piena di acronimi, interrompete: «traducetelo dal punto di vista dell'ospite». Se il fornitore descrive una funzione tecnica, chiedete cosa cambia sullo schermo; se parla di gestione dei profili, cosa cambia per un ospite che torna dopo un anno; se parla di integrazione con il CRM, quale informazione passa e per fare cosa. La traduzione in comportamento concreto aiuta a capire se una funzione serve davvero.
Da dove arriva la risposta, e cosa succede quando non c'è
La domanda successiva dovrebbe essere: «da dove prende questa informazione?». Se il sistema dice che la piscina chiude alle 20, chi ha stabilito quell'orario? Se dice che una camera è adatta a 4 persone, da quale fonte arriva il dato? Le risposte devono restare ancorate a contenuti reali e approvati dalla struttura, senza inventare prezzi, servizi o promesse, e il fornitore deve saper spiegare come viene impedito al sistema di riempire i vuoti con informazioni non verificate.
Ancora più importante. Cosa succede quando la risposta non esiste? Un ospite chiede «posso usare la piscina dopo il check-out?» e l'informazione non c'è. Se il sistema inventa, abbiamo un problema; se restituisce una frase vaga per nascondere che non sa, ne abbiamo un altro; se dice «non ho un'informazione confermata su questo punto, posso aiutarti a contattare la reception», il comportamento è molto più sano. La capacità di dire "non lo so" è una qualità, e va mostrata durante la dimostrazione, non soltanto promessa. Lo stesso vale per le domande ambigue: «cerco una camera tranquilla» — lontana dall'ascensore? ben insonorizzata? in una zona meno frequentata? Vale la pena chiedere: «quando il sistema decide di fare una domanda invece di dare subito una risposta?». Un assistente che risponde sempre può sembrare brillante. Spesso è soltanto troppo sicuro.
Perché il sistema ha mostrato proprio questo
Un decisore dovrebbe chiedere sempre: «perché il sistema ha mostrato proprio questo?». La risposta dovrebbe essere comprensibile — perché risponde direttamente alla richiesta, perché è coerente con ciò che è emerso durante la visita, perché si accompagna bene a un contenuto già proposto: sono i tre criteri che abbiamo chiamato pertinenza, affinità e correlazione. Se il fornitore non sa spiegare in modo semplice perché un contenuto compare, la struttura farà fatica a governare il sito; e se la risposta è «lo decide l'intelligenza artificiale», quella frase non spiega nulla.
Va poi verificato che menu e conversazione condividano davvero lo stesso patrimonio. «La camera mostrata nella pagina tradizionale è la stessa informazione usata nella conversazione? Se cambio l'orario del ristorante, devo aggiornarlo in più punti?» Se esistono due mondi separati, il rischio di incoerenza cresce, e la struttura non dovrebbe ritrovarsi a mantenere un sito e, accanto, una seconda versione del proprio sapere. Le due navigazioni devono anche parlarsi. Se l'ospite è nella pagina di una camera e scrive «questa è adatta anche a 2 bambini?», il sistema sa di quale camera si parla, o risponde «quale camera intendi?». La continuità di contesto, nei due sensi, è uno dei punti qualificanti del modello.
Quanto controllo resta alla struttura
Il sito deve poter essere governato. Quali contenuti possono essere pubblicati, chi li approva, chi può modificarli, chi può correggere un errore o disattivare un contenuto, quanto tempo serve perché una modifica diventi effettiva. Il progetto non deve trasformare ogni correzione in una richiesta al fornitore. Se per cambiare l'orario della spa bisogna aprire un ticket e aspettare quattro giorni, il problema comparirà presto. Lo stesso vale per i contenuti temporanei — un'offerta che scade, la piscina chiusa per manutenzione, il ristorante con orari ridotti per due settimane. Il sistema smette automaticamente di usare quel contenuto quando non è più valido? Chi controlla? Queste situazioni sembrano piccole e nell'ospitalità sono quotidiane. E se il progetto include il territorio, serve chiedere come si sa che quelle informazioni sono ancora valide, ricordando che un perimetro più piccolo e curato è più utile di un grande archivio poco affidabile.
Le domande della seconda fase
Finché il modello lavora con una comprensione anonima e temporanea, la domanda è semplice: «quali informazioni vengono usate mentre una persona naviga, e cosa succede quando la visita finisce?». Se il progetto parte subito raccogliendo molti dati personali, vale la pena chiedere perché. Con l'identità e la memoria, invece, le domande diventano più delicate, e non sono tecniche. Sono domande sul comportamento della relazione. Come viene riconosciuto l'ospite, cosa viene ricordato e per quanto, quali informazioni arrivano dal CRM e quali tornano indietro, come si distingue ciò che l'ospite ha dichiarato da ciò che il sistema ha dedotto, come una persona può correggere una preferenza o chiedere di essere dimenticata. Sul consenso il fornitore deve saper spiegare quando serve, cosa viene chiesto, come si revoca, cosa succede dopo. La risposta non può essere «è tutto conforme al GDPR», troppo generica per capire cosa accade davvero. E va chiesto chi può vedere i dati — marketing, reception, ristorante, fornitore, tutti? — perché ognuno dovrebbe vedere soltanto ciò che serve al proprio lavoro. Infine la correzione. Se un ospite scrive «non viaggio più con il cane» e il profilo dice il contrario, la correzione vale subito, resta per le visite successive, si propaga ai sistemi collegati, o restano copie che continuano a usare il dato vecchio? Una memoria utile deve poter dimenticare un errore.
Informazione e azione, e il passaggio all'uomo
Una distinzione va resa chiara prima del lancio. Quali azioni il sito può davvero compiere. Può dire che il ristorante è aperto, ma può prenotare un tavolo, o soltanto inviare una richiesta? Può verificare una disponibilità reale? Ogni azione promessa deve avere un significato operativo preciso. Se il sistema scrive «ho prenotato», la prenotazione deve esistere; se può solo trasmettere una richiesta, deve dirlo. E quando serve una persona — «vorrei organizzare 10 camere per una festa di famiglia» — bisogna chiedere come avviene il passaggio. Il commerciale riceve solo nome ed email, o il contesto della conversazione? È uno dei momenti in cui la qualità percepita può crollare, perché un assistente molto bravo seguito da un passaggio umano disordinato lascia comunque un'esperienza disordinata.
Cosa impareremo, e cosa resta nostro
Un progetto serio prevede anche il fallimento. Gli errori arriveranno — una richiesta interpretata male, un contenuto vecchio — e il punto non è immaginare un sistema infallibile, ma capire come si comporta quando qualcosa va storto. L'utente può segnalare che la risposta non è utile, il team può vedere le richieste problematiche, quanto serve per intervenire. Conviene poi chiedere come vedremo le domande a cui il sistema non sa rispondere, perché quelle richieste senza risposta mostrano dove il patrimonio è incompleto e guideranno il lavoro editoriale dopo il lancio. Sul successo, molti fornitori mostreranno numeri — conversazioni, messaggi, utenti, tempo sul sito — ma il successo non coincide con quante persone parlano con l'assistente. Meglio metriche vicine al problema, cioè quante persone trovano una risposta, in quanto tempo, con quanti passaggi, quante richieste restano irrisolte, quanti proseguono verso un'azione. Ed è utile la domanda scomoda: «se dopo 6 mesi scopriamo che quasi tutti usano solo il menu, cosa abbiamo imparato?». Una buona risposta non è difensiva. La prima fase serve anche a validare l'idea, e un progetto deve poterci insegnare che un'ipotesi non funziona.
Due domande riguardano il controllo nel tempo. La prima: «cosa rimane se cambiamo fornitore?». I contenuti restano alla struttura, le classificazioni sono recuperabili, il patrimonio editoriale è separato dal servizio, e cosa succede ai dati dell'ospite? Un hotel dovrebbe evitare di costruire anni di conoscenza dentro un sistema da cui poi non può uscire. La relazione con gli ospiti appartiene alla struttura. La seconda: «quanto lavoro richiederà a noi, ogni settimana e ogni stagione?». Chi aggiorna, quanto tempo serve, cosa succede se per tre mesi nessuno cura il patrimonio. Un progetto che richiede venti ore alla settimana a una struttura che può dedicarne due ha già un problema. La tecnologia deve adattarsi alla capacità organizzativa dell'hotel. Per questo un buon progetto parte da un perimetro controllabile, e la domanda giusta è «qual è il progetto più piccolo che ci permette di capire se questa idea funziona per noi?», molto migliore di «quanto costa fare tutto?».
Il capitolato, e il segnale del buon fornitore
Quando si commissiona il progetto è utile descrivere alcuni casi d'uso invece di sole funzioni: una famiglia che cerca attività in caso di pioggia, una coppia che torna dopo un soggiorno precedente, un ospite che arriva da una newsletter, una persona con una richiesta di accessibilità, un cliente con una domanda a cui non esiste risposta, una richiesta che deve passare al commerciale. Diventano un modo concreto per valutare il progetto. Il fornitore deve mostrare come li gestisce, non dichiarare di avere "personalizzazione AI". Perché alcune decisioni devono arrivare dalla struttura e non da un listino — quali promesse automatizzare, quali informazioni ricordare, quanto personalizzare, quali richieste devono arrivare a una persona, quanto territorio includere, quali dati custodire — trattandosi di scelte sul rapporto con l'ospite.
C'è infine un buon segnale da osservare. Se qualcuno arriva e dice di poter costruire tutto senza chiedere quasi nulla all'hotel, preoccupatevi. Un progetto serio genera domande — «qual è la policy corretta?», «chi aggiorna questa informazione?», «quando il sistema deve fermarsi?», «questa preferenza merita di essere conservata?», «chi può vedere questo dato?» — domande che complicano un po' il lavoro all'inizio e spesso evitano problemi molto più costosi dopo. Commissionare significa anche sapere cosa non chiedere. Non serve risolvere tutto al primo rilascio, collegare ogni sistema, ricordare ogni ospite, coprire ogni lingua nello stesso giorno. La struttura deve avere una direzione, e poi procedere per passi, prima capire bene, poi ricordare, se ne vale la pena. Ed è proprio questo il tema del prossimo capitolo: perché partire da un sito che capisce e aggiungere la memoria soltanto dopo può essere molto più intelligente che tentare di costruire subito il sistema completo.