In molte PMI italiane il flusso degli ordini funziona ancora così: il cliente manda un’email con un PDF, un Excel o una lista scritta nel testo, e qualcuno in ufficio commerciale ricopia righe, codici, quantità e date di consegna nel gestionale. L’automazione ordini clienti con l’AI serve a togliere proprio questo passaggio: l’ordine viene letto, interpretato, confrontato con anagrafiche e listini, e arriva nel gestionale come bozza da confermare. La persona non sparisce: passa dal ricopiare al verificare solo i casi dubbi.
In questo articolo spiego come progetto un flusso del genere, quali parti affido a un modello linguistico e quali invece devono restare regole deterministiche, e dove di solito si inciampa.
Perché partire dagli ordini e non da un chatbot
Secondo i dati Istat ripresi da Confartigianato Liguria, nel 2025 il 16,4% delle imprese italiane con almeno 10 addetti usava l’intelligenza artificiale e, tra queste, la tecnologia più diffusa è l’estrazione di informazioni dai documenti (70,8%). Non è un caso: è il punto in cui l’AI produce un risultato misurabile senza dover reinventare l’organizzazione.
Gli ordini, in particolare, hanno tre caratteristiche che li rendono un buon primo progetto:
- sono ripetitivi: gli stessi clienti mandano documenti con la stessa struttura, settimana dopo settimana;
- hanno un esito verificabile: l’ordine inserito è giusto o sbagliato, non c’è margine interpretativo;
- impattano direttamente sul fatturato: un ordine inserito con un giorno di ritardo o con un codice errato si traduce in consegne sbagliate e note di credito.
Una precisazione: se i vostri clienti sono grandi catene della distribuzione che già lavorano in EDI, quella parte non va toccata con l’AI. Il problema da risolvere è la coda lunga di clienti medi e piccoli che ordinano "come capita".
L’architettura del flusso, passo per passo
Lo schema che uso più spesso si costruisce bene con n8n come orchestratore dei flussi di lavoro, ma la logica vale anche con Make o con codice su misura.
- Ricezione: una casella dedicata (ad esempio ordini@azienda.it) monitorata via IMAP, oppure un inoltro automatico dalle caselle dei commerciali. Ogni messaggio viene salvato con allegati e un identificativo univoco.
- Classificazione: un primo passaggio con il modello decide che cosa è il messaggio. Nuovo ordine, modifica di un ordine esistente, sollecito, richiesta di offerta, altro. Solo i primi due proseguono nel flusso.
- Estrazione: il modello legge PDF, Excel o testo e restituisce un JSON con uno schema fisso: cliente, riferimento ordine del cliente, data, destinazione merce, righe con codice, descrizione, quantità, unità di misura, prezzo indicato, data di consegna richiesta.
- Normalizzazione: qui lavorano le regole, non l’AI. Si riconosce il cliente in anagrafica, si traducono i codici articolo, si convertono le unità di misura, si confrontano i prezzi con il listino o le condizioni contrattuali.
- Validazione e coda di revisione: se tutto torna, l’ordine viene preparato per l’inserimento; se qualcosa non torna, finisce in una coda dove un operatore vede documento originale e dati estratti affiancati.
- Scrittura nel gestionale: tramite API, file di import o tabella di appoggio, a seconda di cosa permette il vostro software.
- Conferma: email di conferma d’ordine al cliente, generata dal gestionale o dal flusso, con eventuali righe non evadibili evidenziate.
Il punto critico: la transcodifica degli articoli
Leggere un PDF oggi è la parte facile. Il lavoro vero è capire che "VITE TE 8×40 ZN conf. 100" del cliente corrisponde al vostro articolo interno con un codice completamente diverso, venduto a pezzi e non a confezioni.
L’approccio che funziona è a strati:
- tabella di transcodifica per cliente: codice cliente → codice interno. È la fonte più affidabile e va costruita fin dall’inizio, anche partendo dallo storico degli ordini già inseriti;
- ricerca semantica come proposta: se il codice non è in tabella, il sistema cerca gli articoli più simili per descrizione e li propone all’operatore, senza mai sceglierli in autonomia;
- apprendimento dalla revisione: quando l’operatore conferma un abbinamento, questo entra nella tabella. Il secondo ordine dello stesso cliente con quel codice passa senza intervento.
Lo stesso vale per le unità di misura e per le destinazioni merce: un cliente con cinque punti di consegna scritti ogni volta in modo diverso è un classico caso da normalizzare con una tabella, non da lasciare all’interpretazione del modello.
Controlli e revisione umana: dove mettere l’asticella
Un ordine sbagliato inserito in automatico è peggio di un ordine inserito in ritardo. Per questo il flusso deve sapere quando fermarsi. Le condizioni che mando sempre in revisione sono:
- cliente non riconosciuto o riconosciuto con dubbio;
- articolo senza transcodifica certa;
- prezzo indicato dal cliente diverso dal listino oltre una soglia definita con voi;
- quantità fuori dal range abituale per quel cliente e quell’articolo (un ordine da 1.000 dove di solito sono 10);
- date di consegna incompatibili con i tempi di evasione;
- somma delle righe che non coincide con il totale riportato nel documento.
All’inizio conviene mandare in revisione tutto, anche gli ordini che sembrano perfetti, per alcune settimane. Serve a misurare quanto spesso il sistema sbaglia e su cosa. Poi si sblocca l’inserimento diretto solo per i clienti e le tipologie di ordine che hanno dimostrato di passare senza correzioni. Ho approfondito questa logica nell’articolo su quando gli agenti AI devono chiedere conferma.
Duplicati e modifiche
Due problemi pratici che emergono subito: lo stesso ordine inviato due volte (magari prima al commerciale e poi alla casella ordini) e le modifiche ("sostituite la riga 3, aggiungete 20 pezzi"). La soluzione è una chiave univoca basata su cliente e numero d’ordine del cliente, verificata prima di ogni inserimento, più una gestione esplicita delle revisioni. È lo stesso principio di idempotenza che applico alle integrazioni via webhook: ogni operazione deve poter essere ripetuta senza creare doppioni.
Integrazione con il gestionale: cosa chiedere al vostro fornitore
Molti gestionali diffusi nelle PMI italiane non espongono API moderne. Non è un ostacolo insormontabile, ma va chiarito prima di partire. Le strade possibili, in ordine di preferenza:
- API ufficiali del gestionale per creare ordini cliente;
- import da file (CSV, XML o tracciati proprietari) che il gestionale già supporta, magari usati oggi per altri scopi;
- tabella di appoggio concordata con il fornitore del gestionale, da cui una sua procedura legge gli ordini;
- automazione dell’interfaccia (RPA) solo come ultima risorsa, perché fragile a ogni aggiornamento.
Quello che sconsiglio è scrivere direttamente nel database del gestionale senza il consenso di chi lo mantiene: si rischia di saltare controlli interni e di perdere l’assistenza.
Dati, privacy e scelta del modello
Gli ordini contengono dati commerciali sensibili e dati personali dei referenti. Prima di mandarli a un servizio esterno vanno verificati: dove vengono elaborati, se il fornitore li usa per addestrare i modelli, quale accordo di trattamento dati (DPA) è previsto ai sensi del GDPR. Per molte aziende è sufficiente un fornitore con elaborazione nell’Unione Europea e opzione di non conservazione; per altre ha senso un modello self-hosted, che per l’estrazione strutturata da documenti di solito basta.
C’è anche un aspetto organizzativo: l’Osservatorio del Politecnico di Milano rileva che 8 lavoratori su 10 che usano l’AI in Italia lo fanno con strumenti personali (fonte). Se il vostro ufficio commerciale sta già incollando ordini in un chatbot personale per velocizzare l’inserimento, un flusso aziendale controllato è anche un modo per riportare quei dati dentro un perimetro gestito.
Come partire senza un progetto enorme
Il percorso che propongo di solito:
- analisi dello storico: quali clienti mandano più ordini, in quali formati, con quali errori ricorrenti;
- pilota su pochi clienti ad alto volume, con revisione completa;
- misurazione di due indicatori semplici: percentuale di ordini passati senza correzioni e tempo tra ricezione e inserimento;
- estensione graduale ad altri clienti e sblocco dell’inserimento diretto dove i dati lo giustificano.
Non vi do numeri di risparmio a priori: dipendono dal volume, dalla varietà dei formati e da quanto sono ordinate le vostre anagrafiche. Li misuriamo insieme durante il pilota.
Domande frequenti
Devo cambiare gestionale per automatizzare gli ordini?
Quasi mai. Nella maggior parte dei casi basta un canale di import già previsto dal gestionale o una tabella di appoggio concordata con il fornitore. Il cambio di gestionale è un progetto diverso, da valutare per altri motivi.
L’AI funziona anche con ordini scritti a mano o fotografati?
I modelli multimodali leggono anche scansioni e foto, ma la qualità dell’estrazione cala. Questi ordini vanno sempre in revisione e, se sono frequenti, conviene proporre al cliente un modulo semplice o un portale.
Cosa succede se il modello sbaglia un codice articolo?
Se il flusso è progettato bene, non dovrebbe arrivare nel gestionale: un codice senza transcodifica certa viene fermato e proposto all’operatore. L’errore diventa una correzione in revisione, che arricchisce la tabella per gli ordini successivi.
Si può usare lo stesso flusso per i DDT e gli ordini a fornitore?
Sì, la struttura è la stessa: ricezione, estrazione, normalizzazione, controlli, scrittura. Cambiano le regole di validazione e le tabelle di riferimento. Di solito conviene consolidare prima gli ordini cliente e poi estendere.
Portare gli ordini nel gestionale senza ricopiarli
Se il vostro ufficio commerciale passa ore a trascrivere ordini da email e allegati, il problema è concreto e si risolve con un flusso progettato su misura per i vostri clienti, i vostri codici e il vostro gestionale. Lavoro da Ravenna con aziende in tutta Italia e in Europa: analizzo lo storico, costruisco il pilota e lo porto in produzione con i controlli giusti. Se volete valutare il vostro caso, contattatemi qui e partiamo dai vostri ordini reali.
