Pipeline che si muove da sola: stadi, scoring e follow-up in Accordo

In breve. In Accordo un'opportunità avanza perché un workflow nominato esegue la mossa sul server, con la policy che l'ha governata attaccata al verdetto: sette stadi scritti nel codice, una soglia che parcheggia i rinnovi grossi in attesa di un umano, scoring con input tracciati e code di lavoro che non spariscono in silenzio. La tesi che ne ricavo, ed è interpretazione mia: una pipeline non memorizza lo stadio, registra come ci è arrivata. Pubblicato il 6 ottobre 2026.

Sette stadi, scritti nel codice

Gli stadi delle opportunità stanno in un enum nel nucleo: discovery, qualification, proposal, approval_pending, negotiation, won, lost. Sette valori, niente di più: uno stadio che non è in lista non si può impostare, e un cambio di stadio non è una scrittura su tabella ma un workflow nominato, request-opportunity-stage-change, in tre passi: carica l'opportunità, valuta la policy commerciale, applica l'esito.

Nessuno — né il client, né l'agente — scrive mai direttamente sulle tabelle: chiama metodi di servizio e workflow nominati, che conservano validazione, identità dell'attore, policy, traccia e audit. Il client chiede, il server decide. È lo stesso disegno del customer hub: i record agiscono solo dentro azioni governate.

La soglia che parcheggia da sola

Il secondo passo del workflow è quello che muove la pipeline senza intervento umano. La regola di default: un rinnovo che punta allo stadio proposal, con valore pari o sopra la soglia — 5 milioni di centesimi, cioè 50.000 euro — non avanza. Si parcheggia in approval_pending e apre una richiesta di approvazione, con il motivo della policy registrato. Sotto soglia, o per tipi diversi dal rinnovo, lo stadio cambia e basta.

Il percorso di uscita è un secondo workflow, decide-opportunity-approval: carica la richiesta, pretende un attore umano esplicito — senza, errore di validazione — e applica l'esito dentro una transazione con attore e run tracciati. Approvata, l'opportunità va in proposal; rifiutata, torna in qualification. Se nel frattempo non è più in attesa, il sistema risponde conflitto invece di decidere su uno stato vecchio. Il racconto completo delle approvazioni è nell'articolo dedicato, con la demo riproducibile e il rinnovo deciso dal vivo.

Scoring che si può rileggere

Prima ancora degli stadi c'è il lead, e il lead ha un punteggio. La lead intelligence di Accordo registra segnali comportamentali immutabili, uno per uno, con chiavi deterministiche: un segnale duplicato è un 409 stabile, non un secondo contributo al punteggio. Gli input che il modello di scoring può leggere sono una proiezione dichiarata dei campi del lead, e ogni run di scoring ne registra l'impronta: settimane dopo, il punteggio storico si rilegge con gli input che aveva allora, anche se il lead nel frattempo è cambiato.

Per i concetti — punteggio per interesse e potenziale, instradamento alla figura sales giusta — il riferimento resta la guida esistente su scoring e routing. Qui aggiungo il pezzo di meccanica: lo scoring deterministico e spiegabile non è una qualità del modello, è una proprietà della registrazione. Resta un'area parziale, marcata come tale nei documenti: la copro nei limiti.

Follow-up: code che non spariscono

L'ultimo pezzo della pipeline che si muove da sola è quello che non si muove finché una persona non decide. Quando una richiesta operativa finisce i tentativi, resta visibile in attesa e solo un operatore può abbandonarla, con un comando dedicato: i token di deploy vengono rifiutati con 403. Niente sparisce in silenzio, niente si chiude da solo. È la stessa disciplina delle approvazioni: chiudere una richiesta esausta è una decisione, non un errore da riprovare.

Questo è il follow-up nel mio disegno: non un promemoria che suona, ma una coda di lavoro con stati scritti, attori nominati e traccia per ogni transizione. La tesi completa sull'autonomia che ne deriva è nel pillar sull'autonomia sotto controllo.

Fatti e limiti, separati

Fatti: sette stadi in enum nel nucleo; workflow di cambio stadio in tre passi con policy a soglia (default 50.000 euro sui rinnovi verso proposal); parcheggio in approval_pending con richiesta registrata; decisione solo da attore umano esplicito, in transazione con trace; segnali di scoring immutabili con dedupe deterministica; impronta degli input per ogni run; richieste esauste chiudibili solo da operatore, token di deploy rifiutati.

Limiti: la policy copre i rinnovi con una soglia di valore, non pipeline arbitrarie — il new business non passa dalla policy dei rinnovi; lo scoring ha aree marcate parziali nei documenti; predizione e data science sono fuori dallo scope del pilot; la marketing automation non esegue niente. Sette stadi e due workflow non misurano quanto il disegno regga in produzione: misurano che la meccanica esiste e gira.

Domande frequenti

Chi decide un cambio di stadio?

Il server, attraverso un workflow nominato: il client chiede lo stadio di destinazione, il workflow valuta la policy e applica l'esito. Nessuno scrive direttamente sulle tabelle, né il client né l'agente.

Cosa succede sopra la soglia di approvazione?

Il rinnovo non avanza: si parcheggia in approval_pending e apre una richiesta di approvazione con il motivo registrato. Solo un umano nominato può decidere, e la decisione resta tracciata con la versione di policy che la governava.

Perché lo scoring registra gli input di ogni run?

Perché un punteggio senza input è un numero non verificabile. Con l'impronta registrata, il punteggio storico si rilegge settimane dopo con i dati che aveva allora, anche se il lead è cambiato nel frattempo.

Cosa resta in attesa senza chiudersi da solo?

Le approvazioni sopra soglia e le richieste a tentativi esauriti: restano visibili in coda finché una persona non decide. Niente sparisce in silenzio, niente si chiude da solo.