Un ospite chiede: “Trovami due notti a Interlaken, camera doppia, parcheggio e cancellazione flessibile.”
L’agente trova sul sito una camera a CHF 240 con colazione e cancellazione 48 ore prima. Poi scopre che CHF 240 è un prezzo “da”, la tariffa non vale nel weekend e l’ultima camera è stata venduta tre minuti fa.
Il sito era leggibile. La prenotazione no.
Per un hotel, essere agent-ready non significa soltanto avere schema markup e testi chiari. Significa separare informazioni, disponibilità live, richiesta e commit finale in modo che nessun agente possa confondere “ho preparato una prenotazione” con “l’hotel l’ha accettata”.
La parte informativa è solo il primo livello
Un agente dovrebbe capire tipologia camera, occupazione, servizi, check-in, policy, lingua e percorso di booking.
Prezzi e inventario però cambiano.
Google Hotel Prices tratta availability, rates, inventory e restrictions come dati operativi che vengono aggiornati quando cambia lo stato. Un prodotto è vendibile soltanto se tutte le condizioni applicabili lo permettono.
Questo non significa che ogni assistente IA userà Google. Dimostra però un principio di sistema: prezzo prenotabile e disponibilità sono stato live, non testo statico della pagina.
Fatto confermato: la documentazione ufficiale Google separa disponibilità, tariffe e inventario e richiede dati aggiornati.
Raccomandazione: lasciate leggere all’agente i fatti pubblici, ma il commit deve passare da booking engine, PMS o API autorevole.
Quattro livelli per non chiamare “prenotato” ciò che non lo è
| Livello | Esempio | Cosa può fare l’agente |
|---|---|---|
| Lettura | camera, servizi, check-in, policy | sì |
| Preparazione | date, ospiti, preferenze | sì |
| Richiesta | controllo live di prezzo e disponibilità | solo su interfaccia autorizzata |
| Commit | creazione prenotazione + confirmation ID | solo dopo successo esplicito |
Usate stati backend chiari: quote, available_now, booking_pending, confirmed, failed, manual_review.
Il messaggio al cliente deve derivare da questo stato. Dopo l’invio di un modulo non si dice “prenotazione confermata”.
La naturalezza dell’IA aumenta l’importanza di questa regola, perché una frase sbagliata può sembrare molto autorevole.
Prezzo e disponibilità devono avere una fonte autorevole
CMS, PMS, channel manager, booking engine e feed esterni possono contenere versioni diverse della stessa offerta.
L’AI layer non deve scegliere liberamente.
Per un soggiorno specifico servono almeno: check-in/out, numero ospiti, room/rate plan, prezzo totale attuale e valuta, tasse/fee rilevanti, condizioni di cancellazione/modifica, restrizioni e stato di disponibilità.
La pagina può mostrare “da CHF 220”. Per il commit quel prezzo resta indicativo finché la fonte live non restituisce il quote reale.
Se il prezzo cambia prima della conferma, l’agente deve mostrare la variazione e ottenere la necessaria conferma del cliente. Non deve completare il task nascondendo il cambiamento.
Le eccezioni non sono bug
Gruppi, bambini, animali, accessibilità, late arrival, parcheggio garantito, voucher, corporate rate, camere comunicanti: il soggiorno standard diventa rapidamente un caso speciale.
Create una via manual_review.
Il flusso automatico può gestire un soggiorno semplice con tariffa pubblica e disponibilità chiara. Quando compare un’eccezione, il team riceve date, camera/rate candidata, ultimo prezzo e richiesta speciale.
Il cliente non deve ripetere tutto.
Se due canali mostrano prezzi differenti, l’agente non decide da solo quale “deve” valere. Il caso viene verificato secondo le regole dell’hotel.
Timeout e retry possono creare due prenotazioni
L’agente invia il commit. Il PMS crea la prenotazione ma la risposta di rete va in timeout. Dal punto di vista dell’agente sembra un fallimento.
Ripetere subito la chiamata può generare un doppione.
Serve quindi idempotency o un booking ID univoco, con controllo dello stato prima di ripetere un commit incerto.
Altro scenario: l’ultima camera viene venduta tra quote e commit. Il risultato deve diventare unavailable, non una conferma basata sul vecchio stato.
Se l’API di booking è offline, l’agente può salvare una richiesta e i contatti, ma deve dire chiaramente che la prenotazione non è ancora confermata.
Queste condizioni di errore sono parte centrale del design.
Pilot minimo: una camera e una tariffa
- Scegliere una camera standard e una tariffa pubblica flessibile.
- Definire la fonte autorevole per dati camera, policy, prezzo e inventario.
- Separare
quote,pendingeconfirmedanche nel linguaggio al cliente. - Aggiungere protezione duplicate/idempotency al commit.
- Testare cambio prezzo, sold-out, timeout, pagamento fallito e richiesta speciale.
- Passare le eccezioni alle prenotazioni con tutto il contesto.
Metriche: richieste con parametri completi, mismatch prezzo/disponibilità bloccati prima del commit, commit con confirmation ID univoco, prenotazioni duplicate, tasso di manual review e stati non confermati comunicati erroneamente come prenotati.
L’ultima è la metrica di sicurezza più importante. Un agente che conclude più flow ma promette camere non confermate non sta aumentando la qualità.
i viaggiatori useranno sempre più agenti che cercano e agiscono. L’hotel non deve per questo perdere controllo. Deve rendere più chiaro il confine: i fatti si possono leggere, la disponibilità appartiene al sistema autorevole e solo un commit riuscito crea una vera prenotazione.
La soluzione hotel e turismo collega richieste, chiamate e prenotazione. I dati social e video misurano i contenuti di ispirazione.
Fonti
- Google Hotel Prices — Documentation overview
- Google Hotel Prices — Availability message
- Google Hotel Prices — Pricing overview
- Google Hotel Prices — Landing page variables
- OpenAI — How agents are transforming work
FAQ
Lo schema markup basta per il direct booking via IA?
No. Aiuta a comprendere i fatti, ma non sostituisce inventario live, condizioni tariffarie e transazione.
L’agente può usare il prezzo della pagina?
Come indicazione sì. Il prezzo del soggiorno specifico va verificato nella fonte di booking prima del commit.
Come distinguere richiesta e prenotazione?
Con stati backend espliciti. Solo un commit riuscito con confirmation ID viene comunicato come prenotazione confermata.
Come gestire gruppi e richieste speciali?
Passarli a revisione umana mantenendo tutte le informazioni già raccolte.
Come evitare doppioni dopo un timeout?
Usare idempotency/booking ID univoco e controllare lo stato prima di ritentare il commit.