Cosa ho scoperto vivendo dentro le loro chat

Arcatech non vende davvero “ricambi”. Vende risposte. Veloci. La maggior parte delle richieste arriva come una foto sfocata in un messaggio WhatsApp, con l’energia emotiva di “aiuto” e la precisione tecnica di “questo coso”. Niente codice. Niente modello. A volte nemmeno una frase. Solo l’immagine di un pezzo di metallo unto, fotografato con luce pessima.

All’inizio l’ho trattata come un problema di dati. Costruire un catalogo. Normalizzare i nomi. Aggiungere campi. Ripulire tutto. È la mossa classica. Ed è fallita subito, perché il lavoro non stava succedendo in un database. Stava succedendo nei thread delle chat. La “fonte di verità” era chiunque si ricordasse una foto simile di tre mesi prima.

La conclusione utile era semplice: l’azienda non era rotta, lo era il flusso di lavoro. Gli umani stavano facendo il lavoro di un sistema. Tradurre, cercare, copiare, scrivere ai fornitori, aspettare, riscrivere, e poi ricostruire il contesto dalla cronologia dei messaggi. Il costo non era solo tempo. Era attenzione. E l’attenzione non scala.

Quando il business gira sulle chat, il tuo vero database è la memoria di tutti.

Quando ho smesso di provare a “sistemare i dati” e ho iniziato a “sistemare il flusso”, la soluzione è diventata ovvia: costruire un CRM che si comporti come un cervello operativo. In tempo reale. Multilingue. Consapevole dei fornitori. Assistito dall’AI. E soprattutto: progettato attorno al modo disordinato in cui le richieste arrivano davvero.

Il giorno in cui ho capito che i fogli di calcolo erano la trappola

La prima settimana sembrava produttiva. Era anche una bugia. Avevo campi puliti, una tabella ordinata, e quella sensazione appagante di controllo. Poi un cliente ha mandato la foto di un pezzo che tecnicamente era “già nel sistema”, solo che il nome non combaciava, il fornitore usava un’altra descrizione, e l’unico identificatore davvero utile era la forma nell’immagine.

Lì mi si è accesa la lampadina. In questo mondo i ricambi non hanno identità stabili. Non in modo affidabile. Hanno “ci assomiglia”. Hanno “sembra quello dell’altra volta”. Hanno cinque nomi diversi a seconda di quale fornitore chiedi. Qualsiasi sistema che presuppone nomi stabili diventa un sistema che costringe gli umani a fare lavoro extra. E Arcatech non aveva bisogno di lavoro extra.

Quindi ho smesso di progettare per la perfezione. Ho progettato per velocità e tracciabilità. L’obiettivo non era creare il miglior catalogo del mondo. Era aiutare una persona a rispondere a un cliente in pochi minuti con le migliori informazioni disponibili, lasciando una traccia che renda più facile la richiesta successiva.

Costruire un “cervello operativo” invece dell’ennesimo strumento

Ho costruito la base in Elixir con Phoenix LiveView. Non perché sia di moda. Perché il flusso richiedeva coordinamento in tempo reale senza trasformarsi in uno zoo di frontend. I messaggi arrivano. Le risposte dei fornitori arrivano in momenti imprevedibili. Ci sono più richieste aperte contemporaneamente. Le persone devono vedere cosa è cambiato adesso, non dopo un refresh, e non chiedendo in giro.

All’inizio ho provato a tenere tutto “manuale ma più veloce”. Un inbox più bello. Tag migliori. Un piccolo set di template. Sembrava più sicuro. Ma lasciava intatto il dolore. Rendeva il caos più ordinato, senza togliere il lavoro ripetitivo.

La svolta è stata trattare ogni richiesta come un processo guidato. Una coda con stato. Un thread con memoria. Qualcosa che possa dire: “L’abbiamo già visto”, oppure “Non l’abbiamo visto, ma ecco tre articoli simili”, e poi far avanzare la richiesta senza costringere una persona a copiare testo tra applicazioni.

Il comportamento centrale è diventato lineare: accettare un messaggio o una foto del cliente, agganciarla a una richiesta, tracciare ciò che è noto, chiedere ai fornitori giusti, raccogliere le risposte, e produrre un preventivo pulito nella lingua del cliente. Non è spettacolare. È solo quello che l’azienda doveva fare, ogni giorno, in modo affidabile.

La parte AI ha funzionato solo quando ho smesso di aspettarmi magia

Non volevo un “CRM con chatbot”. È così che finisci con un sistema sicuro di sé che dice la cosa sbagliata in fretta. Arcatech aveva bisogno di qualcosa di più rigido: un agente che si comporti come un operatore prudente. Può far avanzare il lavoro, ma deve mostrare cosa sta facendo e chiedere approvazione nell’unico punto che conta davvero: il prezzo.

La modalità di fallimento iniziale era prevedibile. Se lasci un agente improvvisare, improvviserà. Indovinerà nomi di pezzi. Inventerà struttura dove non c’è. Suonerà convincente mentre sbaglia. In questo dominio, sbagliare costa. Quindi ho ristretto il suo lavoro. Non decide tutto. Fa le parti noiose che gli umani odiano ripetere.

In pratica questo ha voluto dire usare l’AI in punti piccoli e controllati: classificare e abbinare immagini quando mancano i nomi, preparare richieste ai fornitori, estrarre prezzo e disponibilità da risposte sporche, e tradurre i messaggi in modo pulito. Per la traduzione ho usato Gemini perché è veloce ed economico. Per ragionamento e orchestrazione ho usato GPT-5 (preview) perché gestisce bene flussi multi-step. Ogni modello fa un lavoro. Nessun eroismo.

La vera vittoria di design è stato il momento della “una sola domanda”. Dopo che i dati del fornitore vengono estratti e salvati, Arcatech riceve un prompt pulito: prezzo fornitore, disponibilità, tempi di consegna e contesto. Poi una decisione: “Qual è il prezzo finale?” Lì gli umani restano in controllo, ed è il punto che protegge il business.

WhatsApp è stato il pezzo più duro perché rifiuta di essere un sistema

Tutto ciò che conta succedeva su WhatsApp. I clienti vivono lì. I fornitori vivono lì. E WhatsApp non vuole essere automatizzato nel modo in cui Arcatech ne aveva bisogno. Non esiste un’API ufficiale gratuita che si adatti a questo flusso. O paghi la Business API e accetti i vincoli, oppure ti appoggi a WhatsApp Web con tutta la fragilità che si porta dietro.

All’inizio sono finito nel percorso “integriamo tutto direttamente”. Era tentante. Tutto in un’unica app. Un deploy. Un solo modello mentale. Poi arriva la realtà: le sessioni WhatsApp cadono, i login via QR scadono, e qualsiasi cosa tocchi un client web è il tipo di cosa che si rompe alle 2 di notte. Se lo mescoli nel cuore del CRM, trasformi un guasto in un guasto di sistema.

Quindi ho fatto marcia indietro e ho scelto la soluzione noiosa: isolare WhatsApp in un microservizio Go usando Whatsmeow. Go non è Elixir. Va bene così. Il confine contava più del linguaggio. Il servizio mantiene la sessione WhatsApp, invia e riceve messaggi, e parla con il CRM via WebSocket. Senza stato. Sostituibile. Facile da riavviare senza trascinarsi dietro il resto del sistema.

Ho anche considerato di far comportare il servizio Go come un nodo Erlang. È il tipo di idea che suona elegante in un diagramma. In produzione ti compra solo mal di testa di cluster e dolore di debugging. I WebSocket mi hanno dato confini chiari, monitoraggio più semplice, deploy più sicuri, e meno modi di fallire in maniera sorprendente. A volte la scelta più intelligente è rifiutarsi di essere “furbi”.

Cosa è cambiato per Arcatech dopo il rilascio

Tutto gira su Fly.io: due istanze Elixir per ridondanza, una istanza Go per WhatsApp, MongoDB Atlas come database, e API LLM esterne per i task AI. Il sistema gestisce bene la concorrenza e fallisce in modo contenuto. Se WhatsApp ha una giornata storta, il CRM continua a funzionare e le richieste non spariscono nella cronologia delle chat.

Il cambiamento più grande è stato culturale. Arcatech ha smesso di vivere dentro thread sparsi. Le richieste sono diventate oggetti tracciabili con stato. Le risposte sono state catturate, strutturate e collegate. Le decisioni di pricing sono diventate esplicite invece che implicite. E la comunicazione multilingue ha smesso di essere un collo di bottiglia perché la traduzione è diventata parte del flusso, non un passaggio extra da ricordare.

È stato costruito in circa quattro settimane, non perché fosse semplice, ma perché il bersaglio era chiaro: rispettare il flusso che l’azienda aveva già e togliere le parti che bruciavano attenzione umana. Il sistema non ha chiesto ad Arcatech di cambiare identità. Ha smesso di chiedere a Arcatech di essere un database.

Se stai costruendo qualcosa di simile, ecco il test che conta: quando un cliente manda una foto senza contesto, il tuo sistema riesce ad andare avanti senza panico, senza supposizioni, e senza richiedere un eroe che si ricordi cosa è successo l’ultima volta? È a questo che serve un cervello operativo.

I prossimi passi sono pratici: rendere ancora più stretto il punto di approvazione della “una sola domanda”, aggiungere più pattern di estrazione specifici per fornitore man mano che compaiono nuovi formati di risposta, e misurare il tempo al preventivo come una metrica fondamentale. Perché in questo business, la velocità non è una feature. È il prodotto.