Skip to main content
Booking.com non ha un’API per i messaggi. I messaggi degli ospiti arrivano solo via email, alla casella registrata nell’Extranet della struttura. Se quella casella non è collegata a Conduit, l’agente non vede nessun messaggio Booking.
Questo è lo step che si rompe più spesso, e si rompe in silenzio.Le prenotazioni Booking continuano ad arrivare lo stesso, perché entrano dal PMS (Kross). Sono solo i messaggi a mancare. Quindi il cliente non vede nulla di anomalo: lui le mail le riceve nella sua casella e risponde a mano, come ha sempre fatto. Nessuno si accorge che l’AI è cieca su quel canale.È già successo: centinaia di prenotazioni Booking arrivate in mesi e zero messaggi mai entrati in Conduit; e un collegamento che ha funzionato una settimana e poi si è staccato senza che nessuno se ne accorgesse per oltre un mese.

​
🔑 La regola che regge tutto

L’indirizzo collegato in Conduit e l’indirizzo nell’Extranet Booking devono essere LO STESSO. Sembra ovvio, ed è il singolo errore che manda tutto a monte. È già capitato: una Gmail collegata e funzionante, poi in Conduit viene collegato il dominio aziendale senza completarne la configurazione, e nel frattempo la Gmail viene staccata. Risultato: Conduit puntava a un indirizzo mai finito, Booking scriveva a un altro, e i messaggi sono spariti per settimane senza che nessuno se ne accorgesse. Quando li verifichi o li cambi, muovili sempre in coppia:
1

Decidi UN indirizzo

Quello che colleghi a Conduit. Preferibilmente dedicato (booking@, ota@), non la casella personale.
2

Collegalo in Conduit

Add Gmail account se è Google, altrimenti inoltro. Verifica che risulti collegato, non che sembri collegato.
3

Impostalo nell'Extranet Booking

Nelle preferenze notifiche della struttura, come indirizzo che riceve gli avvisi dei messaggi ospite. Anche se pensi che sia già quello: confermalo guardando, non a memoria.
Se cambi uno dei due senza cambiare l’altro, il canale muore in silenzio: le prenotazioni continuano ad arrivare dal PMS e nessuno si accorge che i messaggi non passano più.

​
Perché riguarda soprattutto gli studenti Krossbooking

Su Kross, Booking.com pesa tipicamente 20-25% delle prenotazioni. Airbnb entra in Conduit con il suo canale nativo e funziona da subito: è questo che dà la falsa impressione che “l’AI funziona bene”. Booking invece passa solo da questo canale email. Se lo salti, stai consegnando un agente che copre tre quarti del traffico e ignora il resto.

​
Come collegarlo

1

Scopri qual è la casella VERA di Booking

Non è per forza quella che ti dice il cliente, né quella già configurata in Conduit. È l’indirizzo che il cliente ha messo nell’Extranet Booking, e va chiesto in modo esplicito:
“Qual è l’indirizzo email a cui ti arrivano le notifiche di Booking? Non quello che usi per scrivere ai clienti: proprio quello dove Booking ti manda gli avvisi dei messaggi degli ospiti.”
Non dedurlo dal dominio. È già successo: il mittente configurato in Conduit era su un dominio aziendale con mail server proprio, e da lì era stato concluso “non ha Google, serve l’inoltro”. Falso: la casella che riceveva davvero da Booking era una Gmail completamente diversa. Verifica, non inferire.
2

Se è Gmail o Google Workspace → OAuth nativo (STRADA DA PREFERIRE)

Conduit → Settings → Connected Channels → Email → Add Gmail account → login Google e concedi i permessi. L’indirizzo compare sotto Gmail accounts, sincronizza i messaggi in entrata e manda le risposte.Niente inoltri, niente codici di conferma, niente DNS. Funziona sia con Google Workspace sia con una Gmail gratuita, e convive con un dominio già aggiunto in Connected domains: non devi smontare la configurazione esistente.
Su Google Workspace serve un account vero, non un alias. L’OAuth richiede un login: booking@ deve essere una casella con una sua password, non un alias che rigira su un’altra. Un account vero consuma una licenza Workspace — è un costo piccolo ma va detto al cliente prima, non scoperto a metà procedura.
3

Se NON è Google → inoltro verso l'indirizzo di ingresso Conduit

L’indirizzo di ingresso sta in Conduit → Settings → Email → dominio → sezione “3. Receiving emails”: è un indirizzo ...@inbound.postmarkapp.com. Nel provider del cliente si crea una regola che inoltra lì.Meglio se filtrata sui mittenti booking.com invece che su tutta la casella: copre noreply@booking.com, no-reply@properties.booking.com e <numprenotazione>-xxxx@guest.booking.com, e tiene fuori la posta privata. La copia resta comunque nella casella del cliente: non gli sparisce niente.
4

Controlla le preferenze notifiche nell'Extranet Booking

Prima di tutto: il flag che abilita la notifica in sé. Extranet Booking → Struttura → Preferenze messaggi: deve essere attivo il flag “ricevi un’email per ogni messaggio inviato dagli ospiti”. Se è spento, Booking non manda nessuna email, di nessuno dei due tipi qui sotto — non è un problema di contenuto, è proprio zero traffico. Già capitato su più strutture: il canale in Conduit era collegato correttamente, ma questo flag nell’Extranet era disattivato e sembrava un problema di collegamento.
Una volta attivo il flag, Booking manda comunque due tipi di mail diversi, e uno dei due è inservibile:Se al cliente arriva il primo tipo, va cambiata la preferenza nell’Extranet perché i messaggi arrivino col contenuto. Il link sta dentro la mail stessa (“Modifica le tue preferenze”).

​
Verifica: come si controlla DAVVERO

Non fidarti mai della spunta “Inbound email forwarding is set up”. È auto-dichiarata, non verificata: la mette a mano chi fa l’onboarding. I record DNS accanto mostrano “Configured” perché Conduit li interroga davvero; quella casella no. Quindi non è una prova: la prova si fa sui dati, come sotto.
La verifica vera si fa sui dati, via API o MCP Conduit:
  1. Elenca le conversazioni del workspace e conta per canale.
  2. Devono esistere conversazioni unthreaded_email con mittente booking.com (= le mail entrano) e conversazioni booking_com con messaggi reali (= vengono interpretate).
  3. Zero email in ingresso di qualunque tipo = il canale è morto, punto. Non serve altra diagnosi.
Prima di rifare il collegamento OAuth o l’inoltro, controlla il flag “notifica email per ogni messaggio ospite” nell’Extranet (Struttura → Preferenze messaggi): è la causa più veloce da escludere e la più facile da dimenticare, perché da fuori il canale Conduit sembra collegato bene.
Controprova sui contatti: prendi qualche prenotazione Booking e guarda il contatto collegato. Se ha il canale booking_com registrato ma last_message_at vuoto su tutte, non è mai passato un messaggio.
Cosa NON si vede via API: se il collegamento è OAuth o inoltro. Gli endpoint /v1/connections e /v1/integrations non esistono (404). L’API dice se le mail arrivano, non come sono collegate: quella verifica resta in dashboard.

​
Dopo averlo collegato: la verifica NON è finita

Appena colleghi la casella con Add Gmail account, in Conduit cominciano a comparire conversazioni unthreaded_email nel giro di pochi minuti. È la prova che l’OAuth funziona — e non è ancora la prova che il canale Booking funziona. Misurato su un workspace il giorno del collegamento: prima, centinaia di conversazioni in cinque mesi e zero email in ingresso di qualunque tipo. Dopo il collegamento, entro un’ora sono entrate le prime email. Ma erano:
  • notifiche automatiche del PMS (noreply@krossbooking.com),
  • la corrispondenza ordinaria della casella,
  • nessuna email da booking.com.
“Arrivano email” ≠ “arrivano le email di Booking”. Le prime mail che vedi entrare sono quelle che la casella riceve di suo: PMS, newsletter, posta personale. Sono la prova che il tubo è aperto, non che ci passi l’acqua giusta.La verifica è completa solo quando in Conduit esiste almeno una conversazione con mittente booking.com — idealmente una <numprenotazione>-xxxx@guest.booking.com con il testo del messaggio dentro.
Quindi il collegamento va chiuso così:
1

Collega la casella e verifica che entrino email (qualunque)

Se dopo un’ora non è entrato niente, l’OAuth non ha funzionato: torna indietro, non aspettare.
2

Vai nell'Extranet Booking e controlla le preferenze notifiche

Devono essere impostate per mandare le notifiche col contenuto e all’indirizzo che hai appena collegato. Questo è il passaggio che la gente salta perché “tanto è già collegato”.
3

Aspetta (o provoca) un messaggio ospite Booking vero e ricontrolla

Finché non vedi una mail da booking.com dentro Conduit, il canale è collegato ma non dimostrato. Segnalo come tale nello stato dell’onboarding, non come “fatto”.
Nel frattempo si vede anche l’altra faccia della medaglia: le conversazioni che entrano hanno contatti “non mappati”, perché sono mittenti che non corrispondono a nessun ospite. È il costo normale dell’OAuth su una casella non dedicata, e la ragione per cui la best practice è un indirizzo booking@ o ota@ dedicato.

​
Le due trappole

Per attivare un inoltro, Gmail manda un codice di conferma all’indirizzo di destinazione. La destinazione è la casella Postmark di Conduit, quindi il codice finisce dentro Conduit e il cliente non lo vede: si blocca a metà procedura.→ Va fatto in call, con noi che leggiamo il codice in Conduit e glielo passiamo. Non si delega per iscritto.Vale anche al contrario, come diagnosi: se in Conduit non è mai arrivata nessuna email, allora quel codice non è mai stato inviato, quindi nessuno ha mai nemmeno iniziato la procedura. Con la strada OAuth il problema non esiste.
L’OAuth sincronizza l’intera casella. Se lo colleghi su un indirizzo personale, dentro Conduit finisce anche la posta privata del cliente.Successo davvero: su un workspace sono entrate notifiche di calendario, di riunioni, del revenue tool, di Google, corrispondenza personale e persino le nostre mail di marketing. Su un altro, l’inoltro di tutta la casella è stato spento dopo una settimana — plausibilmente proprio per questo.Best practice: indirizzo dedicato (booking@, ota@), mai la casella di corrispondenza personale. È lo standard nostro:La forma è sempre la stessa: una casella dedicata sul dominio del cliente, del tipo booking@ o ota@, usata solo per le OTA. L’elenco di quali clienti usano quale casella sta nel repo interno, non qui.
Consenso esplicito. Collegare una casella significa che l’AI vede quella posta. Su un indirizzo dedicato è irrilevante. Su una casella personale va detto e concordato col cliente prima di collegarla, non nascosto in mezzo a un’istruzione tecnica.

​
Se le mail arrivano ma le conversazioni non nascono

Se vedi le unthreaded_email da Booking ma nessuna conversazione booking_com, il collegamento è a posto e il problema è a valle:
  1. Verifica di essere nel caso della mail col contenuto (tabella sopra). Se arrivano solo gli avvisi vuoti, non c’è niente da interpretare: si torna alle preferenze dell’Extranet.
  2. Se il contenuto c’è ed è completo, è il parser di Conduit → apri ticket allegando l’esempio esatto: mittente, oggetto, data e testo della mail.

​
Checklist finale

Il canale email è a posto quando

  • Sai qual è la casella vera dell’Extranet Booking (chiesta, non dedotta)
  • L’indirizzo collegato in Conduit e quello nell’Extranet sono lo STESSO (verificato guardando entrambi)
  • Nell’Extranet, Struttura → Preferenze messaggi, il flag di notifica email per ogni messaggio ospite è attivo
  • È collegata: Add Gmail account se Google, altrimenti inoltro all’indirizzo Postmark
  • L’Extranet manda le notifiche col contenuto, non gli avvisi vuoti
  • Se è una casella personale: consenso del cliente esplicito
  • In Conduit esistono conversazioni unthreaded_email da booking.com
  • In Conduit esistono conversazioni booking_com con messaggi reali
  • Hai fatto un test con un ospite Booking vero
Finché manca l’ultima riga, lo stato corretto è “collegato, non dimostrato” — non “fatto”.