CRM per studio professionale

Uno studio che vende servizi professionali vive su un ciclo lungo: arriva una richiesta, si valuta se è qualificata, si manda una proposta, si apre la pratica, si fattura, si incassa, e se il cliente è arrivato tramite un segnalatore bisogna calcolargli la provvigione.

Quasi sempre questo ciclo è spezzato su tre o quattro strumenti che non si parlano: un CRM per i contatti, un software di fatturazione, e un foglio di calcolo per le provvigioni. Il risultato è che nessuno sa mai con certezza quanto vale davvero una pratica, e le riconciliazioni si fanno a mano ogni fine mese.

Un gestionale che tocca fatture, incassi e provvigioni non può permettersi dati incoerenti: un importo negativo entrato per errore o un incasso appeso a una fattura che non esiste diventano un problema contabile, non un fastidio dell’interfaccia.

Per questo le regole vivono nel database, non nella validazione della schermata: sono vincoli che il sistema rifiuta di violare, indipendentemente da quale parte dell’applicazione stia scrivendo il dato.

Il sistema segue il ciclo reale invece di dividerlo per strumento. La richiesta entra da un percorso di prequalifica con i documenti allegati, diventa opportunità, poi proposta generata da un modello a sezioni riutilizzabile, poi pratica con le sue righe di listino. Da lì nascono fattura, incassi, eventuali note di credito e la provvigione al segnalatore, calcolata sul valore effettivo e non stimata a parte.

I segnalatori sono entità di prima classe del modello dati, con la loro anagrafica e le loro provvigioni collegate alle pratiche che hanno originato. È la differenza tra sapere quanto rende una fonte di lavoro e crederlo.

Sopra ci sono le funzioni che rendono il sistema usabile ogni giorno: scadenze delle fatture con avvisi, notifiche, archivio documenti per pratica, costi, e le impostazioni della società emittente in un unico posto.

Il software è stato costruito da agenti AI dentro lo stesso recinto che usiamo per tutti i gestionali con dati che contano, lo stesso descritto nel case study di Digitool: il modello non modifica il database, propone. Ogni cambiamento allo schema resta sospeso finché una persona non lo approva, e solo allora diventa una migrazione applicata in transazione.

Su un sistema contabile questo non è un vezzo metodologico. Le migrazioni raccontano la storia delle decisioni prese, e i vincoli che proteggono i dati sono entrati uno alla volta, ognuno approvato consapevolmente.

Front-end Vue con stato in Pinia, middleware Fastify, PostgreSQL come unica fonte di verità, container isolato e design system a token. La forma dei dati nasce sempre dal database: al frontend è vietato ridefinirla per far compilare il codice.

Lo studio ha un unico posto in cui chiedere quanto vale una pratica, a che punto è, se è stata incassata e quanto spetta a chi l’ha segnalata. Le riconciliazioni di fine mese fra strumenti diversi non esistono più, perché non esistono più strumenti diversi.

Un CRM generalista gestisce contatti e trattative, ma la parte che fa male in uno studio professionale è quella dopo: proposta, pratica, fattura, incasso, provvigione. Se il tuo ciclo di lavoro ha passaggi che nessun software pronto conosce, costruirlo su misura smette di essere un lusso e diventa il modo per smettere di tenere la contabilità in testa.