Prima del fornitore viene l'ordine
Quando un hotel decide di rifare il sito, una delle prime cose che fa è cercare un fornitore: un'agenzia, un consulente, una software house, qualcuno che prenda il progetto e lo porti online. È una sequenza comprensibile, ma per un sito conversazionale conviene invertirla almeno in parte. Prima di chiedere a qualcuno di costruire, la struttura dovrebbe capire che cosa possiede davvero — non dal punto di vista tecnologico, ma da quello delle informazioni. Quali contenuti esistono, dove sono, quali sono affidabili, quali duplicati, quali vecchi, quali informazioni importanti vivono soltanto nella testa delle persone. Il primo cantiere è qui. Un fornitore può costruire un sistema molto sofisticato, ma non può sapere da solo se la piscina chiude alle 19 o alle 20, quale policy sia quella corretta, se una camera è davvero adatta a una persona con mobilità ridotta. Questa conoscenza appartiene all'hotel, e se arriva disordinata al progetto, il disordine entrerà nel sito.
Il vecchio sito non è automaticamente la fonte
La prima tentazione sarà: «prendiamo tutto dal sito attuale». Può essere un buon punto di partenza, ma non va considerato automaticamente la verità, perché il sito attuale contiene anni di modifiche — pagine dimenticate, offerte scadute, descrizioni duplicate, servizi cambiati, qualche vecchia frase che nessuno ha più controllato. Importare tutto sarebbe come traslocare mettendo negli scatoloni anche ciò che non usiamo da dodici anni, pur di fare prima. Conviene aprire gli armadi.
Non serve però censire ogni frase pubblicata negli ultimi quindici anni. Serve partire dai nuclei che incidono davvero sulla relazione con l'ospite — camere, servizi, ristorazione, wellness, policy, accessibilità, parcheggio, animali, orari, arrivo e partenza, territorio, offerte, condizioni commerciali, domande frequenti — e poi allargare. Il criterio è pratico: quali informazioni una persona può usare per capire, scegliere, prenotare o organizzare il soggiorno?
Le camere e le policy mostrano subito il problema
Le camere sembrano la parte più facile, e spesso rivelano subito il disordine. Come si chiama ufficialmente una tipologia? Quante persone ospita, che letti ha, dove si trova, è raggiungibile con l'ascensore, accetta animali? Queste informazioni devono essere coerenti con ciò che appare nel booking engine e con ciò che il personale comunica; se già qui troviamo differenze, abbiamo scoperto qualcosa di utile prima di iniziare. Le policy sono il punto più fragile, perché nascono da una decisione, vengono tradotte in testo, pubblicate, a volte cambiano, e non tutte le copie cambiano insieme. Un'età è "child" nel gestionale, un'altra nel booking engine, sul sito compare una frase generica, la reception applica una regola aggiornata; ma alla domanda «mio figlio ha 12 anni, come viene considerato?» serve una risposta, non quattro versioni. Quando il lavoro preliminare fa emergere due versioni diverse, non si sceglie quella che "suona meglio". Ci si ferma e si decide chi ha l'ultima parola, qual è la regola attuale, da quando vale, se ci sono eccezioni. È uno dei momenti in cui il progetto digitale produce un beneficio organizzativo ancora prima di esistere.
E l'attenzione non deve andare solo ai contenuti spettacolari — camere, ristorante, spa — perché per la conversazione contano moltissimo le informazioni meno vistose: dove lascio i bagagli, posso arrivare dopo mezzanotte, il parcheggio si prenota, posso portare il cane a colazione, serve prenotare la spa. Sono domande che pesano nella decisione, a volte più della descrizione della camera.
La reception e le email sono l'archivio invisibile
Per capire quali informazioni mancano, le persone migliori da coinvolgere presto sono quelle che rispondono ogni giorno alle domande, la reception, il reparto prenotazioni, chi legge le email. Conoscono i punti in cui il sito non basta, le domande che tornano, gli equivoci ricorrenti. Un incontro di due ore con il team fa emergere materiale che nessuna analisi del vecchio sito rivela. Anche le risposte ripetitive che molti hotel tengono pronte — «per il parcheggio…», «per il cane…», «per il check-in…» — sono una fonte preziosa, da controllare ma indicativa dei bisogni reali. E le domande frequenti vere sono diverse dalle FAQ scritte a tavolino in una riunione, che a volte sembrano l'hotel che fa domande a se stesso. Contano quelle che arrivano davvero, come vengono formulate, quali generano più dubbi. L'ordine riguarda infine anche i nomi. Se una camera è chiamata Camera Deluxe, Deluxe Room e Deluxe Vista Lago, i sinonimi aiutano a riconoscere le domande degli ospiti, ma internamente bisogna sapere qual è il nome ufficiale.
Distinguere ciò che è stabile da ciò che cambia
Una camera può mantenere la stessa superficie per anni; un orario può cambiare ogni stagione, una tariffa di continuo, un evento dura due giorni, un sentiero può chiudersi. Queste differenze devono entrare nella gestione. Se un'informazione cambia spesso, serve una fonte particolarmente affidabile e serve sapere chi la aggiorna — non basta scriverla bene una volta. Vale a maggior ragione per il territorio, che è in buona parte fuori dal controllo diretto della struttura: musei, ristoranti, trasporti, eventi. Includerli è possibile, ma richiede manutenzione, e conviene decidere prima quanto territorio si vuole davvero governare. Meglio cinquanta contenuti affidabili che cinquecento lasciati invecchiare. Lo stesso ordine vale per le fotografie — quali sono aggiornate, quali rappresentano la camera attuale, quali hanno diritti chiari — perché anche il patrimonio visuale entra nelle risposte.
Un perimetro e un pilota su domande reali
Una struttura potrebbe voler organizzare subito tutto — tutte le camere, tutti i servizi, tutto il territorio, ogni lingua — ed è comprensibile, e può diventare una trappola. Un primo progetto ha bisogno di un perimetro, abbastanza ampio da essere utile, abbastanza piccolo da poter essere controllato. È lo stesso principio della partenza progressiva vista per la prima fase — un patrimonio iniziale, test reali, poi si allarga — e vale molto anche sul piano organizzativo. Per scegliere da dove partire, conviene guardare dove oggi l'ospite fa più fatica. Se arrivano molte domande sulle famiglie, si parte da lì; se la struttura lavora con i ciclisti, camere, deposito, percorsi e ristorazione formano un primo nucleo. Il pilota deve permettere di vedere se la composizione delle risposte produce un beneficio reale, non essere scelto solo perché è facile da mostrare in una presentazione.
Ordine significa anche eliminare, e dare responsabilità
Durante il lavoro emergeranno pagine che non servono più, FAQ duplicate, servizi che non esistono. La tentazione è conservare tutto — «potrebbe servire» — ed è la frase con cui nascono gli archivi inutilizzabili. Un patrimonio ordinato ha bisogno anche di cancellazioni. Ogni contenuto, poi, dovrebbe avere qualcuno in grado di confermare che è corretto — le camere il reparto prenotazioni, il ristorante chi lo gestisce, le policy commerciali la direzione, il territorio chi verifica le fonti. Il nome della persona può cambiare, la responsabilità no. Se nessuno sa chi aggiorna un contenuto, quel contenuto invecchierà. E serve una piccola disciplina di manutenzione, non pesante — le informazioni stabili controllate periodicamente, quelle stagionali prima dell'apertura, le policy quando cambia una regola, le offerte alla scadenza — non per creare burocrazia, ma per evitare che la qualità del sito si deteriori lentamente.
Consegnare al fornitore un hotel già ordinato
Possiamo riassumere tutto in un piccolo esercizio. Prendiamo una domanda reale: «posso arrivare alle 23 con un cane e parcheggiare in hotel?». La struttura dovrebbe rispondere con certezza su orario, procedura, policy animali, parcheggio, eventuali supplementi. Se per rispondere dobbiamo chiamare quattro persone, cercare due documenti e controllare il vecchio sito, abbiamo già trovato il primo lavoro da fare. Il problema non è il sito conversazionale. È che la conoscenza dell'hotel è sparsa.
A questo punto cambia anche il rapporto con chi realizzerà il progetto. Invece di consegnare «questo è il nostro vecchio sito, fate voi», la struttura arriva con qualcosa di più utile: un patrimonio iniziale, le fonti ufficiali, le responsabilità, le contraddizioni già risolte, le domande frequenti reali, un'idea di quali contenuti cambiano spesso, un perimetro per il pilota. Chi costruisce il progetto conosce tecnologia ed esperienza digitale, ma non vive dentro la struttura. Se gli consegniamo informazioni vaghe dovrà fare ipotesi, e se nessuno risponde prenderà lui una decisione — ed è lì che rischiamo un sito tecnicamente corretto e operativamente sbagliato. La responsabilità del prodotto alberghiero resta all'hotel.
Questo lavoro, del resto, ha un beneficio che supera il progetto. Una fonte ufficiale sulle camere serve al sito, ma anche alla reception, al booking engine, alle campagne, alle OTA, alle newsletter. Mettere ordine riduce la probabilità che ogni canale racconti una versione leggermente diversa dell'hotel. In fondo il sito conversazionale non crea un'esigenza nuova — ogni hotel avrebbe già bisogno di sapere quali sono le proprie informazioni ufficiali — la rende soltanto più difficile da rimandare, perché quando la pagina diventa una risposta, l'informazione sbagliata arriva direttamente alla persona che l'ha chiesta, e non possiamo più nasconderla nella pagina 17.
Siamo pronti a chiamare il fornitore quando sappiamo abbastanza da fargli domande buone. Non serve aver risolto tutto — il fornitore potrà aiutare a organizzare, suggerire metodi, evidenziare lacune — ma la struttura deve arrivare sapendo almeno quale problema vuole risolvere, quali contenuti vuole usare, quali informazioni considera ufficiali, chi ne risponde, quali casi d'uso hanno priorità, quale livello di memoria vuole affrontare all'inizio. Da questo momento non gli stiamo chiedendo «fateci un sito conversazionale», ma di costruire un'esperienza precisa dentro confini che comprendiamo. Ed è proprio questo il passaggio del prossimo capitolo: quali domande fare a chi propone di realizzare il progetto, per capire se dietro una bella dimostrazione c'è davvero qualcosa che possiamo governare.