Gestione delle commesse in un’azienda edile: relazione di un progetto Zoho

Questo articolo documenta un progetto di implementazione realizzato su un’azienda edile del Nord-Est. Non è una presentazione: è la descrizione di come il processo è stato analizzato e modellato, delle scelte fatte e dei motivi, incluse le alternative scartate, e di cosa dicono i dati a sei anni dall’avvio.

Per riservatezza il nome dell’azienda non compare; i dati dimensionali e di processo sono reali e pubblicati con il consenso del cliente.

Contesto e perimetro

L’azienda opera nelle costruzioni e ristrutturazioni per clienti privati, piccoli condomini e appalti pubblici di dimensione contenuta. Organico di circa trenta persone, di cui una decina nell’area commerciale, rimasto stabile per tutto il periodo osservato; fatturato compreso tra cinque e dieci milioni di euro. La vendita avviene sia su appuntamento sia attraverso più showroom fisici sul territorio, e in parte tramite rivenditori e partner.

Il progetto è stato commissionato dalla direzione dell’azienda. Gli interlocutori operativi sono stati tre manager: commerciale, amministrativo e tecnico.

La cronologia dell’implementazione: CRM e collegamento con l’amministrazione a fine 2019; modulo Commessa a metà 2020 e struttura delle fasi nell’autunno dello stesso anno; gestione delle campagne email dal 2024.

Nel 2020 è stata completata l’importazione dei dati storici ricavati dai sistemi precedenti, quindi i risultati sono stati confrontati tra il biennio 2020-2021 e il triennio 2022-2024.

La fase di analisi si è svolta in cinque o sei incontri distribuiti su circa due mesi. La dilatazione nel tempo non è dipesa dalla complessità del lavoro ma dal calendario degli interlocutori: soci operativi e responsabile amministrativo erano impegnati sull’attività corrente, e gli incontri sono stati collocati dove trovavano spazio. È una condizione normale in un’azienda di queste dimensioni e va prevista nella pianificazione, perché comprimere l’analisi per rispettare una data significa farla con le persone sbagliate o con quelle giuste ma distratte.

Requisiti espressi dal cliente

La richiesta iniziale riguardava la mancanza di visibilità sulle commesse: nessuno era in grado di dire a che punto fosse una trattativa o una lavorazione senza chiedere alla persona che la seguiva. L’analisi ha scomposto questa richiesta in tre requisiti distinti.

Il primo: tracciabilità completa del ciclo, dal contatto iniziale fino a consegna, installazione, fatturazione e incasso. Ogni passaggio lasciava traccia in strumenti diversi, non collegati.

Il secondo: standardizzazione del metodo di lavoro commerciale. Ciascun commerciale registrava le informazioni con criteri propri, con livelli di completezza diversi e con specializzazioni di prodotto non governate. La qualità del dato dipendeva dalla persona.

Il terzo: classificazione delle commesse per tipologia e margine. In assenza di dati aggregati, l’allocazione del tempo commerciale non seguiva le priorità aziendali: una commessa di basso valore poteva assorbire giornate intere mentre l’azienda intendeva spingere su lavorazioni a marginalità più alta.

Architettura della soluzione

Lo stack implementato comprende Zoho CRM come sistema centrale, un modulo personalizzato Commesse costruito al suo interno, Zoho Books per la parte amministrativa, Zoho Analytics per il reporting incrociato, Zoho Forms, Zoho Campaigns e Zoho Social per l’acquisizione e la gestione dei contatti.

La distribuzione delle responsabilità tra i sistemi è stata la seguente: il CRM governa lead, trattative e commesse; Books gestisce documenti fiscali, incassi e pagamenti; Analytics acquisisce dati dalle varie fonti e li incrocia per restituire una reportistica avanzata.

La situazione di partenza era frammentata: un insieme di strumenti diversi, in parte artigianali, ciascuno a copertura di un pezzo del processo, e nessun CRM. La richiesta del cliente era semplificare e accentrare, ed è il motivo per cui la scelta è caduta su una piattaforma unica, Zoho One, che ha assorbito progressivamente le funzioni prima distribuite tra quegli strumenti.

Acquisizione dei lead: mappatura dei punti di ingresso

Il primo intervento ha riguardato i canali da cui i contatti entrano in azienda: attività sui canali social, sito web con più landing page collegate a campagne ads, ingressi fisici negli showroom, segnalazioni di fornitori e professionisti, fiere ed eventi.

Ogni canale è stato collegato a un punto di raccolta strutturato. I moduli web passano da Zoho Forms; le campagne email da Zoho Campaigns; per gli showroom è stata definita una procedura di registrazione del contatto al momento della visita. In tutti i casi il record arriva nel CRM con l’origine valorizzata.

Modellazione della trattativa

Sulla trattativa l’intervento è stato volutamente minimo. La struttura standard del modulo Deal è stata mantenuta, con due estensioni: la modalità con cui il cliente ha fatto la richiesta e la tipologia di lavoro. In totale, una decina di classi che distinguono per esempio vendita con installazione, sola vendita, interventi sotto una soglia di importo, integrazioni su una trattativa principale.

La scelta risponde alla consapevolezza che ogni campo aggiuntivo richiede tempo di compilazione, e un modulo sovraccarico di dati viene compilato male, il che avrebbe riportato il problema di qualità del dato da cui il progetto era partito.

I due campi introdotti, inoltre, sono quelli necessari a soddisfare il terzo requisito, la classificazione delle commesse: letti in aggregato, dicono su quali tipologie di lavoro l’azienda sta impegnando il tempo commerciale.

Alla chiusura positiva, la trattativa genera una o più commesse in base a criteri definiti sui campi della trattativa stessa. I dati raccolti confermano la sistematicità: le trattative vinte con una commessa collegata sono l’82 per cento nel 2020, il 99 nel 2021 e il 100 da allora.

Il modulo Commesse

La commessa è stata modellata come modulo personalizzato interno al CRM. È il punto centrale del progetto e quello che ha richiesto la maggior parte del lavoro di analisi.

La funzione del modulo è di aggregazione: la commessa raccoglie tutte le attività che ruotano attorno a una lavorazione, indipendentemente dal reparto esecutore. Le fasi utilizzate per censire lo stato di lavorazione sono undici: inserita, da sviluppare, sviluppo e ordini, in attesa merce, in lavorazione, programmazione della posa, in posa, in verifica, fatturata, terminata, e la fase di uscita per le commesse perse.

Nella stessa scheda sono inseriti i punti di riferimento interni al team, cioè il responsabile commerciale, quello tecnico e quello amministrativo, e le dimensioni principali legate a scadenze e risorse: le date di rilievo, collaudo, fattura di saldo e ultimo incasso, le ore a budget e a consuntivo, e il collegamento al punto vendita o al canale di provenienza.

Dipendenze tra le fasi

La difficoltà principale non è stata la costruzione del modulo ma la definizione delle dipendenze tra le fasi, perché il processo reale non è una sequenza.

Alcune fasi sono strettamente sequenziali: la merce va ordinata, ricevuta a magazzino e solo dopo spedita in cantiere. Altre procedono in parallelo su reparti diversi: il rilievo misure e lo sviluppo tecnico possono avanzare mentre l’amministrazione emette la fattura di acconto.

Questo tipo di analisi precede la configurazione, secondo l’impostazione descritta nel metodo di lavoro che applichiamo a ogni progetto: la mappatura del processo viene prima del software.

Reporting

Zoho Analytics, raccogliendo dati da CRM, dalle attività di marketing e da Books, è stato in grado di portare i dati su un piano comune. Le dashboard costruite hanno coperto tre livelli: andamento della singola commessa, performance dei punti vendita e dei canali indiretti, situazione complessiva dell’azienda.

La differenza rispetto al metodo di reportistica precedente, con i dati estratti dai singoli prodotti, sta nell’incrocio tra fonti: il costo di acquisizione di un cliente proveniente da una campagna si legge accanto al margine della commessa generata e all’incasso effettivamente registrato in contabilità. Prima del progetto queste tre informazioni risiedevano in sistemi non comunicanti e il loro incrocio richiedeva una ricostruzione manuale che di fatto non veniva eseguita.

I numeri riportati in questo articolo sono stati raccolti in questo modo, da query dirette sulle tabelle nello stesso strato di dati su cui l’azienda lavora ogni giorno.

Risultati misurati

Le misure che seguono confrontano il biennio 2020-2021 con il triennio 2022-2024. Il periodo più recente, avendo ancora pratiche aperte, non può essere considerato perché i dati non sono ancora definitivi.

Il ciclo di vendita sulle trattative vinte, misurato dal CRM come giorni tra apertura e chiusura, è passato da una media di 76 giorni nel 2020 a 65 nel 2021, a 38 nel 2022, e si è stabilizzato tra 36 e 39 giorni nel 2023 e 2024. Il tempo si è dimezzato in quattro anni.

Il tempo di attraversamento della commessa, dai giorni tra inizio e fattura di saldo, è passato da una media di circa 180 giorni sulle commesse avviate tra 2019 e 2021 a circa 115 su quelle avviate tra 2022 e 2024.

L’aumento di efficienza del team commerciale ha permesso di aumentare il volume gestito, cresciuto nello stesso periodo: le commesse avviate all’anno sono passate da poco più di 220 nel 2019 a oltre 400 nel 2020 e 2021, a un massimo di circa 600 nel 2022, per stabilizzarsi tra 450 e 520 negli anni successivi, con un valore medio per commessa sostanzialmente costante. L’organico è rimasto stabile: la crescita di capacità è avvenuta a parità di persone.

La qualità del dato, misurata come copertura dei campi che alimentano le dashboard, è passata da parziale a completa: origine dei contatti sotto l’uno per cento di vuoti dal 2023, tipologia di lavoro compilata sul 100 per cento delle trattative vinte dal 2021, collegamento commessa presente sul 100 per cento delle trattative vinte dal 2022.

Considerazioni finali

Il valore del progetto non sta solo nella configurazione degli strumenti ma nella formalizzazione del processo. L’azienda possedeva già un metodo implicito; finché restava non scritto, ne circolavano tante versioni quante erano le persone che lo eseguivano. Il sistema lo ha reso esplicito e obbligatorio, e le dashboard lo hanno reso verificabile.

Redazione Gosnail. Revisione: Fabio Baraldo.

Domande frequenti

Perché un modulo personalizzato invece di uno strumento di project management separato?

Perché la separazione dei dati tra sistemi era il problema di partenza. Il modulo interno al CRM mantiene commessa, trattativa e cliente nella stessa base dati, e il reporting incrociato ne è la conseguenza diretta.

La modellazione delle fasi vale solo per l’edilizia?

No. Vale per ogni azienda in cui la vendita apre una lavorazione multi-reparto: impiantistica, arredo su misura, macchinari. Cambiano le fasi, non il problema delle dipendenze sequenziali e parallele.

Quanto tempo serve prima che i dati siano confrontabili?

In questo caso tre anni per l’origine dei contatti, uno per la tipologia di lavoro. La differenza sta nel metodo: la tipologia è stata resa obbligatoria con un elenco chiuso da subito, l’origine è passata da una fase di testo libero che ha prodotto dati non aggregabili. Il campo obbligatorio con valori chiusi è la scelta che fa risparmiare tempo.

Quanto pesa la fase di analisi su un progetto di questo tipo?

È la parte determinante. La configurazione del modulo è rapida una volta definite le fasi e le dipendenze; una definizione sbagliata produce un processo che gli utenti aggirano, e a quel punto il sistema misura una realtà che non esiste.