Alessandro Frau

ProblemaIl titolare decideva gli acquisti senza conoscere il peso reale di alimenti e bevande. I dati c'erano, chiusi negli XML delle fatture elettroniche.

Cosa ho costruitoUn sistema che legge le fatture FatturaPA, classifica ogni riga per centro di costo e mostra costi e margine in una dashboard. Un modello linguistico classifica solo i prodotti nuovi; gli altri arrivano dal catalogo.

I limiti di Apps Script come scelte di progetto

• Il foglio non è il database. La fonte della verità sono gli XML su Drive: il foglio si ricostruisce da zero in qualsiasi momento.
• Il limite di tempo diventa un lotto. La ricostruzione procede a blocchi, così anche anni di fatture non si interrompono a metà.
• Le quote spingono al riuso. Più cresce il catalogo, meno chiamate al modello e classificazioni sempre coerenti.
• Nessun server. Tutto resta nell'account Google del cliente, a costo quasi nullo.

ProblemaNei CRM restano centinaia di contatti che hanno chiesto un preventivo o comprato una volta, poi sono spariti. Nessuno li ricontatta: non c'è tempo, e non si sa da chi partire.

Cosa ho costruitoPico è un mio prodotto. Scrive su WhatsApp ai contatti fermi nel CRM, porta avanti la conversazione, capisce anche i vocali e passa all'attività chi è pronto a comprare o prenotare. Il primo cliente ha registrato un aumento delle vendite grazie ai lead dormienti tornati attivi.

Scelte tecnicheIntegrazione diretta con le API ufficiali di Meta, trascrizione dei vocali, stato delle conversazioni persistito. L'architettura è riusabile: la sto adattando a un secondo caso d'uso, la reportistica dei team sul campo.

ProblemaChiamate, messaggi e appuntamenti vivevano in strumenti separati, senza uno storico unico del paziente.

Cosa ho costruitoUn CRM su Odoo per il call center della clinica, in un team di tre sviluppatori. Ho curato la parte Odoo e le integrazioni.

• Le chiamate entrano in Odoo. Ogni chiamata del centralino cloud si aggancia al contatto riconosciuto dal numero. Se il numero è nuovo, nasce un contatto e il primo interesse diventa un'opportunità.
• WhatsApp nello stesso storico. Le conversazioni arrivano nella scheda del paziente accanto alle chiamate, e l'operatore risponde da Odoo senza cambiare strumento.
• Un percorso fino all'appuntamento. La pipeline segue le fasi reali del call center, dal primo contatto alla visita, con promemoria per i richiami.
• Sviluppo in un ambiente isolato. Odoo 17 in container con il proprio database, separato da ogni altro progetto: niente moduli o dati condivisi tra clienti.
• Modulo neutro. Il modulo non porta il marchio di chi rivende il servizio, quindi si può installare su un altro cliente senza riscriverlo.

ProblemaUna società di servizi per la sicurezza sul lavoro gestisce le aziende clienti con un gestionale datato. Ogni assunzione o cessazione va poi riportata a mano su Cartsan, la piattaforma di medicina del lavoro: doppio inserimento ed errori.

Cosa ho costruitoOdoo al posto del vecchio gestionale, come unico punto di inserimento per aziende, dipendenti e calendario. Cartsan si aggiorna da solo.

• Sincronizzazione su evento. Quando in Odoo si inserisce un dipendente o se ne registra la cessazione, Odoo chiama le Web API di Cartsan e aggiorna l'anagrafica. Niente esportazioni né reinserimenti.
• Prima lo sviluppo, poi la produzione. L'integrazione è stata costruita e collaudata sull'ambiente di sviluppo di Cartsan, a partire dalla documentazione Swagger delle API, e solo dopo portata sui dati reali.
• Mappatura tra due modelli dati. Aziende, sedi e dipendenti sono organizzati in modo diverso in Odoo e in Cartsan: la corrispondenza tra i campi è esplicita e documentata, così si può verificare e mantenere.
• Errori visibili, non persi. Se Cartsan rifiuta un aggiornamento, l'operazione resta segnalata in Odoo e si può ripetere, invece di sparire in silenzio.
• Recupero dello storico. Il database MySQL del vecchio gestionale è la base per migrare anagrafiche e rapporti esistenti.
• Perimetro a fasi. Ho segnalato che il budget iniziale non copriva il progetto completo. Il primo rilascio è stato ristretto al flusso con più valore, la sincronizzazione dei dipendenti verso Cartsan.

ProblemaL'azienda usa un ERP proprietario installato su un server in sede, gestito da un fornitore esterno. Vuole uscire dall'intero ecosistema del vecchio fornitore, non solo cambiare un modulo.

Cosa sto facendoIl progetto è nato come integrazione via API con l'ERP esistente. Dall'analisi è emerso che la scelta giusta era una migrazione completa, e il perimetro è cambiato di conseguenza.

• Analisi con il fornitore uscente. Partecipo agli incontri tecnici con chi gestisce oggi ERP e server, per mappare dati, database e dipendenze prima di pianificare il passaggio.
• Dal server in sede al cloud gestito. L'ipotesi di arrivo è Odoo Enterprise su Odoo.sh per ERP e database, così l'azienda non dipende più da un server locale.
• Migrazione come occasione. Oltre al trasferimento dei dati: dashboard su misura e revisione dei processi che oggi esistono solo perché il vecchio sistema li imponeva.

ProblemaUno studio di una decina di persone riceve richieste da telefono, social e WhatsApp senza un CRM né un sistema interno. Chi assegna un caso a quale avvocato lo decide a mano, ogni volta.

Cosa ho costruitoUn modulo di intake su Odoo. Ogni richiesta viene registrata, analizzata da un modello linguistico e assegnata all'avvocato giusto. Una dashboard mostra tutto, e gli avvocati possono correggere l'assegnazione dalla dashboard o direttamente da WhatsApp.

• Sopra Odoo, non accanto. Invece di un'app separata, Odoo con un'interfaccia alleggerita nei colori dello studio: CRM, firma degli incarichi e storico nello stesso posto.
• Gli strumenti esistenti restano. Lo studio usava già un proprio assistente AI personalizzato e non voleva perderlo: la dashboard lo interroga.
• Dati sensibili. L'infrastruttura gira su cloud dedicato, con la sicurezza come requisito di partenza.
• Demo funzionante prima del contratto. Prototipo su Odoo in container con dati inventati, usato nella trattativa con lo studio.

ProblemaUn nuovo brand di gioielli personalizzati parte da zero: negozio online, clienti, magazzino e fatture devono stare in un unico sistema dal primo giorno.

Cosa sto costruendoNel team mi occupo di Odoo e delle integrazioni: configurazione di CRM, magazzino e fatturazione, collegamento di WhatsApp al CRM e delle richieste di gioielli su misura.

• Architettura valutata prima di scegliere. Avevo progettato un middleware tra un e-commerce esterno e Odoo, con verifica della firma dei webhook, scritture senza doppioni tramite ID esterno e riallineamento notturno. Il team ha poi scelto l'e-commerce nativo di Odoo, che elimina un sistema da mantenere.
• Ipotesi scritte nella stima. Volumi, tipo di clienti e perimetro della fatturazione sono dichiarati nel preventivo, in giornate per blocco di lavoro, così ogni cambio di perimetro ha un costo visibile.

ProblemaUn maglificio lavora con una trentina di filati e deve sapere quanto filato ha, da quale lotto, e in quali capi è finito.

Cosa sto costruendoUn gestionale con carico dei filati dai documenti di trasporto e scarico per ordine, più una pagina ordini per capi fatti con fino a cinque filati. Ogni capo è tracciabile fino al filato e al suo storico.

• Il vincolo del lotto nel modello dati. Un ordine usa un solo lotto per colore, per evitare differenze di tinta: il sistema lo impone invece di affidarlo alla memoria di chi prepara l'ordine.
• MVP sullo stesso stack del prodotto finale, ripreso dal sistema di controllo costi per la ristorazione. Quello che il cliente prova è quello che riceverà.
• Manutenibile senza teleassistenza. È un requisito di progetto. In valutazione il passaggio a un database PostgreSQL ospitato, con preventivo separato per hosting e manutenzione.

ProblemaLe soluzioni anticontraffazione per il vino chiedono chip, RFID o etichette speciali: costi e modifiche di linea che molte cantine non sostengono.

Cosa sto costruendoUn sistema solo software che riconosce un'etichetta autentica dalla struttura microscopica delle fibre della carta, unica per ogni foglio e impossibile da riprodurre. Basta la fotocamera di uno smartphone.

Come lo sto validando

• Test con criteri di arresto. Il prototipo deve superare tre prove binarie prima di andare avanti. Il protocollo in corso usa 24 fogli in sei condizioni diverse, con cicli di umidità, per verificare che la firma della carta resti leggibile nel tempo.
• Il vantaggio sta nella carta. Il lavoro con i produttori di carte speciali punta a supporti progettati insieme, più difendibili di qualsiasi algoritmo.
• Mercato scelto sui dati. Il primo segmento è il vino di fascia alta e i consorzi, dove la contraffazione esiste davvero e c'è disponibilità a pagare per difendersi.
• Pensato per integrarsi. Affianca blockchain e passaporto digitale di prodotto: fornisce il legame fisico tra la bottiglia e il suo record digitale.

ProblemaLo stack tipico per trovare e contattare aziende costa 100–150 € al mese tra abbonamenti diversi.

Cosa ho costruitoUna pipeline che sostituisce tre abbonamenti con codice proprio, eseguita su job programmati. Costo di esercizio stimato: 3–5 € al mese. È pronta e in fase di avvio.

• Ricerca delle aziende. Le attività di un territorio e di un settore arrivano dalla API di Google Places, al posto dei database a pagamento.
• Messaggi personalizzati. Un modello linguistico leggero scrive l'apertura di ogni email a partire dai dati dell'azienda.
• Esecuzione senza server. I job girano su GitHub Actions a orari fissi: niente macchina da mantenere accesa.
• Reputazione protetta. Gli invii partono da un dominio dedicato, separato da quello principale, così un problema di consegna non tocca la posta di lavoro.