Su una commessa chiusa in perdita il colpevole non è il prezzo di partenza: è la gestione commesse che si aggiorna in ritardo, con ore segnate a fine mese, materiali usciti senza una riga e varianti concordate a voce e mai fatturate.
In sintesi
- Il margine che manca a consuntivo si spiega quasi sempre con tre voci: ore registrate in ritardo, materiali imputati alla commessa sbagliata e varianti approvate a voce.
- Un software gestione commesse registra bene quello che qualcuno gli scrive dentro, ma non va a cercare i dati che restano in mail, DDT e rapportini.
- Un agente AI su questo processo ha senso solo se la commessa ha già un posto dove vivere: se il consuntivo non esiste, prima serve quello.
Dove una commessa perde margine, voce per voce
Chi lavora su commessa conosce il sintomo: il lavoro è finito, il cliente è soddisfatto, il consuntivo dice che hai guadagnato meno di quanto avevi messo a preventivo. Le cause sono quasi sempre le stesse quattro, e nessuna è il prezzo.
La prima è il preventivo costruito a memoria. Le ore vengono stimate da chi ha fatto un lavoro simile due anni prima, non lette dal consuntivo di quel lavoro. Un software preventivi o un software computo metrico ti aiuta a comporre la cifra in modo ordinato, ma pesca dai listini e dai tuoi coefficienti, non dalla storia reale delle tue commesse chiuse.
La seconda sono le ore non registrate. I rapportini arrivano a fine mese, su carta o su un messaggio, e chi li inserisce deve decidere a quale commessa attribuire mezza giornata descritta come “intervento in cantiere”. Nel dubbio sceglie la commessa più grande, che è quella che assorbe tutto senza far rumore.
La terza sono i materiali. Un pezzo esce dal magazzino per chiudere un’urgenza su un altro lavoro e nessuno cambia la riga. A fine commessa il materiale risulta consumato dove non è stato montato.
La quarta, la più costosa, sono le varianti. Il capocantiere concorda una modifica per telefono, il cliente la conferma con una mail di tre righe, il lavoro viene eseguito. Quella mail non diventa né un ordine né una riga in commessa, e a fine lavoro nessuno la ritrova. Hai eseguito lavoro reale e non lo hai fatturato.
Il software gestione commesse vede il consuntivo, non il cantiere
Qui va fatta una distinzione che decide tutto il resto. Un buon gestionale di commessa, o un software gestionale produzione, è preciso su quello che riceve: se gli scrivi un’ora, la imputa correttamente; se gli registri un movimento di magazzino, lo valorizza; se gli inserisci una variante, la porta in fattura. Non ha un problema di calcolo.
Il problema è a monte, nel modo in cui i dati gli arrivano. Le ore gli arrivano in ritardo e aggregate. I DDT dei fornitori gli arrivano come allegati in una casella di posta, e qualcuno deve aprirli, leggere le righe e decidere a quale commessa appartengono. Le varianti non gli arrivano affatto, perché vivono in una conversazione.
È lo stesso schema che si vede in altri settori dove il software chiude bene il giro amministrativo e lascia fuori il lavoro di riconciliazione: lo abbiamo descritto parlando di cosa resta a mano con un gestionale per la logistica e i trasporti. Cambia il documento, non la dinamica. Il gestionale è un registro, non un investigatore.
Per questo aggiungere un modulo in più raramente sposta il risultato. Un configuratore prodotto migliora il preventivo, non il consuntivo. Il dato che manca non è in un campo vuoto del software: è in un allegato che nessuno ha aperto.
L’agente che aggiorna la commessa leggendo mail, DDT e rapportini
Un agente AI serve esattamente in quel punto. Non sostituisce il gestionale e non rifà il preventivo: lavora sui documenti in ingresso e tiene la commessa aggiornata mentre il lavoro è ancora aperto.
In concreto, su un flusso reale l’agente presidia la casella dove arrivano i documenti di cantiere e di fornitura. Apre l’allegato, anche quando è una scansione, estrae fornitore, numero e data del DDT, righe, quantità e riferimento ordine. Cerca la commessa corrispondente con il riferimento ordine o con il nome del cantiere, scrive il movimento e mette in una lista di eccezioni tutto ciò che non ha saputo abbinare con certezza. Sulle varianti fa la cosa che oggi non fa nessuno: riconosce in una mail una conferma di modifica, la lega alla commessa e la segnala come lavoro approvato ma non ancora ordinato.
Il punto non è la bravura del modello, è il perimetro. L’agente legge, abbina, scrive e dichiara quello di cui non è sicuro. Noi costruiamo questi flussi con il Claude Agent SDK di Anthropic, lo stesso impianto descritto nella documentazione ufficiale sull’uso degli strumenti da parte dei modelli e nelle linee guida di Anthropic su come si costruiscono agenti efficaci. Polara è guidata da Luca Edward Villa e lavora su questo tipo di processi con PMI manifatturiere, impiantisti e system integrator: la pagina su come affrontiamo lo sviluppo di agenti AI descrive il metodo nel dettaglio.
Cosa pesa sui tempi di messa in produzione
L’impegno di un progetto così dipende da poche variabili concrete, e nessuna riguarda il prezzo.
Pesa dove vivono i dati. Se i DDT arrivano come PDF nativi la lettura è lineare; se arrivano come foto scattate in cantiere serve più lavoro di normalizzazione. Pesa il numero di fornitori e di formati diversi: dieci fornitori con dieci layout sono dieci casi da riconoscere. Pesa l’accesso al gestionale, e qui la differenza è netta tra un sistema con API documentate e uno che espone solo un import CSV notturno.
Pesa poi una decisione che è tua, non nostra: chi definisce le regole di abbinamento. Quando il riferimento ordine manca, l’agente deve sapere se tentare un abbinamento sul nome del cantiere o fermarsi e chiedere. Quella regola la scrive chi conosce le commesse.
Infine pesa se un percorso di approvazione delle varianti esiste già. Se oggi una variante vive solo in una telefonata, l’agente può intercettare le mail ma non inventare un processo che non c’è. Come orientamento, un audit iniziale sui processi automatizzabili dura intorno a due settimane, la costruzione di un singolo agente dalle tre alle sei settimane a seconda delle integrazioni. Il percorso completo, dalla mappatura al flusso in produzione, è descritto nella roadmap di implementazione AI.
Quando il problema è il preventivo e non il software
Ci sono casi in cui un agente sulle commesse non è la risposta, e vale dirlo prima di partire.
Se il tuo margine si perde perché preventivi sotto costo per prendere il lavoro, nessun automatismo ti salva: il dato a consuntivo ti dirà con più precisione dove hai perso, ma la decisione resta commerciale. Se gestisci poche commesse all’anno con pochi documenti ciascuna, il volume non giustifica un agente: un flusso costruito con n8n, Make o Zapier copre bene i trigger standard, e sulla scelta tra autogestirlo e farlo costruire abbiamo scritto una guida a n8n self hosted. Un agente su misura regge meglio quando gli step crescono, i formati sono molti e serve una decisione reale su ogni documento.
Ci sono anche limiti nostri da mettere sul tavolo. Polara è una struttura snella guidata dal founder: se cerchi un fornitore con trenta persone e SLA enterprise, non siamo noi. Non costruiamo modelli proprietari da zero, usiamo Claude, GPT e Gemini come componenti. E i primi trenta giorni richiedono tempo tuo: servono interviste, accesso ai dati e feedback sul prototipo. Se nessuno in azienda può dedicare quelle ore, il progetto non arriva in produzione.
Sette domande da fare a chi ti propone un agente sulle commesse
Queste domande separano chi ha già costruito questi flussi da chi ti sta vendendo una demo. Accanto a ognuna, cosa devono farti vedere.
1. Su quale documento parte il flusso, e me lo fate vedere su un mio DDT vero? Devono chiederti un documento reale, non usare il loro esempio.
2. Cosa fa l’agente quando non riesce ad abbinare una riga a una commessa? La risposta giusta è una lista di eccezioni con un responsabile, non un abbinamento forzato.
3. Chi scrive le regole di abbinamento e dove sono scritte? Devono mostrarti un posto leggibile, non codice sepolto.
4. Come entra nel gestionale: API, import o scrittura manuale assistita? Devono sapere già quale, per il tuo gestionale.
5. Come riconoscete una variante approvata in una mail e cosa ne fate? Qui si vede chi ha lavorato su commesse e chi no.
6. Chi interviene quando l’agente sbaglia e in quanto tempo? Serve un nome e un canale, non un indirizzo generico.
7. Cosa resta mio se ci fermiamo dopo il primo flusso? Regole, prompt e accessi devono restare tuoi.
Il criterio di valutazione complessivo è semplice: giudica chi ti propone il lavoro sul metodo e sulla trasparenza, non sulla ricchezza della presentazione. Un fornitore solido ti dice anche dove il suo approccio non conviene, ti mostra un flusso già in produzione da qualche parte e accetta di partire da un processo stretto e misurabile invece che dal progetto completo.
Domande frequenti
Devo cambiare gestionale per mettere un agente sulle commesse?
No, ed è il motivo per cui conviene partire da qui. L’agente lavora sopra il gestionale che hai: legge i documenti, li interpreta e scrive il dato dove il gestionale lo aspetta.
Quanto è affidabile la lettura di un DDT scansionato male?
Non arriva al cento per cento, e un fornitore serio non lo promette. Quello che si può garantire è che i casi dubbi finiscano in una lista di eccezioni invece di entrare silenziosamente in commessa con il valore sbagliato.
Funziona anche per le ore dei tecnici, non solo per i materiali?
Sì, se le ore arrivano in un formato leggibile: un messaggio, un modulo, un rapportino fotografato. L’agente estrae tecnico, data, durata e cantiere, e segnala quando la descrizione non basta per attribuire la mezza giornata.
Se lavori su commessa e vuoi capire da dove si parte, fai un conto su tre commesse chiuse: quante varianti sono state concordate a voce e quante sono finite in fattura. La differenza tra quei due numeri è la cifra che stai cercando. Da quel conto parte il lavoro che descriviamo nella pagina dedicata agli agenti AI per system integrator e impiantisti.
