01
Documenti che diventano lavoro
Leggere richieste, allegati o moduli; estrarre ciò che conta; preparare una bozza; chiedere conferma quando manca un dato.
Preventivi, intake, pratiche, report, contratti in revisione.
Automazioni AI in Italia
Automazioni AI che reggono il lavoro reale.
Non parto dal modello. Parto da una coda di lavoro, dalle eccezioni che la rallentano e dalla persona che ne risponde. Poi costruisco il tratto di sistema che può davvero restituire tempo senza perdere controllo.
Per founder, responsabili operations e team italiani che hanno già un processo, non per chi cerca una demo da mostrare.
Automatizzare non significa aggiungere un chatbot.
Il valore appare quando un sistema prende in carico un passaggio operativo ben delimitato, usa i dati giusti e sa quando fermarsi.
02
Code operative che chiedono giudizio
Classificare, arricchire e instradare casi senza trattare ogni eccezione come se fosse uguale alla precedente.
Inbox condivise, ticket, lead, richieste fornitori, escalation.
03
Sistemi che non si parlano
Collegare gli strumenti già in uso e conservare la provenienza dei dati, invece di creare un altro pannello da mantenere.
CRM, ERP, email, fogli, database, portali interni.
Cinque domande prima di spendere un euro.
Una buona azienda di automazioni AI dovrebbe anche dirti quando non costruire. Questo è il filtro che uso all'inizio.
Il lavoro si ripete abbastanza da poterlo osservare?
Segnale buono: Esistono casi reali, esempi e una frequenza riconoscibile.
Segnale di cautela: Il processo cambia ogni volta e nessuno sa descriverlo allo stesso modo.
I dati necessari sono accessibili e affidabili?
Segnale buono: Fonti e permessi sono noti; gli errori hanno un proprietario.
Segnale di cautela: I dati vivono solo nella memoria delle persone o in file senza storia.
Le eccezioni possono essere nominate?
Segnale buono: Sappiamo quando il sistema deve fermarsi e chi deve decidere.
Segnale di cautela: L'obiettivo implicito è automatizzare tutto, anche i casi ambigui.
L'esito si può misurare prima del build?
Segnale buono: Tempo, errori, attesa o capacità hanno una baseline osservabile.
Segnale di cautela: Il successo viene descritto soltanto come innovazione o uso dell'AI.
Qualcuno possiede il processo dopo il lancio?
Segnale buono: Esiste un responsabile per regole, eccezioni e miglioramenti.
Segnale di cautela: Il sistema dovrebbe funzionare da solo senza manutenzione né decisioni.
Tre o più segnali di cautela non significano no. Significano che il primo progetto è rendere il processo osservabile.
Esperienza di produzione, non teatro dell'AI.
Ho passato quindici anni a costruire software con utenti, incidenti, scadenze e conseguenze reali: dalle startup di Londra al fintech di Amsterdam, fino ai sistemi AI e alle lezioni di AI applicata in SDA Bocconi. Porto la stessa disciplina nelle automazioni aziendali.
- 15+: anni di software engineering
- Seed → IPO: leadership in un prodotto cresciuto fino alla quotazione
- 3,2★ → 4,7★: rating App Store nel lavoro con il team bunq
- SDA Bocconi: due lezioni su AI applicata e agentic AI
Questi sono fatti sulla mia esperienza. Il risultato della tua automazione verrà definito e misurato sul tuo processo, non preso in prestito da un caso altrui.
Prima il processo. Poi il sistema. Infine la prova.
Quattro passaggi, ciascuno con un'uscita verificabile. Se un passaggio non regge, non si nasconde il problema nel codice.
01
Osservare
Ricostruiamo il lavoro com'è davvero: input, decisioni, attese, passaggi manuali, eccezioni e costo corrente.
Output: mappa del flusso e baseline.
02
Delimitare
Scegliamo il tratto da automatizzare, ciò che resta umano, i dati consentiti e le condizioni di arresto.
Output: perimetro, responsabilità e criteri di accettazione.
03
Costruire
Colleghiamo i sistemi, rendiamo visibili le decisioni e trattiamo errori e rollback come parte del prodotto.
Output: automazione verificabile in un ambiente controllato.
04
Provare
Confrontiamo il nuovo flusso con la baseline. Si estende solo ciò che riduce davvero lavoro, attesa o rischio.
Output: risultato pre/post e decisione di rollout.
Un sì utile vale quanto un no detto in tempo.
Ha senso parlarne se
- un processo assorbe ore ogni settimana o rallenta ricavi e servizio;
- il team usa già strumenti digitali ma passa il tempo a ricopiare e controllare;
- gli errori o le attese hanno un costo riconoscibile;
- vuoi partire da un perimetro piccolo e provarlo seriamente.
Probabilmente non serve ancora se
- cerchi una funzione AI da aggiungere senza un problema operativo preciso;
- nessuno può mostrare casi reali del lavoro da automatizzare;
- non esiste un responsabile del processo;
- il progetto richiede di eliminare ogni controllo umano fin dal primo giorno.
Automatizzare i preventivi senza automatizzare gli errori.
Ho pubblicato il metodo completo applicato a un flusso che molte PMI conoscono: dati cliente, regole di prezzo, eccezioni, revisione umana e scelta fra SaaS e sistema su misura.
Quello che conviene chiarire subito.
Che cosa fa un'azienda di automazioni AI?
Dovrebbe studiare un processo, scegliere un perimetro utile, collegare dati e strumenti, gestire eccezioni e controllo umano, poi dimostrare il risultato rispetto a una baseline. Se vende soltanto un chatbot o una demo, sta coprendo una parte molto più piccola del problema.
Quanto costa un progetto di automazione AI?
Dipende dall'accesso ai dati, dal numero di sistemi coinvolti e dal rischio delle azioni. Quando il caso d'uso non è ancora definito, parto da un AI Assessment da 5.000 euro. Un'implementazione completa parte normalmente da 40.000 euro. Lo scope viene prima del preventivo.
Quanto tempo serve?
Un assessment mirato può chiudersi in una settimana. Specifiche complete richiedono in genere due o tre settimane. Una soluzione implementata richiede spesso da sei a dodici settimane, ma il calendario ha senso solo dopo aver delimitato processo, integrazioni ed eccezioni.
Lavori con aziende italiane anche se DL Solutions ha base ad Amsterdam?
Sì. Sono italiano, lavoro in italiano e nel fuso italiano; l'Italia è il mercato primario. La sede olandese è la base legale e operativa, non una barriera al lavoro con team e aziende in Italia.
È necessario sostituire i software che usiamo già?
Di solito no. Il primo obiettivo è usare meglio ciò che esiste, collegando sistemi e dati con responsabilità chiare. Si sostituisce uno strumento solo quando il vincolo è dimostrato, non per rendere il progetto più appariscente.
Porta il processo, non una lista di tecnologie.
Scrivimi qual è il lavoro che si accumula, chi lo gestisce e cosa succede quando va storto. La prima risposta sarà una valutazione di fit, non una demo automatica.