Chatbot AI sul sito: quando serve davvero e quando è inutile

Un chatbot AI sul sito web può essere una funzione molto utile, oppure il bottone più costoso e ignorato della pagina. Quale delle due dipende quasi sempre dal problema che deve risolvere, e molto meno dal modello che ci sta dietro.

Se nessuno ha bisogno di assistenza mentre naviga, aggiungere una chat non crea valore da sola. Se invece ogni giorno arrivano le stesse venti domande, in più lingue e fuori orario, l'assistente può diventare una funzione vera del sito, e allora vale la pena progettarlo con la stessa cura del resto.

Qui mettiamo in fila i criteri con cui decidiamo, gli stessi del nostro lavoro su AI e automazioni: prima l'attrito da togliere, poi la tecnologia da mostrare. Come lo costruiamo, quando serve, sta nella pagina del chatbot AI per aziende.

Quale problema deve togliere il chatbot

Prima di parlare di modelli conviene guardare cosa succede oggi. Le persone non trovano le informazioni, scrivono sempre le stesse domande, abbandonano il booking o non sanno quale servizio scegliere; il team risponde di notte, oppure arrivano richieste in lingue che nessuno presidia. Un chatbot ha senso se almeno una di queste situazioni è abbastanza frequente da pesare.

Il primo dataset da analizzare sono le domande reali, non una demo. Raccogli per una settimana quelle che arrivano via email, chat, WhatsApp, ticket e telefono, più le ricerche fatte nel motore interno del sito, e raggruppale per tema: prezzi, orari, disponibilità, servizi, problemi, prenotazioni, supporto. Se il 70% delle domande riguarda quattro temi, l'assistente ha un lavoro chiaro. Se ogni conversazione è diversa dalle altre, il caso è molto più complesso.

Poi mappa il processo attorno a quelle domande: chi risponde oggi, dove trova la risposta, quanto tempo impiega, quando serve davvero una persona e cosa succede dopo. È il metodo che descriviamo in quali processi automatizzare in azienda, e porta spesso a scoprire che il bot è una delle soluzioni possibili, non per forza la prima.

Per ogni tema che emerge conviene scrivere una riga di una matrice semplice: la domanda, la fonte da cui arriva la risposta corretta, l'azione che deve seguire. È il documento che impedisce al bot di improvvisare.

Cinque livelli, dalla FAQ all'agente

Sotto la parola «chatbot» stanno prodotti molto diversi, che conviene distinguere prima di chiedere un preventivo:

• FAQ conversazionale. Risponde usando contenuti già presenti sul sito.
• Assistente per i contatti. Fa domande e raccoglie le informazioni che servono per una richiesta.
• Concierge. Suggerisce esperienze, servizi o percorsi.
• Assistente di supporto. Consulta dati autorizzati: lo stato di un ordine, un account, una prenotazione.
• Agente. Compie azioni al posto dell'utente.

Più si sale, più crescono insieme il valore possibile e il rischio. Un assistente che risponde da contenuti pubblici è un progetto; uno che entra nel CRM o nel booking è un altro, con altri controlli. Non serve partire dal livello più alto.

Prima la UX, poi la chat

Un bot non deve correggere una navigazione fatta male. Se il cliente chiede «dove trovo i prezzi?» e il prezzo dovrebbe essere evidente nella pagina, la soluzione migliore è sistemare la pagina. Se chiede «quale dei vostri dodici servizi è più adatto al mio caso?», una conversazione guidata può invece dare qualcosa che il menu non sa dare.

Per lo stesso motivo la chat non deve essere obbligatoria. Menu, ricerca, contatti, form e booking devono continuare a esistere e a funzionare per chi non ha nessuna voglia di parlare con un bot: la chat è un percorso alternativo, non il cancello d'ingresso.

E non deve diventare l'unico posto in cui vive un'informazione. Le risposte importanti restano nelle pagine, dove Google e chi non apre la chat possono trovarle; il bot può recuperarle e spiegarle. Quando le domande sono poche, le risposte stabili e il sito piccolo, una buona pagina FAQ è più veloce, indicizzabile, facile da mantenere ed economica: non serve l'AI per ogni problema informativo.

Quando un chatbot AI sul sito web serve davvero

Il caso più semplice è la risposta fuori orario. Una richiesta delle 23:40 viene letta il giorno dopo; nel frattempo un assistente può rispondere alle domande di base, raccogliere il contatto, chiedere di quale servizio si tratta, preparare il contesto e spiegare quando risponderà una persona. Non deve fingere che il team sia online: deve gestire bene l'attesa.

Ospitalità e turismo sono il terreno più naturale. Check-in, parcheggio, transfer, spiaggia, animali, colazione, esperienze: per chi gestisce un hotel o un resort sono domande frequenti, che arrivano in lingue diverse e a orari diversi.

In AVOY Sofia ha senso perché il prodotto è turistico, multilingua e distribuito fra ospiti e host. Lì la chat non è appoggiata alla home: fa parte del servizio.

Un ristorante, invece, non ha bisogno di un chatbot in automatico. Se le domande riguardano menu, orari, prenotazione, parcheggio e allergeni, spesso è più efficace rendere quelle informazioni evidenti nel sito, un tema che trattiamo in menu PDF, Instagram o sito. Se il locale gestisce più sedi, eventi, delivery, esperienze e più lingue, una guida conversazionale comincia ad avere valore. Decide il volume.

Su un sito B2B l'assistente può aiutare a qualificare i contatti. A chi non sa quale servizio scegliere chiede azienda, problema, dimensione, scadenza, budget indicativo e recapito, e trasforma le risposte in un brief che rende più utile la prima call. Può proporre una categoria, ma non dovrebbe decidere da solo che un contatto «non vale»: se la decisione commerciale resta al team, una frase interpretata male non fa perdere un'opportunità.

Un modulo da dodici campi può essere pesante, e una conversazione può raccogliere le stesse informazioni in piccoli passaggi; per chi sa già cosa vuole, però, il form resta più veloce, e se il volume lo giustifica conviene offrire entrambi. Sui siti grandi, come cataloghi, knowledge base e marketplace, la conversazione può anche aiutare a cercare i contenuti, a patto di mostrare sempre la fonte.

In sintesi, lo costruiremmo con volume alto e domande ripetitive, più lingue, un catalogo ampio o servizi complessi, richieste fuori orario, contatti da qualificare, dati collegabili e un passaggio chiaro a una persona.

Saper dire «non lo so»

È una delle funzioni più importanti, e la meno spettacolare. Un modello generativo tende a produrre comunque una risposta; il prodotto deve invece riconoscere quando manca un'informazione, quando un dato non è aggiornato, quando il tema è fuori dal perimetro o la richiesta è delicata, e fermarsi. «Non ho abbastanza informazioni, ti metto in contatto con una persona» vale più di una frase plausibile e falsa.

Collegare il bot ai documenti giusti, il cosiddetto RAG, cioè il recupero dei contenuti pertinenti prima di rispondere, aiuta ma non è una garanzia contro gli errori. Non elimina del tutto le interpretazioni sbagliate, le fonti in contraddizione fra loro e le risposte fuori contesto. Per questo servono un perimetro dichiarato, le fonti citate quando sono utili, una soglia di confidenza, un fallback e una serie di test.

Nei settori ad alto rischio i limiti vanno stretti ancora di più. Nella sanità, come nel legale o nella finanza, l'assistente può dare informazioni generali, orientare, prenotare e passare i contatti; non fa diagnosi, non prende decisioni legali, non dà raccomandazioni finanziarie personalizzate. Quel confine va progettato nel prodotto, insieme a una soglia di escalation: temi sensibili, richieste commerciali importanti, clienti arrabbiati, pagamenti, cancellazioni e dati personali non passano dallo stesso livello di autonomia di una domanda sugli orari.

La base di conoscenza va governata

Un assistente risponde sempre da qualche parte: pagine del sito, FAQ, documenti, database, CRM, booking. Ogni fonte ha bisogno di un proprietario, di una data, di permessi e di una regola di aggiornamento. Se il bot usa una vecchia policy e il sito quella nuova, il problema non è l'AI ma la governance.

Più documenti non significano risposte migliori. Caricare tutto, dai vecchi PDF alle email, crea rumore; serve una base selezionata, vera e aggiornata, in cui il chatbot sappia quale fonte è autorevole. Il bot non dovrebbe conoscere più di quanto l'azienda sa mantenere: tremila documenti che nessuno aggiorna lo rendono incoerente in fretta, cento fonti governate funzionano meglio, soprattutto per prezzi, condizioni, orari e policy.

Prima del lancio conviene scrivere anche una piccola policy editoriale: chi aggiorna le fonti, in quanto tempo vanno corrette le informazioni critiche, quali contenuti il bot non può usare, chi approva nuove capacità. Prompt, configurazione e fonti vanno versionati, così quando una risposta cambia si capisce se è cambiato il prompt, un documento, il modello o una regola.

Più lingue, una promessa in più

Un assistente traduce rapidamente, e questo apre il sito a chi non parla italiano. È anche una promessa: se poi il contatto umano esiste solo in italiano, il passaggio va gestito e dichiarato, con una frase come «posso assisterti in tedesco qui, ma il nostro team ti risponderà in inglese». La qualità va testata sulle lingue che il pubblico usa davvero, non solo sull'inglese, perché nomi propri, località, termini tecnici e condizioni si traducono male anche quando la conversazione sembra fluida.

Chatbot e sito multilingua non sono alternative. Se il mercato inglese è importante, il bot non sostituisce una versione inglese del sito: le pagine devono essere indicizzabili, condivisibili, leggibili e coerenti, e il chatbot aggiunge supporto sopra di loro. Ne abbiamo parlato per esteso in sito in più lingue.

Il passaggio a una persona deve essere corto

«Vuoi parlare con una persona?» non dovrebbe aprire altri sei passaggi. Se il bot ha già raccolto nome, richiesta, pagina di provenienza e lingua, quelle informazioni devono arrivare al team insieme alla richiesta; altrimenti il cliente ripete tutto da capo e la chat ha solo aggiunto un giro. Una buona automazione conserva il contesto.

L'uscita non deve per forza stare dentro la stessa interfaccia: l'assistente può chiarire la richiesta e poi passare a WhatsApp, email, telefono o booking, e l'architettura più semplice è spesso la migliore. Deve però esserci sempre una via d'uscita visibile, perché una conversazione che gira in tondo senza arrivare a un'azione sta intrattenendo, non aiutando.

Anche i guasti fanno parte del progetto. Il chatbot può essere attivo a ogni ora, le API a cui è collegato no: se booking, CRM o pagamenti non rispondono, il bot deve dire «posso raccogliere la richiesta, il team la elaborerà» invece di fingere che l'azione sia avvenuta. E se è il modello a non rispondere, il sito deve continuare a mostrare contatti, FAQ e percorsi principali.

La chat è un'interfaccia, non solo un prompt

Leggibilità, velocità, uso da mobile e da tastiera, stato di caricamento, errori, chiusura e riapertura: il chatbot è un pezzo di interfaccia e va progettato come tale. Se su mobile il pannello copre la call to action principale, ha fallito prima ancora di rispondere. Una chat che si apre dopo due secondi irrita; una che compare dopo un certo tempo sulla pagina, a un tentativo di uscita o su una pagina complessa può essere pertinente, e va misurata, perché proattivo non vuol dire aggressivo.

Spesso le scorciatoie funzionano meglio del testo libero. Pulsanti come «Costi e prezzi», «Tempi», «Prenotazione», «Servizi» e «Parla con noi» aiutano l'utente a entrare nei temi principali e aiutano il bot, perché riducono l'ambiguità.

Su Green Tech Costruzioni le scorciatoie portano dentro i temi principali senza costringere la persona a inventarsi la domanda. Per orari, contatti, prezzi, prenotazioni o stato di una richiesta, una risposta strutturata come un pulsante, una card, un link o una tabella è spesso migliore di un testo generato: il chatbot può orchestrare componenti invece di scrivere tutto, e diventa più prevedibile e più facile da usare.

Poi c'è l'identità: nome, ruolo, cosa può fare e cosa no, tono, lingue. Un assistente può essere caldo e utile senza fingere di essere un dipendente in carne e ossa, e la trasparenza aumenta la fiducia. Il tono sostiene il brand ma non passa davanti all'accuratezza: un bot simpatico che dà informazioni sbagliate è peggio di una pagina FAQ. E non ogni tema merita una chat: per un orario o una procedura la conversazione è naturale, per una proposta complessa una pagina strutturata funziona meglio.

Dati personali e azioni: dove cresce il rischio

Nella chat vale la minimizzazione: chiedere solo ciò che serve, di solito nome, email, telefono e problema. Più dati raccogli, più responsabilità hai, e la conversazione non deve invitare a scrivere informazioni sensibili quando non servono. Anche la cronologia va trattata con cautela: è utile per migliorare il prodotto, ma non va conservata per sempre, e tempi, accessi e anonimizzazione devono essere proporzionati allo scopo.

Quando il bot accede a dati personali come ordini, prenotazioni, fatture o profilo, deve sapere chi sta parlando: non si mostrano dati privati a chi conosce un nome. Autenticazione e autorizzazione diventano parte del progetto.

Il salto più grande arriva con le azioni. Rispondere «la tua prenotazione è il 12 agosto» è una cosa, modificarla è un'altra. Quando l'assistente può prenotare, annullare, pagare, modificare o inviare, servono conferme, autenticazione, permessi, un modo per tornare indietro quando possibile e un registro di cosa è successo; un prompt migliore non basta. Prima di ogni azione irreversibile la domanda è esplicita, del tipo «vuoi cancellare la prenotazione X per il 12 agosto?», e solo dopo la conferma parte l'azione. L'AI interpreta l'intento, la persona conferma l'effetto.

A questo livello l'assistente smette di essere un «chatbot sul sito» e diventa un'interfaccia del servizio: concierge, coach, supporto, analista. Servono product design, dati, backend e misurazione, e il progetto appartiene più allo sviluppo di prodotti digitali che all'aggiunta di un widget.

Testare prima, misurare dopo

Durante la demo tutti chiedono «quali servizi offrite?». Poi gli utenti veri scrivono «ciao, ho prenotato ma non trovo la mail e domani arrivo tardi con un cane, che faccio?». I test devono includere errori grammaticali, messaggi lunghi, più domande insieme, lingue diverse, ambiguità, richieste fuori perimetro, toni aggressivi e dati mancanti: un assistente utile deve reggere la realtà, non la demo.

Prima del lancio serve quindi una suite di test: 50–100 domande reali, ognuna con la risposta attesa, la fonte, l'azione e il punto in cui deve passare a una persona. La ripeti ogni volta che cambi modello, prompt o base di conoscenza, e il chatbot diventa un prodotto mantenibile invece di un esperimento. Utile anche un periodo di prova interna, con il team che usa l'assistente e annota gli errori: correggere cento casi in staging costa molto meno che scoprirli attraverso i clienti.

Dopo il lancio contano più numeri del totale dei messaggi: temi, domande risolte, passaggi a una persona, contatti e conversioni, abbandoni, tempi, risposte senza fonte, errori e domande che il bot non copre. Il tasso di contenimento, cioè la quota di conversazioni chiuse senza intervento umano, non deve diventare un obiettivo cieco. «Il bot ha risolto l'80% da solo» va benissimo, se il 20% passato alle persone contiene i clienti più importanti; non si ostacola l'escalation per migliorare una statistica.

Il feedback si chiede in modo leggero, non dopo ogni messaggio. Più istruttive sono le conversazioni che finiscono male, quando l'utente chiude, ripete la domanda o chiede una persona: indicano una risposta sbagliata, una pagina che manca o un processo frustrante, e fanno del chatbot uno strumento di ricerca sulla UX. Se cento persone chiedono «dove parcheggio?», forse è il sito che deve mostrare il parcheggio. Un buon assistente può ridurre nel tempo il proprio volume proprio perché aiuta a migliorare contenuti e percorsi, e per questo non si giudica dal numero di chat.

Serve anche una persona responsabile del prodotto, non per forza uno sviluppatore: qualcuno che guardi conversazioni, errori, domande nuove e metriche. Un chatbot lasciato solo dopo il lancio peggiora mentre l'azienda cambia. E se dopo un periodo quasi nessuno lo usa, le risposte richiedono troppe correzioni, il team gestisce comunque tutto o i costi superano il valore, va corretto o spento: nessuno è obbligato a tenere una funzione perché contiene AI.

Quanto costa un chatbot AI

Dipende dal livello. Una FAQ conversazionale su contenuti pubblici, un assistente che cerca in una base di conoscenza, uno che qualifica i contatti, uno collegato a CRM, account o booking, uno che compie azioni: ogni passo aggiunge dati, integrazioni e controlli, e il progetto cresce con loro.

Il costo iniziale non è tutto. Ci sono costi ricorrenti (hosting, monitoraggio, manutenzione, servizi esterni) e costi a consumo legati a ogni conversazione: modello, recupero dei documenti, messaggistica, archiviazione. Con poco traffico di solito sono piccoli, con grandi volumi crescono, quindi conviene seguirli per conversazione, per richiesta risolta e per contatto, invece di guardare solo il canone. Se l'assistente vive dentro una piattaforma a canone, vale lo stesso conto che facciamo in abbonamento o software tuo.

Il ritorno, poi, non è per forza fatto di vendite nuove. Se l'assistente evita 500 domande semplici al mese, il valore è operativo: ore del team, tempi di risposta, copertura fuori orario, lingue. Non ogni progetto deve dimostrare fatturato diretto, ma ognuno deve avere una metrica; sul tempo che le attività ripetitive tolgono al team abbiamo scritto in le prime ore che si recuperano con le automazioni.

Quindi: chatbot AI sì o no?

Sì, quando toglie un attrito reale; no, quando serve solo a mostrare che il sito «ha l'AI». Un chatbot che risponde male, è lento, blocca il mobile, non si chiude, chiede l'email prima di aiutare, finge di essere una persona, usa dati vecchi o non passa mai a un umano peggiora il sito, e in quei casi è meglio non averlo.

Chiedersi in astratto se un chatbot conviene alle aziende porta poco lontano, perché la risposta dipende da volume, tipo di domande, costi e percorso umano. Il test è più semplice: senza chatbot, quale problema rimane? Se non sai rispondere, non costruirlo. Se invece il team perde ore sulle stesse domande, il pubblico è multilingua e molte richieste arrivano fuori orario, vale la pena progettarlo.

Per capire se ha senso nel tuo caso, raccogli per una settimana le domande che ricevi e partiamo da lì: quel campione vale più di qualsiasi demo.