23 touchpoint, un unico sistema
Il percorso digitale di un ospite attraverso un'architettura hospitality unificata, e perché gli oltre 150 trigger sottostanti non possono esistere in stack frammentati.

Questo articolo segue un unico ospite (Sarah, un direttore marketing di 38 anni che sta pianificando un weekend prolungato in un country house hotel per l'anniversario di matrimonio dei suoi genitori) attraverso ventitré distinti touchpoint digitali con un operatore del settore ricettivo. Dalla prima ricerca su Google alla richiesta di recensione post-soggiorno, ogni interazione viene registrata nello stesso profilo ospite canonico, ogni segnale comportamentale alimenta la decisione successiva e ogni evento operativo può attivare un trigger di marketing, se l'operatore sceglie di collegarlo.
Il punto non è il percorso in sé. Il punto è che ogni touchpoint dipende dai dati di un sistema operativo diverso, e l'intero percorso regge solo perché tutti questi sistemi condividono un unico database.
In uno stack frammentato, il percorso si sfalda lungo le cuciture. Sarah viene trattata come una nuova cliente al touchpoint 6, poi di nuovo al touchpoint 14 e ancora al touchpoint 19. Le sue preferenze non vengono ricordate. Il suo stato di fidelizzazione non la segue. Il suo consenso al marketing deve essere raccolto nuovamente. Il personale operativo non ha alcun contesto. Il team di marketing non ha alcuna attribuzione. Diciotto dei ventitré touchpoint cadono nel buio operativo.
In un'architettura unificata, ogni touchpoint rimane in piena luce. Ecco come si presenta.
Touchpoint 1–10: prima dell'arrivo
Touchpoint 1: Sarah cerca su Google "Cotswolds hotels with private dining for 8". Atterra sulla pagina di una struttura del sito web dell'operatore. Il CMS risiede sulla stessa piattaforma di tutto il resto. La pagina che visualizza viene generata dinamicamente con la disponibilità per le sue date estratta in tempo reale dal PMS. Non c'è alcun widget di prenotazione di terze parti che la reindirizzi a un dominio diverso.
Touchpoint 2: Si connette al WiFi della struttura durante una visita per un sopralluogo due settimane prima (i suoi genitori abitano nelle vicinanze, era passata per un caffè). Il captive portal riconosce la sua e-mail (lo stesso profilo ospite) e in quel momento si era attivato un trigger al primo accesso WiFi, inserendola in un flusso di nutrimento non invasivo dedicato alla struttura. Lei non lo sa: ricorda solo che il posto le era piaciuto.
Touchpoint 3: Compila il modulo di richiesta per la sala privata sulla pagina della struttura. Si attiva il trigger di richiesta informazioni per lo spazio. Il coordinatore degli eventi della struttura riceve una notifica. Sarah riceve un'e-mail di conferma automatica con in allegato il PDF della brochure della sala privata, incluso automaticamente perché il modulo è collegato alla libreria documenti della struttura. Latenza totale dall'invio del modulo alla consegna dell'e-mail: meno di 30 secondi.
Touchpoint 4: Due ore dopo, il coordinatore degli eventi invia a Sarah un'e-mail personale con un preventivo. L'e-mail del coordinatore viene inviata direttamente dalla posta in arrivo unificata di mDOS. La risposta finisce nella stessa conversazione. La conversazione viene collegata alla scheda contatto di Sarah. L'opportunità viene creata automaticamente nello stadio "Richiesta: Preventivo inviato".
Touchpoint 5: Sarah accetta il preventivo e prenota otto coperti nella sala privata per il sabato sera. La prenotazione viene registrata nella sua scheda contatto. L'acconto viene incassato tramite Stripe Connect sull'account collegato della struttura. Il trigger di deposito versato per lo spazio si attiva e inserisce Sarah in un flusso di nutrimento pre-evento: conferma del menu pre-arrivo a -7 giorni, modulo per le esigenze alimentari a -5 giorni, pre-selezione dei vini del sommelier a -3 giorni, logistica di arrivo a -1 giorno. Nessuna di queste e-mail viene scritta o inviata manualmente: funzionano perché il flusso è stato creato una volta sola, sei mesi fa, e ora si attiva per ogni prenotazione di sale private nell'intera tenuta.
Touchpoint 6: Tre settimane prima dell'evento, Sarah prenota le camere d'albergo per sé e per i suoi genitori per la stessa notte. Il widget di prenotazione riconosce la sua e-mail (lo stesso profilo ospite) e precompila nome, telefono e indirizzo. Sia la sua prenotazione nel PMS sia la prenotazione della sala privata esistente fanno riferimento alla stessa scheda contatto canonica; in questo modo il team le visualizza insieme sotto un unico ospite e le sue preferenze alimentari dal modulo eventi sono visibili al team F&B. Riceve un'unica e-mail di conferma contenente tutti i dettagli, non tre e-mail da tre fornitori diversi.
Touchpoint 7: Due settimane prima, Sarah dimentica di compilare il modulo per le esigenze alimentari. Il trigger di invio del modulo, che si sarebbe dovuto attivare, non scatta. Al suo posto, a -10 giorni, si attiva un trigger di inattività separato nel flusso di lavoro degli eventi. Sarah riceve un'e-mail di promemoria cordiale: "Una rapida domanda: qualcuno dei Suoi ospiti ha allergie o esigenze alimentari particolari che dovremmo conoscere?". Sarah fa clic sul link, compila il modulo e il flusso prosegue.
Touchpoint 8: Una settimana prima, abbandona la prenotazione presso un locale partner di ristorazione informale che voleva visitare il venerdì sera prima della cena di anniversario. Stava scegliendo i piatti per un pre-ordine quando, distratta da una telefonata di lavoro, ha chiuso la scheda del browser. Si attiva il trigger di prenotazione abbandonata. Quarantacinque minuti dopo riceve un'e-mail: "Il Suo tavolo presso [venue] è ancora riservato. Un solo tocco per confermare." Un link diretto. E lei conferma.
Touchpoint 9: Tre giorni prima, arriva l'e-mail per la pre-selezione del sommelier. Sceglie tre vini da una lista selezionata. Le sue scelte vengono salvate come pre-ordini dell'evento, la stessa lista che la cucina e il bar leggeranno la sera stessa. Le proposte del sommelier nell'e-mail di pre-selezione inviata a Sarah sono state filtrate in base ai vini effettivamente disponibili in magazzino presso la struttura per quella settimana, attingendo dallo stesso sistema di inventario utilizzato dal bar manager per gli ordini.
Touchpoint 10: Un giorno prima, arriva l'e-mail con la logistica per l'arrivo. Indicazioni stradali. Orario di check-in. Password del WiFi. Conferma della prenotazione al ristorante. Ubicazione della sala privata. PDF del menu per l'anniversario (inviato perché Sarah aveva spuntato "festeggiamento di un'occasione speciale" nella richiesta iniziale, impostando un tag che ha condizionato questo flusso). Tutto in un'unica e-mail, personalizzata con il brand della struttura e firmata dal General Manager.
Touchpoint 11–19: il soggiorno e le fasi successive
Touchpoint 11: Sarah arriva alle 15:00 di sabato ed effettua il check-in. Il check-in viene registrato nel database. La sua registrazione attiva due azioni in modo autonomo: il flusso di benvenuto (un messaggio personalizzato con il suo nome, contenente le preferenze sulla camera di un soggiorno precedente già presenti nel suo profilo a disposizione del team) e il trigger di upsell per la spa: "Soggiorna da noi per due notti. Desidera aggiungere il massaggio di coppia domani mattina?". Sarah prenota il trattamento dal link presente nel messaggio. La prenotazione viene riscritta nel PMS come extra addebitato sul conto.
Touchpoint 12: La prenotazione per una cena informale di venerdì sera avviene presso la struttura affiliata. La cassa addebita il pasto sulla scheda contatto di Sarah. Si attiva il trigger dell'ordine completato alla cassa. I punti fedeltà vengono calcolati e assegnati atomicamente all'interno della stessa transazione del pagamento del conto. Il suo livello di fedeltà passa da Silver a Gold. Si attiva il trigger di passaggio al livello superiore, inserendola in un flusso di upgrade che verrà inviato domenica mattina.
Touchpoint 13: La bottiglia di Châteauneuf alla cena privata di sabato sera attiva il trigger di acquisto per categoria per il vino. Può approfondire l'argomento nel nostro articolo sugli abbinamenti enologici.
Touchpoint 14: Sarah effettua il check-out domenica alle 11:00. Si attiva il trigger di check-out. Il conto viene saldato e la ricevuta viene inviata automaticamente via e-mail. La richiesta di recensione post-soggiorno non viene inviata immediatamente: il flusso è configurato per attendere 48 ore dal check-out, ovvero quando la maggior parte degli ospiti è emotivamente pronta a scrivere una recensione significativa anziché affrettata nel parcheggio. Questa decisione è stata presa dal team di marketing sulla base delle analisi sui tassi di risposta alle recensioni provenienti dai dati della piattaforma stessa.
Touchpoint 15: Martedì mattina Sarah riceve la richiesta di recensione. Clicca sul link e accede al modulo di recensione diretto della piattaforma. Valuta il soggiorno con 5 stelle. Si attiva il trigger di recensione positiva. Ora è idonea per il flusso di referral, il flusso con sconto sul prossimo soggiorno per aver consigliato un amico creato dal team di marketing sei mesi fa.
Touchpoint 16: Mercoledì viene recapitata l'e-mail sull'abbinamento dei vini.
Touchpoint 17: I genitori di Sarah (che non hanno mai interagito con il sistema di marketing della struttura) ricevono un'e-mail di ringraziamento dal General Manager. Il coordinatore degli eventi l'ha scritta manualmente, nella posta in arrivo unificata, indirizzata agli ospiti nominati da chi ha effettuato la prenotazione, in quanto i loro dati sono stati acquisiti al touchpoint 7. Ora i genitori dispongono di schede contatto autonome nel CRM, collegate alla stessa prenotazione. Flussi futuri potranno contattarli previo opportuno consenso.
Touchpoint 18: Due mesi dopo si avvicina il compleanno del padre di Sarah. Si attiva il trigger per il compleanno del membro del programma fedeltà (era stato iscritto al programma fedeltà al touchpoint 17 tramite iscrizione implicita con consenso di marketing). Riceve un'e-mail di compleanno con un'offerta adeguata al suo livello per un nuovo soggiorno.
Touchpoint 19: Effettua la prenotazione. L'intero ciclo riparte, ma questa volta la struttura conosce già la famiglia, le preferenze per la camera, le esigenze alimentari e i gusti in fatto di vino.
Touchpoint 20–23: il livello operativo
I touchpoint dal 20 al 23 sono trigger operativi che si attivano silenziosamente in background e non raggiungono mai direttamente Sarah, ma migliorano ogni interazione che ha con lo staff: la chiusura del night audit per il bilancio definitivo; una richiesta di manutenzione, derivante dalla sua segnalazione sulla doccia che perde, registrata per la camera e risolta prima dell'arrivo dell'ospite successivo; una richiesta al concierge, scaturita dalla sua domanda per prenotare un ristorante nelle vicinanze; e la creazione di un account aziendale, dato che la sua società ha ormai utilizzato la struttura quattro volte e si sta configurando una tariffa corporate.
Cosa dimostra questo percorso
Il percorso sopra descritto si articola in ventitré touchpoint. Utilizza sedici trigger distinti tra gli oltre 150 integrati nel motore di flussi di mDOS. Nessun singolo touchpoint è un'esclusiva di mDOS. Teoricamente, qualsiasi gestore potrebbe crearne uno all'interno di uno stack frammentato, a fronte di un adeguato lavoro di integrazione.
Ciò che rende unico mDOS è che tutti i ventitré touchpoint rimangono collegati alla stessa scheda ospite canonica dall'inizio alla fine, che i dati da cui dipende ciascun touchpoint sono accessibili con una semplice query nello stesso database e che i flussi che governano il percorso possono essere creati e modificati dal team di marketing direttamente nell'interfaccia utente della piattaforma, senza dover ricorrere a un'agenzia di integrazione.
È questo ciò che intendiamo per "integrato nelle realtà operative della struttura". Il motore di marketing non è aggiunto a posteriori ai sistemi operativi: ne fa parte integrante. Ogni evento operativo è un trigger di marketing pronto per essere collegato. Ogni trigger di marketing è un evento operativo già presente nel database.
Gli oltre 150 trigger rappresentano l'ampiezza dell'interfaccia. Il database unificato è ciò che rende possibile tale ampiezza.
Contatti il fondatore per scoprire come questa architettura si adatti alla Sua struttura.
Scoprite mDOS per la vostra azienda
Una chiamata di 30 minuti con uno dei nostri esperti, incentrata sulle Sue priorità d'intervento.
About the author
Ross Crawford is the founder of Mr Digital and mDOS, and a Fellow of the Chartered Institute of Marketing (FCIM). He has worked in hospitality marketing since 2008, when he started at Fuller’s.
- Fellow of the Chartered Institute of Marketing (FCIM)


