Come Ho Costruito un Assistant Commerciale AI con Risposta in 90 Secondi

90 secondi. Non è una promessa di marketing. È il tempo medio attuale tra la ricezione di una richiesta commerciale e la prima risposta inviata da un mio cliente B2B.

Sei mesi fa, quel tempo era 4 ore e 23 minuti.

In questo articolo documento come siamo arrivati da 4 ore a 90 secondi: architettura del sistema, decisioni di build, errori commessi e corretti, pattern replicabili. Non c'è codice di un prodotto inventato. Solo il resoconto preciso di un sistema in produzione su 388 richieste reali.

Se stai costruendo qualcosa di simile — o stai valutando se abbia senso farlo — questo case study ti darà una mappa più utile di qualsiasi tutorial generico sull'AI per le vendite.

Perché il Ritardo Commerciale Non È un Problema di Personale

Ho posto la stessa domanda a tre responsabili commerciali di PMI italiane negli ultimi 12 mesi:

Quanto tempo passa, in media, tra la ricezione di una richiesta via form e la prima risposta?

Le risposte erano: "dipende da chi c'è in ufficio", "cerchiamo di rispondere entro l'ora", "a volte arrivano la sera, le gestiamo la mattina".

Nessuno sapeva il numero esatto. Nessuno aveva mai misurato.

Una ricerca su oltre 1.400 aziende B2B ha rilevato che le aziende che rispondono entro un'ora hanno una probabilità 7 volte maggiore di qualificare un lead rispetto a quelle che rispondono dopo. Entro 5 minuti: 100 volte più probabile rispetto a chi risponde dopo 30 minuti.

Il punto non è che i commerciali siano lenti. È che il processo non è progettato per la velocità. La risposta commerciale richiede: leggere la richiesta, capire il settore del cliente, recuperare materiali pertinenti, scrivere un testo che suoni umano e competente, inviarlo. Con una casella email condivisa, 12 richieste al giorno e riunioni in parallelo, 4 ore è un risultato ragionevole per un essere umano.

È un problema di architettura del sistema, non di motivazione delle persone.

L'Architettura: 3 Layer Che Non Si Toccano

La decisione progettuale più importante è stata separare nettamente i tre livelli del sistema. Non li ho mescolati. Non ho costruito un'unica pipeline che fa tutto.

Layer 1 — Ricezione e classificazione

Un webhook su n8n intercetta ogni nuova richiesta dal form del sito e dall'indirizzo email dedicato alle richieste commerciali. Claude riceve la richiesta grezza e la classifica in tre categorie: commerciale standard (gestibile in autonomia), tecnica/atipica (richiede valutazione umana), non pertinente (spam, richieste generiche non qualificate).

L'output è un oggetto JSON con il tipo di richiesta, uno score di confidenza tra 0 e 1, e una flag di priorità.

Layer 2 — Elaborazione e risposta

Per le richieste commerciali standard con score >0.85, Claude elabora la risposta partendo da tre sorgenti di contesto:

• I dati inseriti nel form (settore, dimensione aziendale, esigenza dichiarata)
• Il profilo aziendale arricchito (recuperato via API da un servizio di enrichment B2B)
• La libreria di casi d'uso verificati (document store con 23 case study interni, aggiornato ogni due settimane)

Il prompt è modulare: classificazione, arricchimento e generazione della risposta sono tre chiamate distinte al modello. Non un prompt unico.

Layer 3 — Human-in-the-loop selettivo

Le richieste con score tra 0.50 e 0.85, o classificate come tecniche, vengono inoltrate via Slack al responsabile commerciale. Il messaggio contiene: il testo originale della richiesta, il draft della risposta generato da Claude, e tre pulsanti di azione (approva, modifica, scarta). Il responsabile interviene in pochi secondi, non in ore.

Questo layer non è una rete di sicurezza. È una funzionalità progettata. Senza di essa, il sistema non avrebbe mai ottenuto l'approvazione per andare in produzione.

Le 3 Decisioni di Build Che Hanno Cambiato il Risultato

Non ogni scelta è stata corretta dalla prima iterazione. Alcune decisioni decisive sono arrivate dopo il fallimento della soluzione iniziale.

Decisione 1: API diretta via n8n vs Claude Code

Ho testato entrambi gli approcci per due settimane in parallelo.

Con Claude Code, il workflow era più rapido da prototipare ma più rigido in produzione. Ogni modifica ai prompt richiedeva un aggiornamento del codebase e un deploy. Con l'API diretta via n8n, ogni componente è isolato: il nodo del prompt è un campo di testo modificabile dall'interfaccia.

Ho scelto l'API diretta. Il motivo non era tecnico. Era operativo: il responsabile commerciale doveva poter modificare il tono e i contenuti delle risposte senza dipendere da me per ogni aggiustamento. L'autonomia operativa del cliente vale più dell'eleganza dell'implementazione.

Decisione 2: risposta immediata completa vs draft + approvazione selettiva

Il responsabile commerciale voleva risposte completamente automatiche per tutte le richieste. Io ho proposto un ibrido.

Non per sfiducia nel modello. Per una ragione più concreta: nelle prime settimane di produzione, la responsabilità commerciale non si delega completamente a un sistema non ancora calibrato. Un errore — una risposta plausibile ma sbagliata su prezzi, tempistiche o specifiche — in contesto B2B ha un costo reputazionale reale.

Il compromesso: risposta immediata automatica per le richieste con score di confidenza elevato (>0.85), draft + approvazione per le richieste al di sotto di quella soglia.

In 4 mesi di produzione: 347 risposte inviate automaticamente, 41 draft inviati per revisione umana. Di questi 41, solo 5 hanno richiesto una correzione significativa prima dell'invio. Il responsabile ha impiegato in media 23 secondi per approvare un draft.

Decisione 3: prompt monolitico vs prompt modulare

Il primo sistema che ho costruito usava un prompt unico che faceva tutto: classificava la richiesta, recuperava il contesto rilevante, costruiva la risposta, aggiustava il tono. Era lungo circa 1.800 token e produceva output inconsistenti, specialmente sulle richieste più articolate.

Ho spezzato il processo in tre chiamate sequenziali:

1. Classificazione — 150 token di prompt, output JSON strutturato con tipo e score
2. Arricchimento contesto — 300 token, input: dati form + profilo aziendale; output: riepilogo contestuale da usare nella risposta
3. Generazione risposta — 600 token, input: output del passaggio 2; output: testo finale pronto per l'invio

Latenza aggiuntiva rispetto al prompt unico: +340 ms. Qualità dell'output: nettamente superiore, con zero casi di confusione tra richieste di tipo diverso nelle ultime 200 richieste.

I Numeri in Produzione

4 mesi di sistema attivo. Campione: 388 richieste commerciali ricevute.

| Metrica | Prima del sistema | Con il sistema | Variazione |

|---|---|---|---|

| Tempo medio prima risposta | 4h 23min | 1min 31sec | -97% |

| % richieste senza risposta entro 24h | 12% | 0.3% | -97.5 pp |

| Lead qualificati nel primo contatto | 31% | 58% | +27 pp |

| Ore/giorno del commerciale su risposta iniziale | 3.2 ore | 22 min | -89% |

| Richieste gestite in autonomia dal sistema | — | 89.4% | — |

| Costo mensile infrastruttura AI (API + n8n) | — | €14 | — |

Il dato più rilevante non è la velocità. È il 58% di lead qualificati nel primo contatto: quasi il doppio rispetto al processo manuale. L'ipotesi operativa è che una risposta rapida e contestualizzata aumenti la percezione di competenza del fornitore nel momento in cui il potenziale cliente è ancora in fase di valutazione comparativa.

Il costo di €14 al mese include le chiamate all'API Claude (circa 2.000 token per richiesta, usando Claude Haiku per la classificazione e Sonnet per la generazione) e il piano n8n self-hosted su una VPS condivisa.

Cosa Non Ha Funzionato (e Come L'Ho Corretto)

Anti-pattern 1 — Arricchimento dati asincrono

Diagnosi: nella prima versione, il profilo aziendale veniva recuperato in background dopo l'invio di una risposta iniziale generica. L'idea era mandare subito qualcosa, poi seguire con una seconda email più contestualizzata. Risultato: il destinatario riceveva due email in 3 minuti. La seconda era migliore, ma la prima creava confusione e l'impressione di un sistema disorganizzato.

Fix: arricchimento sincrono prima della generazione della risposta, con una sola email inviata. Latenza aggiuntiva media: +8 secondi. Tasso di confusione: zero.

Anti-pattern 2 — Classificazione binaria senza score

Diagnosi: il primo classificatore restituiva solo "automatizzabile" o "manuale". Troppo grezzo. Molte richieste etichettate come "automatizzabili" contenevano sfumature — budget non dichiarato, richiesta implicita di demo, settore ad alta regolamentazione — che richiedevano almeno un controllo umano.

Fix: classificazione a tre livelli con score di confidenza numerico. Le soglie (0.85 e 0.50) sono state calibrate empiricamente sulle prime 80 richieste, non scelte arbitrariamente.

Anti-pattern 3 — Prompt senza esempi negativi espliciti

Diagnosi: il prompt di generazione produceva testi con tono eccessivamente formale, incluse formule tipiche della comunicazione aziendale italiana tradizionale — esattamente il contrario di quello che il cliente voleva comunicare.

Fix: aggiunto nel system prompt un blocco dedicato con 3 esempi di frasi esplicitamente vietate e 3 esempi di frasi preferite. La distinzione non era nel modello, era nel contesto fornito. Il miglioramento nella qualità del tono è stato immediato, senza modificare nulla altro.

Gli Ingredienti, Non la Ricetta

Se dovessi ricostruire questo sistema da zero con una settimana di lavoro invece di quattro mesi, mi concentrerei su quattro elementi. Non sono step di un tutorial. Sono le condizioni necessarie.

Document store con casi d'uso reali dell'azienda

Claude è tanto efficace quanto è ricco il contesto che riceve. Un assistant commerciale senza una libreria di casi d'uso verificati produce risposte generiche. Il tempo investito a documentare i propri casi d'uso reali vale 10 volte il tempo investito nell'engineering del prompt.

Livello di classificazione esplicito prima di qualsiasi risposta

Non fare rispondere il sistema senza classificare prima la richiesta. Il costo computazionale di una chiamata di classificazione separata è trascurabile (Haiku: frazioni di centesimo per richiesta). Il valore in termini di riduzione degli errori è sproporzionatamente alto.

Human-in-the-loop progettato come funzionalità, non come eccezione

L'approvazione umana selettiva non è una rete di sicurezza. È la componente che rende il sistema accettabile per chi deve usarlo. Progettala con la stessa cura del componente automatico: interfaccia semplice, notifica contestuale, azione in un click.

Logging strutturato dal primo giorno

Senza dati non puoi calibrare le soglie, non puoi misurare il miglioramento, non puoi giustificare il sistema a chi ha autorizzato il progetto. Logga ogni richiesta: timestamp, categoria classificata, score, esito (automatico/approvato/corretto/scartato). È la base di tutto il resto.

Per l'integrazione tecnica tra n8n e Claude API, con i pattern di workflow che uso per la classificazione e la generazione, ho documentato l'architettura completa nell'articolo su n8n + Claude API per il ciclo di vendita B2B. Se invece vuoi vedere come questo sistema si inserisce nel ciclo completo del cliente — dalla lead generation alla retention — il framework ciclo cliente B2B è il punto di partenza logico.

Conclusione

Un assistant commerciale AI non è un chatbot con le risposte alle FAQ. È un sistema con architettura deliberata, dati di contesto curati, e un livello umano progettato per intervenire dove la confidenza del modello scende sotto soglia.

Il risultato su 388 richieste reali: 347 risposte automatiche inviate, 89.4% di autonomia, €14 al mese di costi operativi, -97% sul tempo medio di risposta. Non perché il modello sia eccezionale in sé. Perché il sistema è costruito per far emergere la qualità del modello nel contesto giusto.

Se vuoi costruire qualcosa di equivalente per il tuo business — o per un cliente — i template di prompt per la classificazione e la generazione di risposte commerciali, insieme all'architettura n8n, sono parte del percorso Claude Mastery.

FAQ

Quanto costa costruire un sistema simile?

L'infrastruttura mensile è circa €14 (API Claude + n8n self-hosted su VPS). Il costo reale è il tempo di setup: tra le 15 e le 25 ore per un sistema funzionante con le specifiche di questo case study, dipende da quanto il document store è già strutturato.

Funziona senza un document store di casi d'uso interni?

Funziona, ma le risposte saranno generiche. Il contesto aziendale specifico è il fattore che differenzia una risposta plausibile da una risposta che genera fiducia. Senza di esso, il sistema risponde come farebbe qualsiasi strumento AI generico.

Claude può classificare erroneamente una richiesta?

Sì. Nel campione di 388 richieste, 14 classificazioni sono state corrette manualmente (3.6%). È una percentuale accettabile, ma devi monitorarla. Le soglie vanno calibrate nel tempo: i primi 100 casi sono il campione di training reale del sistema.

Lo stesso schema funziona per il supporto post-vendita?

Il pattern è trasferibile. Il document store conterrà documentazione tecnica e FAQ invece di case study commerciali, e la logica di escalation sarà orientata al supporto invece che alla qualificazione. La struttura in tre layer — classificazione, elaborazione, approvazione selettiva — rimane identica.

{
  "request_id": "req_2026_04_15_001",
  "received_at": "2026-04-15T08:12:03.000Z",
  "classification": {
    "type": "commerciale_standard",
    "confidence": 0.91,
    "priority": "alta"
  },
  "routing": {
    "auto_reply": true,
    "requires_human_review": false,
    "channel": "email"
  }
}