Un tag non applicato ha spostato $119 dalla tasca di un closer a quella di nessuno. Il sistema ha eseguito correttamente, applicando il piano sbagliato. Nessun errore, nessun alert, nessuno che se ne accorge — finché qualcuno non va a controllare a mano. Questa è la forma più silenziosa di errore nell’automazione commissioni: nessuno grida, i numeri escono, e sono sbagliati.
Il caso è questo: un’academy con un volume di vendite mensile rilevante usa un sistema di calcolo delle commissioni agganciato al CRM. I venditori chiudono deal in due modalità — rateale o pagato in un’unica soluzione (pay-in-full). La commissione cambia a seconda del tipo: più alta sul pay-in-full, perché genera liquidità immediata. Per distinguere i due casi, il processo prevedeva che il closer applicasse manualmente un tag — chiamiamolo PIF — al contatto nel CRM nel momento in cui il deal veniva chiuso in full. Un clic. Nella SOP c’era scritto. Tutti sapevano che serviva.
Su un deal da $7.000 chiuso in full, la commissione corretta era $714. Senza tag, la formula ha letto il deal come rateale e ha prodotto $595. Delta: $119 spariti nel nulla. Scoperto solo in verifica manuale, settimane dopo. L’articolo spiega perché succede, come identificare i gesti a rischio nel tuo processo, e come eliminare il problema alla radice.
Perché l’automazione commissioni si rompe in silenzio
Il sistema non ha sbagliato niente. Ha letto l’assenza del tag, ha applicato il piano rateale, ha prodotto un numero. Tutto corretto, tutto tracciato, tutto sbagliato. Questo è il punto centrale di qualsiasi errore nell’automazione commissioni: la macchina esegue con la stessa sicurezza quando il dato è giusto e quando è mancante.
Il CRM non sa che il tag mancava. Non sa che avrebbe dovuto esserci. Sa solo che non c’è, e si comporta di conseguenza. Nessun log di errore, nessun webhook fallito, nessuna notifica. Il silenzio non è salute — è il sintomo. E nei sistemi di commissioni, dove i numeri escono una volta al mese e vengono controllati poco, quel silenzio dura.
Il problema non è la disciplina del closer. Il closer ha chiuso il deal, ha spostato il lead nello stage corretto, ha fatto il suo lavoro al 100%. Il tag non serviva a lui — serviva al sistema di calcolo, cioè a qualcun altro, a valle. La memoria non alloca spazio a roba che non ti serve. Non è negligenza: è come funziona l’attenzione umana.
Il discriminante che nessuno usa quando progetta i processi
C’è una domanda che bisogna fare su ogni gesto manuale in un processo: questo gesto serve a chi lo fa, o serve solo al sistema?
Se serve a chi lo fa, tiene. L’agente che sposta un lead nello stage Confirmed lo fa perché è così che gestisce la sua pipeline — se non lo sposta, non sa più a che punto è. Qualsiasi automazione agganciata a quel trigger prende il dato gratis, senza chiedere niente di extra. Il gesto esiste già, il sistema ci si appoggia sopra.
Se serve solo al sistema — se è un clic che non cambia niente per chi lo fa, ma cambia tutto per chi elabora a valle — quel gesto è un debito. Prima o poi non viene fatto. E quando non viene fatto, nessuno se ne accorge subito.
| Gesto | Serve a chi lo fa? | Risultato |
|---|---|---|
Spostare il lead in Confirmed |
Sì — gestisce la sua pipeline | Tiene: l’automazione ci si aggancia sopra |
Applicare il tag PIF manualmente |
No — serve al calcolo commissioni | Cade: $595 invece di $714 |
| Aggiornare le metriche del delivery report | No — serve al reporting | Cade: 100% success rate e $0 cash collected |
Spostare un lead in Nurturing |
Sì — indica che non chiude adesso | Tiene: il nurturing parte da lì automaticamente |
La tabella non è una lista di comportamenti virtuosi e pigri. È una mappa di affidabilità strutturale. I gesti nella colonna verde tengono perché sono intrinsecamente motivati. Quelli nella colonna rossa cadono perché chiedono uno sforzo cognitivo extra per qualcosa che non restituisce niente a chi lo fa.
La regola
Il gesto che serve solo al sistema è un debito, non un processo
Ogni gesto manuale che non cambia niente per chi lo fa, ma cambia tutto per chi elabora a valle, è un punto di rottura garantito. Non domani, non forse: garantito.
- Chiedi chi ne beneficia — se la risposta è solo il sistema, il gesto va eliminato o automatizzato
- Nessuna SOP lo salva — puoi scriverlo in grassetto rosso nella procedura, non cambia niente
- Il silenzio è il sintomo — quando il dato manca, la macchina non protesta, esegue sbagliato
Come eliminare il gesto invece di ricordarlo
Il fix scelto nel caso reale non è stato un reminder, non è stata una SOP aggiornata, non è stato un controllo in più. È stata una regola di auto-tag: il prodotto sa già se è pay-in-full o rateale — quella distinzione è codificata nel prodotto stesso, non nella testa del closer. L’automazione legge il tipo di prodotto acquistato e applica il tag PIF da sola, al momento del pagamento.
Il closer non deve fare niente di diverso da quello che faceva prima. Il sistema ottiene il dato di cui ha bisogno senza chiederlo a nessuno. Zero gesti extra, zero dipendenza dalla memoria.
Esistono tre modi per affrontare questo problema, in ordine di preferenza:
- Deriva il dato da un gesto che già esiste. Se il closer sposta il deal in uno stage specifico per i pagamenti full, aggancia lì il tag. Non stai aggiungendo un gesto — stai sfruttando uno che già avviene.
- Deducilo dai dati che hai già. Il prodotto venduto, il valore del pagamento, la struttura dell’ordine: spesso il sistema sa già se è PIF o rateale senza che nessuno lo dica esplicitamente. Leggi quel dato e basta.
- Se deve farlo una persona, rendilo l’unica strada. Non un campo opzionale accanto al percorso principale — la strada. Senza quel tag, il deal non si chiude. Non un promemoria: un blocco.
Quello che non funziona — e su questo non ho dubbi — è scriverlo nella SOP e sperare. L’ho verificato abbastanza volte da smettere di provarci.
Come costruire una guardia sul calcolo commissioni
Anche dopo aver automatizzato il tagging, un sistema di commissioni senza guardie non è finito. La guardia non è il backup del backup: è la verifica strutturale che il sistema stia operando sui dati giusti prima di produrre un numero.
Nel caso del tag PIF, la guardia più semplice è un controllo pre-calcolo: prima di elaborare ogni deal, il flow verifica che tutti i campi necessari siano presenti e coerenti. Se il tipo di prodotto è pay-in-full ma il tag non è presente — per qualunque motivo — il deal non entra nel calcolo e genera un alert. Non un errore nel log che nessuno legge: un alert attivo, su un canale che qualcuno controlla ogni giorno.
La struttura è questa:
- Il trigger parte dai pagamenti confermati nel CRM o nella piattaforma di pagamento.
- Un gate controlla la presenza e la coerenza di tutti i campi che determinano il piano commissioni.
- Se i campi sono completi e coerenti, il calcolo parte.
- Se manca qualcosa, il deal finisce in una coda di revisione e viene notificato in tempo reale.
La coda di revisione è la parte che quasi nessuno costruisce. Senza di essa, il deal mancante sparisce — e la scoperta avviene in verifica manuale, settimane dopo. Per capire come strutturare questi flow in modo solido, la mappa sull’automazione dei processi aziendali copre la logica di progettazione prima ancora di parlare di tool.
Strumenti e dove costruire la macchina
Il tag automatico può partire da GoHighLevel se il CRM è lì: una workflow automation agganciata all’evento di pagamento, che legge il tipo di prodotto e applica il tag al contatto senza intervento umano. GoHighLevel supporta trigger su prodotti specifici e azioni di tagging native — il setup non richiede codice.
Se il pagamento passa da una piattaforma esterna e arriva via webhook, Make è il punto in cui costruire la logica: riceve il payload, legge il campo che identifica il tipo di piano, applica il tag via API sul CRM, e — se il campo manca o è ambiguo — manda la notifica invece di procedere. La guida completa a Make copre la struttura dei router e dei filtri che servono esattamente per questo tipo di gate.
Per chi gestisce volumi più alti o vuole maggiore controllo sul flusso, n8n permette di costruire la stessa logica con più granularità — inclusa la gestione della coda di revisione su un foglio o un database interno. La guida completa a n8n è il punto di partenza se non hai ancora una macchina di automazione strutturata.
Il tool è secondario. La logica — gate, calcolo, coda di revisione, alert — è la stessa indipendentemente da dove la costruisci. E se vuoi capire come progettare l’intera infrastruttura di un’agenzia o di un infobusiness attorno a questa logica, la guida su come automatizzare un’agenzia affronta il problema dall’alto.
Il vero costo dell’errore nelle commissioni
$119 su un singolo deal sembrano pochi. Ma il punto non è quel deal. Il punto è quanti deal simili sono usciti nello stesso modo prima che qualcuno controllasse. E quanti usciranno ancora se il processo rimane com’è.
Un’automazione commissioni errori di questo tipo non si manifesta come un picco anomalo — non c’è niente che suoni strano. I totali mensili sembrano ragionevoli, le commissioni escono, i closer vengono pagati. Il problema è invisibile finché non si fa una verifica deal per deal, confrontando il tipo di prodotto venduto con il piano commissioni applicato.
Il secondo costo — quello che nessuno calcola — è la fiducia. Quando un closer scopre che gli è stata pagata la commissione sbagliata, la domanda che si fa non è «è stato un errore del sistema». È «quante volte è successo». E a quella domanda non c’è risposta rassicurante se il processo non ha guardie.
La macchina che produce numeri senza verificare i propri presupposti non è un’automazione — è un generatore di numeri plausibili. La differenza tra i due emerge solo quando qualcuno va a controllare.
Domande frequenti
Come posso verificare se il mio sistema di calcolo commissioni ha errori silenziosi?
Prendi un campione di deal degli ultimi 30 giorni e confronta il tipo di prodotto venduto con il piano commissioni applicato. Se i due non combaciano su almeno un deal, hai una discrepanza strutturale. L’assenza di errori nel log non significa che i dati siano corretti.
Qual è la differenza tra un errore di automazione e un dato mancante?
Un errore di automazione genera un log, un alert, una risposta 4xx o 5xx. Un dato mancante no: il sistema riceve meno di quello che dovrebbe, completa l’esecuzione con quello che ha, e produce un output sbagliato senza saperlo. Il secondo è molto più difficile da intercettare.
Come si costruisce un gate di verifica prima del calcolo commissioni?
Prima del nodo di calcolo, aggiungi un controllo condizionale che verifica la presenza e la coerenza di tutti i campi necessari. Se qualcosa manca, il deal non procede: finisce in una coda di revisione e genera una notifica su un canale attivo. Senza la coda, il deal sparisce.
È sufficiente aggiornare la SOP per evitare che il tag venga dimenticato?
No. Una SOP descrive cosa dovrebbe succedere, non garantisce che succeda. Il gesto che serve solo al sistema — non a chi lo esegue — viene dimenticato indipendentemente da quanto è chiara la procedura. L’unica soluzione affidabile è eliminare il gesto o renderlo automatico.
