Gli errori nelle automazioni AI delle PMI quasi mai riguardano il modello: nascono nelle prime due settimane, quando si sceglie il processo sbagliato, si parte senza un dato di partenza e nessuno in azienda resta proprietario del flusso.
In sintesi
- Il modello non è il collo di bottiglia: Claude e GPT reggono la quasi totalità dei flussi di una PMI, mentre la scelta del processo e la qualità dei dati decidono l’esito.
- Sei dei sette errori più frequenti si vedono prima di scrivere una riga di codice, quindi si fermano in riunione e non in produzione.
- Un’automazione senza baseline e senza referente interno non è un progetto tecnico fallito, è un progetto che nessuno può dire se ha funzionato.
I sette errori, e il segnale che li annuncia
Ogni errore ha un sintomo che si riconosce in anticipo. Se nelle prime conversazioni senti la frase nella colonna di destra, l’errore è già in casa.
| Errore | La frase che lo annuncia |
|---|---|
| Automatizzare un processo non scritto | “Dipende dal caso, lo vede il commerciale” |
| Partire dal tool invece che dal problema | “Abbiamo già Make, cosa ci mettiamo dentro?” |
| Nessun dato di partenza | “Ci mettiamo un po’, comunque troppo” |
| Dati a monte sporchi | “Il CRM va sistemato, poi lo facciamo” |
| Tutto automatico dal primo giorno | “Mandiamo le mail direttamente, senza passaggi” |
| Nessun proprietario interno | “Lo seguiamo un po’ tutti” |
| Confondere regola e agente | “Mettiamoci l’AI, intanto” |
I primi due sono errori di sequenza: si decide lo strumento prima del processo. Il terzo e il quarto sono errori di dati, e sono quelli che costano più tempo a recuperare in corsa. Gli ultimi tre si pagano dopo il lancio, quando il flusso gira ma nessuno lo governa.
Processo rotto o processo non scritto: due diagnosi diverse
Questi due casi si assomigliano in riunione e portano a decisioni opposte, quindi vale separarli.
Un processo non scritto funziona nella testa di chi lo esegue. Esiste, è coerente, non è documentato. Qui l’automazione è possibile: serve una settimana di interviste a chi lo fa, si mette su carta, si automatizza quello che è stato scritto.
Un processo rotto non è coerente nemmeno quando lo esegue una persona. Due colleghi qualificano lo stesso lead in modo diverso e nessuno sa dire quale dei due ha ragione. Automatizzarlo rende l’incoerenza più rapida e più difficile da vedere, perché la decisione sbagliata esce con lo stesso tono di quella giusta.
La prova che li distingue: chiedi a due persone che fanno lo stesso lavoro di descrivere il flusso separatamente. Se le due descrizioni coincidono, il processo è solo non scritto. Se divergono su cosa fare in un caso frequente, è rotto, e prima di automatizzare va deciso chi ha ragione.
Regola, workflow o agente: la griglia per non comprare lo strumento sbagliato
Il secondo errore della tabella si ferma con una scelta a tre, non a due. La maggior parte dei flussi di una PMI non ha bisogno di un agente, e usarne uno dove basta una regola aggiunge costo e punti di rottura.
| Serve quando | Strumento | Esempio concreto |
|---|---|---|
| L’input è strutturato e la decisione è fissa | Automazione a regole | Una riga nuova nel foglio apre un task in Asana |
| Più passaggi tra app note, logica prevedibile | Workflow su n8n, Make o Zapier | DDT firmato, archiviazione, notifica al cliente |
| L’input è testo libero e la decisione cambia | Agente AI | Leggere la mail, capire l’intento, aprire il deal giusto |
La riga che le PMI saltano più spesso è la prima. Anthropic, nella sua guida tecnica building effective agents, arriva alla stessa conclusione dal lato ingegneristico: conviene partire dalla soluzione più semplice che risolve il compito e salire di complessità solo quando quella non basta. Vale anche al contrario: quando il processo cresce di volumi e di eccezioni, un workflow a regole diventa un albero di condizioni che nessuno osa più toccare. La distinzione nel dettaglio è in agenti AI vs Zapier.
Come si misura un’automazione che funziona
Senza un numero raccolto prima, a fine progetto resta un’impressione. Il dato di partenza non deve essere preciso, deve essere ripetibile: lo stesso conteggio, fatto con lo stesso criterio, prima e dopo.
Il metodo che usiamo con i clienti è il test delle venti esecuzioni. Prendi venti casi reali del processo candidato, gli ultimi venti, non i venti più comodi. Per ognuno segna tre cose: minuti impiegati, chi li ha impiegati, e se l’esito è stato corretto al primo colpo. Mezza giornata di lavoro e hai la baseline.
Dopo il lancio ripeti lo stesso conteggio sulle prime venti esecuzioni dell’agente. Il confronto dice tre cose che una demo non dice: quanto tempo è uscito dal processo, quanto ne è rientrato sotto forma di revisione, e su quali casi l’agente sbaglia in modo sistematico. Le eccezioni raggruppate sono la lista di lavoro del mese successivo, non un difetto da nascondere.
Luca Edward Villa parte da questo conteggio in ogni progetto, prima di proporre qualsiasi architettura: su un flusso di qualificazione lead il test delle venti esecuzioni ha più volte spostato la scelta dall’agente a un workflow a regole, perché i venti casi erano più regolari di come li descriveva il team commerciale.
Chi resta proprietario del flusso dopo il lancio
Gli errori sei e sette della tabella si pagano al terzo mese, quando un fornitore cambia un campo nel CRM o una persona lascia l’azienda. Un’automazione senza un referente interno non si rompe con un errore: smette lentamente di essere vera, perché il processo si muove e lei resta ferma.
Il referente non deve saper programmare. Deve sapere tre cose: cosa fa il flusso passo per passo, dove guardare quando un caso non è stato gestito, e chi chiamare per cambiarlo. Una persona, con un nome, scritta nel documento di consegna.
Questo vale anche per chi costruisce. Nei primi 30 giorni serve il tuo tempo, non solo il nostro: interviste a chi esegue il processo oggi, accesso ai dati reali, feedback sul prototipo entro pochi giorni. È il punto su cui più progetti si fermano, e non per ragioni tecniche. Se in quelle settimane nessuno in azienda ha spazio in calendario, conviene spostare la partenza invece di consegnare un agente che nessuno ha validato.
Quando aspettare è la decisione corretta
Tre situazioni in cui la risposta onesta è rinviare. Il processo cambia ogni mese per ragioni esterne, ad esempio una normativa in movimento o un cliente che ridefinisce le forniture: qui si automatizza una fotografia che scade. I dati esistono solo su carta o in caselle di posta personali: prima va creato il luogo dove stanno, poi si legge. Nessuno ha tempo nei primi 30 giorni: vedi il punto sopra.
Rinviare di un trimestre con una baseline in mano batte un avvio rapido che si ferma alla quarta settimana. L’ordine in cui affrontare i processi, una volta che il primo gira stabile, è il contenuto di una roadmap di implementazione AI.
Domande frequenti
Qual è l’errore più frequente nelle automazioni AI per le PMI?
Automatizzare un processo che non è ancora scritto. Se il flusso vive nella testa di chi lo esegue, l’AI lo eseguirà più in fretta con le stesse ambiguità, rese meno visibili. La scrittura del processo viene prima dello sviluppo, e richiede giorni, non settimane.
Come capisco se mi serve un agente o basta un workflow?
Guarda l’input. Se arriva strutturato e la decisione è sempre la stessa, bastano una regola o un workflow. Se arriva come testo libero e la decisione cambia caso per caso, serve un agente. La griglia a tre righe sopra copre quasi tutti i flussi di una PMI.
Quanto tempo serve per raccogliere una baseline?
Mezza giornata con il test delle venti esecuzioni. Venti casi reali, tre dati per ognuno: minuti, persona, esito corretto al primo colpo. È il minimo per poter dire, a fine progetto, se qualcosa è cambiato.
Da quanti processi conviene partire?
Da uno, scelto per frequenza, prevedibilità e costo del tempo di persone qualificate. Un processo stabile diventa la base dei successivi, perché i dati e le integrazioni sono già in piedi. Partire da molti insieme è l’errore che blocca più progetti nelle prime settimane.
Se hai riconosciuto due o tre di questi errori in un progetto che sta per partire, il passo utile prima di firmare è fare il test delle venti esecuzioni sul processo candidato: in mezza giornata sai se il problema è il flusso, i dati o nessuno dei due. Con quei numeri in mano, la pagina sullo sviluppo di agenti AI descrive come si passa dal processo scritto all’agente in produzione, e chi resta proprietario del flusso dopo la consegna.
