Un agente AI per le richieste dei clienti via email: come si costruisce
Dall'email in arrivo all'offerta approvata: i sei passaggi, gli strumenti in Microsoft 365, cosa può andare storto a ogni passo, le regole scritte prima, il registro e il collaudo su 40 email di prova.
Un'azienda di forniture tecniche, 30 persone, Mendrisiotto. Nella casella info@ arrivano 70 email al giorno: richieste d'offerta, domande di assistenza, fornitori, solleciti, pubblicità. Due persone le smistano a turno. Quando c'è da fare un'offerta, cercano il cliente nel CRM, aprono il listino, ricopiano tutto in un modello Word e lo mandano al commerciale. Tempo medio di risposta a una richiesta d'offerta: due giorni. Nel frattempo il cliente ha scritto anche a un concorrente.
È un esempio costruito, non un cliente. Ma è il caso che mi viene descritto più spesso, e nella pagina sugli agenti AI con controllo l'ho usato come demo. Qui lo smonto passo per passo: cosa fa l'agente, con quale strumento, cosa può andare storto e come si gestisce. Se non hai ancora chiaro cosa sono davvero gli agenti AI, parti da lì.
L'agente legge, classifica, recupera i dati e prepara. La risposta al cliente parte solo dopo il clic del commerciale in Teams. Ogni passaggio lascia una riga nel registro, e prima di entrare in uso l'agente passa 40 email di prova con la risposta attesa scritta in anticipo.
Cosa deve fare l'agente, e cosa no?
Il compito, in una frase: leggere ogni email che arriva su info@, capire di cosa si tratta, e per le richieste d'offerta preparare una bozza di risposta e di offerta con i dati del CRM, da far approvare al commerciale. Se la frase non sta in una riga, il compito è troppo largo e va spezzato.
Cosa resta alle persone, scritto prima di costruire:
- La decisione. Nessuna email con un prezzo, una condizione o un impegno esce senza l'approvazione del commerciale.
- I casi fuori regola. Cliente sconosciuto, prezzo fuori listino, reclamo: l'agente prepara quello che può e passa la mano, con il motivo.
- La correzione delle regole. Quando l'agente sbaglia, una persona dice dove. Nelle prime settimane è la parte più importante del lavoro.
Un'avvertenza: l'AI non è obbligatoria. Se le richieste arrivassero da un modulo con campi fissi, basterebbe un'automazione senza AI. Qui serve perché le email sono testo libero, con allegati, a volte in tedesco, e c'è da capire cosa chiede il cliente.
Come funziona, passo per passo?
Sei passaggi. Per ognuno: cosa succede, con quale strumento, cosa può andare storto, come si gestisce. Gli strumenti sono quelli di una PMI già su Microsoft 365; è come costruisco un agente nella maggior parte dei casi, perché dati e permessi restano dove stanno.
01 · Email in arrivo e lettura
Un'email arriva nella casella condivisa info@ su Exchange. Un flusso Power Automate si attiva all'arrivo, legge mittente, oggetto, corpo e allegati, converte i PDF in testo e passa tutto al passaggio successivo. Nulla viene ancora deciso: l'email resta nella casella.
- Cosa può andare storto: tre richieste nello stesso messaggio; catene di risposte dove la domanda vera è in fondo; allegati scansionati illeggibili.
- Come si gestisce: l'agente lavora sull'ultimo messaggio e tiene il resto come contesto. Se l'allegato non è leggibile, lo scrive nella bozza e non indovina. Le email con più richieste vengono segnalate, non spezzate in automatico.
02 · Classificazione, con un livello di sicurezza
Il testo passa a un modello linguistico, tramite Copilot Studio o chiamato da Power Automate, con un'istruzione precisa: assegna una sola categoria tra richiesta d'offerta, assistenza, fornitore, altro, e dichiara quanto sei sicuro, da 0 a 100. Le categorie le ha scelte l'azienda, non il modello. Sotto una soglia (nella demo, 75) l'agente non decide: inoltra l'email a una persona con la sua ipotesi e il motivo del dubbio.
- Cosa può andare storto: una richiesta d'offerta scritta come domanda generica («avete anche i raccordi da 40?»); un fornitore che scrive da un indirizzo personale; un reclamo educato che sembra una richiesta.
- Come si gestisce: esempi reali per ogni categoria nelle istruzioni, presi dalle email degli ultimi tre mesi. E la soglia: meglio dieci email in più a una persona che una classificata male con sicurezza. Nel collaudo si tara contando gli errori.
03 · Recupero dei dati
Per le richieste d'offerta, l'agente cerca il mittente nel CRM (per dominio email, poi per ragione sociale), recupera condizioni concordate e ultimi ordini, e legge dal listino su SharePoint i prezzi in vigore degli articoli citati. Se il gestionale espone la disponibilità, la legge. Tutto con i connettori di Power Automate; se il CRM non ne ha uno, con una piccola parte in Python.
- Cosa può andare storto: cliente non in anagrafica; due anagrafiche per la stessa azienda; codice articolo vecchio; listino in due versioni nella stessa cartella.
- Come si gestisce: cliente non trovato o doppio: l'agente non sceglie, segnala. Codice non riconosciuto: propone le corrispondenze più vicine, marcate da confermare. Il listino deve avere un'unica versione in vigore, con una data: se non c'è, si sistema prima. È il passaggio dove un progetto scopre che il problema erano i dati.
04 · Bozza di risposta e di offerta
Con i dati in mano, l'agente compila il modello di offerta dell'azienda (articoli, quantità, prezzi dal listino, condizioni dal CRM) e scrive la bozza dell'email di accompagnamento nel tono deciso dall'azienda. In fondo elenca le fonti usate: quale riga del listino, quale record del CRM. Se un dato manca, scrive «dato mancante: quantità non indicata» invece di riempire il buco.
- Cosa può andare storto: l'agente inventa un prezzo plausibile per un articolo che non trova; applica uno sconto visto in un ordine precedente; risponde in italiano a chi ha scritto in tedesco.
- Come si gestisce: prezzi solo dal listino, mai dal testo libero: è una regola dura del flusso, non un'istruzione al modello. Sconti solo se scritti nelle condizioni del cliente. Lingua della risposta uguale a quella dell'email, con revisione di chi la conosce.
05 · Approvazione del commerciale in Teams
Il commerciale riceve una scheda in Teams: email originale, bozza, offerta allegata, fonti, segnalazioni. Tre pulsanti: modifica, approva, rifiuta. Se modifica, l'agente registra cosa è cambiato. Se rifiuta, chiede il motivo in una riga. È il flusso di approvazione standard di Power Automate, funziona anche dal telefono. Dopo 24 ore senza risposta, la scheda passa a un sostituto definito in anticipo, e il cliente riceve intanto una conferma di ricezione con i tempi.
- Cosa può andare storto: il commerciale approva tutto senza leggere, perché la bozza «di solito è giusta»; oppure la coda di approvazioni diventa il nuovo collo di bottiglia.
- Come si gestisce: le segnalazioni stanno in cima alla scheda. Il registro conta le approvazioni senza modifiche: se arrivano al 100%, o la bozza è perfetta o nessuno legge. Le richieste semplici possono avere una corsia più corta, ma sempre con il clic.
06 · Invio e registro
Dopo l'approvazione, Power Automate invia la risposta da info@ con l'offerta allegata, la salva nella cartella del cliente su SharePoint, aggiorna il CRM (opportunità, importo, data) e scrive la riga nel registro. Le email di assistenza o dei fornitori vengono inoltrate alla casella giusta senza approvazione: sono inoltri interni, non risposte al cliente. Anche quelli finiscono nel registro.
- Cosa può andare storto: invio doppio se il flusso riparte; CRM aggiornato ma email non partita, o viceversa.
- Come si gestisce: ogni email ha un identificativo, e il flusso controlla nel registro se è già stata gestita. Le azioni finali sono in sequenza: se una fallisce, le altre non partono e una persona riceve l'avviso.
Le regole scritte prima di costruire stanno in una tabella. Questa è quella della demo, e si riusa quasi uguale in aziende diverse.
| Situazione | Cosa fa l'agente | Chi decide | Traccia |
|---|---|---|---|
| Cliente non in anagrafica | Prepara solo la bozza di risposta, senza prezzi; segnala «cliente nuovo» | Il commerciale crea il cliente e decide le condizioni | Riga con segnalazione e nome di chi ha creato il cliente |
| Richiesta ambigua | Non prepara l'offerta; prepara una risposta con le domande da fare al cliente | Il commerciale invia o integra | Riga con stato «in attesa di dati» e domande poste |
| Prezzo fuori listino | Non propone cifre; marca la richiesta come speciale con il motivo | Il responsabile commerciale | Riga con motivo e chi ha fissato il prezzo |
| Allegato illeggibile | Lo dichiara nella bozza; lavora solo sul testo dell'email | Il commerciale chiede l'allegato o lo legge a mano | Riga con «allegato non letto» e nome del file |
| Lingua diversa | Classifica comunque; prepara la bozza nella lingua del cliente, marcata per revisione | Chi conosce la lingua rivede e approva | Riga con lingua rilevata e revisore |
| Reclamo | Non risponde al cliente; inoltra al responsabile con un riassunto | Il responsabile, sempre | Riga con categoria «reclamo» e destinatario |
Se una situazione non è nella tabella, l'agente non la gestisce: si ferma e coinvolge una persona. La tabella cresce con i casi che il registro fa emergere.
Cosa resta nel registro?
Una riga per ogni passaggio di ogni email, in una lista SharePoint o in una tabella del CRM. Non serve un sistema a parte: serve che la riga ci sia, che non si possa cancellare e che chiunque la possa leggere senza aiuto. Un estratto della demo:
| Data/ora | Passaggio | Chi | Esito | Nota | |
|---|---|---|---|---|---|
| 14.10 08:12 | RQ-0412 | Classificazione | Agente | Offerta · 94 | 3 articoli, cliente noto |
| 14.10 08:13 | RQ-0412 | Bozza offerta | Agente | Pronta | listino 2026-09 · CRM #1187 |
| 14.10 09:40 | RQ-0412 | Approvazione | S. Ferrari | Approvata con modifica | consegna 10 gg → 15 gg |
| 14.10 09:41 | RQ-0412 | Invio | Agente | Inviata | CRM aggiornato · SP salvato |
| 14.10 10:05 | RQ-0415 | Classificazione | Agente | Dubbio · 61 | inoltrata a L. Keller |
| 14.10 11:30 | RQ-0416 | Recupero dati | Agente | Cliente non trovato | dominio nuovo · bozza senza prezzi |
Il registro serve a tre cose. A rispondere a «chi ha mandato questa offerta?» in dieci secondi. A vedere dove l'agente sbaglia, per categoria, e correggere le regole. E a dimostrare, se serve, che ogni risposta con un prezzo è passata da una persona.
Come si collauda prima di usarlo?
Prima che l'agente tocchi un'email vera, passa una griglia di prova. Nella demo: 40 email costruite con l'azienda, 20 tipiche, 10 incomplete, 10 fuori ambito (reclami, fornitori, pubblicità, una richiesta in tedesco). Per ognuna, la risposta attesa è scritta prima di lanciare la prova: categoria, contenuto della bozza, cosa segnalare. Senza risposta attesa non è un collaudo, è una demo.
Si misurano tre cose:
- Classificazione corretta, per categoria e per livello di sicurezza dichiarato.
- Bozze accettate senza modifiche dal commerciale che partecipa alla prova.
- Risposte inventate: un prezzo, una disponibilità, una condizione che non era in nessuna fonte. È il numero che conta di più.
Risultato della demo, non di un cliente: 33 su 40 gestite correttamente, 5 bozze utili ma incomplete, 2 risposte inventate con sicurezza, 0 uscite senza approvazione. Le due inventate erano prezzi plausibili per codici articolo non trovati. Ho spostato la regola «prezzi solo dal listino» dall'istruzione al modello a un controllo duro nel flusso, ripetuto la prova, e solo dopo l'agente è entrato in uso. È lo stesso metodo del collaudo di un sistema prima del rilascio: casi scritti, risultati contati, correzione, ripetizione.
Cosa cambia, e quanto tempo si recupera?
Prima
- Due persone smistano 70 email al giorno a mano
- Offerte preparate da zero, con ricopiature da CRM e listino
- Risposta in due giorni, tono diverso a seconda di chi scrive
- Nessuna traccia di chi ha risposto cosa
Dopo
- Email già classificate e inoltrate; le persone vedono solo i casi dubbi
- Bozza di offerta pronta in minuti, con fonti indicate
- Risposta nella giornata, stesso standard per tutti
- Registro di ogni passaggio e di ogni approvazione
Il conto del tempo, sempre nell'esempio. Se su 70 email al giorno l'agente fa risparmiare in media 4 minuti ciascuna tra lettura, smistamento, ricerca nel CRM e compilazione, sono 280 minuti al giorno: quasi quattro ore e mezza. A CHF 60 l'ora di costo interno fanno circa CHF 280 al giorno, poco più di CHF 60'000 l'anno su 220 giorni lavorativi. Il numero della tua azienda sarà diverso, e la parte più difficile da misurare non è il tempo: sono le offerte che oggi partono dopo due giorni, quando un concorrente ha già risposto. I mesi di rientro si calcolano con il preventivo in mano, non prima; cosa lo muove l'ho scritto in quanto costa un agente AI per una PMI. Le licenze Microsoft (Copilot Studio a consumo o a pacchetti, Power Automate Premium per utente) si valutano a parte sul listino in vigore.
Dove finiscono le email dei clienti?
Le email dei clienti contengono dati personali: nomi, indirizzi, a volte persone citate in un reclamo. Cinque righe, senza sostituire un avvocato. Primo: dove vengono elaborati i dati; in questo disegno restano nel tenant Microsoft 365 dell'azienda, con Copilot Studio e Power Automate nello stesso perimetro. Secondo: cosa passa da un servizio esterno; niente, se il modello è quello del tenant, altrimenti va scritto cosa riceve e cosa no. Terzo: cosa non va inviato in nessun caso; nella demo gli allegati con dati di persone non escono dal flusso. Quarto: una policy breve per chi approva, perché la scheda in Teams contiene dati del cliente. Quinto: una verifica scritta di tutto questo, parte del collaudo. Il dettaglio sugli strumenti Microsoft è nel pezzo su Copilot e nLPD, dove finiscono i dati.
Quando non conviene farlo?
- Volumi bassi. Con 10 email al giorno il tempo risparmiato non ripaga il progetto. Prima si contano le email, poi si decide.
- Risposte già standard. Se le richieste arrivano da un modulo, o se lo smistamento sta in una tabella (mittente, oggetto, parola chiave), basta un'automazione senza AI. Costa meno, non inventa, si controlla meglio.
- CRM non aggiornato. Anagrafiche doppie, condizioni scadute, listino in tre versioni. L'agente prepara offerte sbagliate con sicurezza. Prima i dati, poi l'agente, anche se significa rimandare il progetto.
Da dove partire?
Da una giornata con te e le tue email. La Diagnosi iniziale serve a contare quante richieste arrivano e di che tipo, a vedere in che stato sono CRM e listino, a decidere dove serve un'approvazione e cosa può restare un'automazione senza AI. Ricevi una nota scritta con il caso consigliato, i rischi e cosa serve per partire. Se poi si parte, la scalo dal preventivo.
Un agente per le email dei clienti funziona se ha un compito in una frase, se la risposta parte dopo il clic di una persona, se ogni passaggio resta scritto e se è stato messo alla prova prima. Se nella tua azienda c'è una casella info@ che qualcuno smista a mano, raccontamelo: in mezz'ora capiamo se serve un agente, un'automazione o nessuno dei due.
Domande frequenti
L'agente può rispondere ai clienti da solo?
No, non nel modo in cui lo costruisco. L'agente classifica, recupera i dati e prepara la bozza. Ogni risposta che contiene un prezzo, una condizione o un impegno passa dal commerciale in Teams: modifica, approva o rifiuta. Senza quel clic non parte nulla. Le sole azioni autonome sono gli inoltri interni, e anche quelli restano nel registro.
Con quali strumenti si costruisce un agente per le email in Microsoft 365?
Con quello che una PMI su Microsoft 365 ha già: Exchange e Outlook per la casella condivisa, Power Automate per il flusso e le approvazioni in Teams, Copilot Studio o un modello linguistico chiamato da Power Automate per leggere e classificare, i connettori verso il CRM e SharePoint per listino e registro. Python entra solo se il CRM non ha un connettore o gli allegati sono complessi.
Cosa succede se l'agente classifica male un'email?
Due protezioni. La prima è il livello di sicurezza: sotto una soglia definita l'agente non decide e manda l'email a una persona con la sua ipotesi. La seconda è l'approvazione: anche una richiesta classificata male arriva al commerciale come bozza, e lui la rifiuta con un motivo. Il motivo finisce nel registro e serve a correggere le regole. Nel collaudo si conta quante volte succede prima del rilascio.
Serve per forza l'AI per smistare le email dei clienti?
No. Se le richieste arrivano da un modulo con campi fissi, o se le regole di smistamento si scrivono in una tabella (mittente, oggetto, parola chiave), basta un'automazione senza AI: costa meno e si controlla meglio. L'AI serve quando le email sono testo libero, con allegati, in più lingue, e c'è da capire cosa chiede il cliente e preparare qualcosa.
Quanto tempo serve per costruirlo, e quanto costa?
Per un caso singolo come questo, dalle quattro alle otto settimane: definizione delle regole, costruzione, collaudo su 40 email di prova, consegna con documentazione. Il tempo dipende dal CRM da collegare e dallo stato dei dati. Il prezzo è a preventivo, dopo la prima call; i fattori che lo muovono sono spiegati nell'articolo su quanto costa un agente AI per una PMI.