Come usare l'AI per gestire la rooming list di eventi e DMC

L'ospite risulta in camera singola nel foglio DMC. L'hotel ha ricevuto una doppia. La mail di modifica è rimasta in una terza cartella.

Il problema non è fare un altro riepilogo. Serve un record che mostri fonte, stato, versione inviata e conferma ricevuta.

L'AI può aiutare a estrarre richieste, normalizzare formati e segnalare conflitti in una rooming list. Non deve indovinare preferenze, assegnare camere in autonomia o ricevere più dati di quelli necessari al compito.

Definisci cosa governa la rooming list

Una rooming list collega un ospite a un'esigenza di soggiorno e a uno stato operativo. Non è la rubrica completa del partecipante, il piano trasporti o l'archivio delle conversazioni.

Il record può rispondere a queste domande:

• chi è il riferimento univoco?
• quali date sono richieste?
• quale tipologia è stata approvata?
• da quale fonte arriva la richiesta?
• quale versione è stata inviata alla struttura?
• cosa ha confermato la struttura?
• quale eccezione resta aperta?

La pagina sul controllo delle versioni dei documenti evento tratta il metodo generale. Qui lo applichiamo a un oggetto che cambia spesso e contiene dati personali.

Scrivi il dizionario dei dati

Prima di importare file, decidi quali campi servono davvero.

guest_ref: G-018
arrival_date: 2026-10-04
departure_date: 2026-10-06
room_type_requested: single
sharing_ref: null
booking_status: approved
source_ref: form-v3-row-18
source_updated_at: 2026-09-21T14:20:00+02:00
export_batch: hotel-a-v5
hotel_confirmation: pending
exception_code: null

Guest_ref permette di lavorare su molte verifiche senza mostrare il nome. Il collegamento con l'identità resta in una vista protetta e accessibile soltanto ai ruoli che ne hanno bisogno.

Non aggiungere numero di documento, telefono, note sanitarie o preferenze personali perché potrebbero servire. Ogni campo deve avere finalità, fonte, owner e regola di conservazione.

L'articolo 5 GDPR fissa principi di finalità, minimizzazione, accuratezza, conservazione limitata, integrità e riservatezza. Il progetto deve tradurli in campi, accessi e tempi verificati dai ruoli competenti.

Separa la vista operativa dalla vista identificativa

Un foglio unico è comodo fino al primo inoltro sbagliato.

Crea due viste:

Vista	Contiene	Chi la usa
Operativa	ID, date, tipologia, stato, eccezione	produzione e controllo
Identificativa	ID, nome e dati richiesti dalla struttura	desk autorizzato e struttura secondo il flusso approvato

Il modello che cerca conflitti tra date e tipologie può lavorare sulla vista operativa. Non gli serve conoscere il nome dell'ospite.

La Commissione europea descrive il principio need-to-know nella protezione by default. Il punto pratico è semplice: chi controlla la doppia assegnazione non riceve automaticamente ogni dato raccolto nel form.

Registra le fonti in ingresso

Le modifiche arrivano da form, email, call, referente aziendale e struttura. Se copi soltanto l'ultimo valore, perdi la possibilità di capire chi lo ha cambiato.

Ogni intake crea un evento:

change_id: CH-044
guest_ref: G-018
field: departure_date
old_value: 2026-10-06
new_value: 2026-10-07
source_ref: email-ops-221
received_at: 2026-09-22T09:14:00+02:00
authority_status: to_verify

L'AI può estrarre il valore e proporre il collegamento al record. Una persona o una regola approvata verifica l'autorità della fonte. Una richiesta scritta da un accompagnatore non modifica per forza la prenotazione.

Le comunicazioni ai partecipanti di un evento governano messaggi, scadenze e canali. La rooming list usa soltanto le informazioni necessarie al soggiorno e conserva il riferimento al messaggio, non tutta la conversazione.

Normalizza senza completare a fantasia

Le date possono arrivare come 4/10, 04 Oct oppure domenica sera. Il tipo camera può essere DBL uso singola, single o una stanza solo per me.

Definisci un vocabolario ammesso:

room_type: single | double | twin | triple | unknown
booking_status: proposed | approved | sent | confirmed | changed | cancelled
confirmation_status: pending | matched | conflict | missing

Il modello converte soltanto quando il significato è chiaro. Negli altri casi restituisce unknown con il frammento di fonte. Non trasforma camera tranquilla in una categoria inventata e non deduce una condivisione dal cognome.

Tieni separati dato originale, valore normalizzato e confidenza. La correzione deve poter tornare alla fonte.

Trova conflitti, non risolverli da solo

I controlli più utili sono deterministici:

• partenza precedente all'arrivo
• stessa persona in due strutture sovrapposte
• condivisione indicata da un solo ospite
• tipologia non disponibile nel blocco camere
• modifica ricevuta dopo l'ultimo export
• conferma hotel diversa dalla richiesta approvata
• record cancellato ancora presente nell'export

L'AI può spiegare il conflitto e raccogliere le righe coinvolte. La decisione resta al desk, al referente autorizzato o alla struttura secondo il contratto del progetto.

Usa codici brevi. PAIR_MISMATCH è più tracciabile di una cella arancione senza motivo.

Versiona ogni invio alla struttura

Il file inviato deve diventare una baseline immutabile.

Per ogni export conserva:

export_id: hotel-a-v5
generated_at: 2026-09-23T17:30:00+02:00
record_count: 42
source_snapshot: rooming-approved-v8
approved_by: hospitality-lead
sent_via: approved-channel
receipt_status: received
supersedes: hotel-a-v4

Il conteggio è un controllo strutturale, non una prova di correttezza. Aggiungi hash o versione del file, destinatario autorizzato e ricevuta.

Quando arriva una modifica, non sovrascrivere v5. Crea v6 e registra quali record cambiano. Il passaggio di consegne per eventi e DMC usa questi riferimenti per distinguere promesse chiuse e aperte.

Riconcilia richiesta, export e conferma

Tre valori possono divergere:

1. richiesta approvata dal referente
2. riga inviata alla struttura
3. riga confermata dalla struttura

Il controllo confronta i tre livelli e produce uno stato:

Stato	Significato	Azione
matched	i tre valori coincidono	chiudi il record
pending	manca la conferma	sollecito dal canale approvato
conflict	almeno un valore diverge	revisione del desk
cancelled_open	cancellazione non confermata	blocca la chiusura

Non considerare silenzio come conferma. Il desk chiude quando ha la prova concordata.

Gestisci privacy e sicurezza nel flusso

La base giuridica, i ruoli tra organizzatore, DMC, cliente e struttura, i trasferimenti e i tempi di conservazione dipendono dal progetto. Vanno verificati da chi ha competenza e responsabilità.

Il workflow può applicare default prudenti:

• dati minimi per fase
• accessi per ruolo
• viste pseudonimizzate dove possibile
• canali approvati per export
• scadenza o revisione della conservazione
• log degli accessi e degli invii
• stop per campi sensibili inattesi

La Commissione europea indica che le misure devono essere proporzionate al rischio. Un foglio piccolo può contenere dati che meritano controlli forti. Il numero di righe non decide da solo la sensibilità.

Non usare un LLM pubblico come casella di smistamento. Il tool, il contratto, la localizzazione e gli accessi vanno approvati prima dell'uso reale.

Un esempio fittizio

Una rooming list sintetica contiene 36 record. Il controllo trova due partenze precedenti all'arrivo, una coppia indicata da un solo lato e tre modifiche arrivate dopo l'export v4.

Il modello normalizza le date chiare, lascia un valore unknown e crea sei eccezioni. Il desk approva cinque correzioni. La sesta resta aperta perché la fonte non ha autorità confermata.

L'export v5 contiene 35 record approvati e una voce sospesa. La struttura restituisce 34 match e un conflitto sulla tipologia. I numeri servono soltanto a mostrare il workflow.

Misura il lavoro, non la quantità di dati

Conta record senza fonte, conflitti aperti, modifiche dopo export, conferme mancanti, tempo di riconciliazione, accessi fuori ruolo e file inviati senza ricevuta.

Campi compilati non è una metrica di qualità. Un campo inutile compilato bene resta un dato inutile.

Per la pagina SEO, osserva impressioni, query non-brand e invii form aggregati. L'impatto richiede almeno 28 giorni comparabili dopo un eventuale rilascio.

Gli errori che fanno divergere le liste

Il primo è lavorare su un allegato senza ID di versione. Il nome finale-2 diventa la baseline per errore.

Il secondo è mescolare richiesta e conferma nella stessa cella. Non sai più cosa ha detto l'ospite e cosa ha accettato l'hotel.

Il terzo è dare al modello il foglio completo. Il controllo richiedeva date e tipologia, ma riceve telefoni e note.

Il quarto è completare gli unknown. Una deduzione plausibile entra nella prenotazione come fatto.

Il quinto è cancellare la versione precedente. Al primo conflitto manca la prova dell'invio.

Think, Build, Enable applicato alla rooming list

Think: definisci finalità, campi minimi, fonti autorizzate e ruoli di accesso.

Build: crea record, viste, codici eccezione, export versionato e riconciliazione a tre livelli.

Enable: forma desk e backup, prova un cambio tardivo e concorda chiusura e conservazione con i ruoli competenti.

La lista è pronta quando richiesta, invio e conferma raccontano la stessa cosa.