Approvazioni commerciali: dallo spreadsheet alla policy testata

In breve. C'è un momento in cui prezzi calcolati su spreadsheet e approvazioni date in chat non riescono più a stabilire quali termini sono stati calcolati, approvati o congelati: quello è il segnale per passare a decisioni commerciali versionate — quote prezzate sul server, policy di sconto in codice, un umano nominato che decide, una versione immutabile che resta. La tesi di questa pagina, ed è interpretazione mia: l'approvazione commerciale non è burocrazia da snellire, è la prova che un'offerta è esistita in quei termini. Con il flusso, due esempi e i limiti. Pubblicato il 6 ottobre 2026.

Il sintomo

Il modo di fallire è preciso, ed è scritto nella solution: prezzi su spreadsheet e messaggi di approvazione non riescono a stabilire quali termini sono stati calcolati, approvati o congelati. Non è un problema di velocità — è un problema di verità. A preventivo firmato, nessuno sa ricostruire quale listino ha prodotto quei numeri, chi ha detto sì a quello sconto, e se la versione approvata è quella che il cliente ha visto.

Per un leader delle commercial operations, il trigger è quando questa domanda non ha risposta. Non quando il team è lento: quando la memoria del processo vive in celle e chat, e ogni audit diventa archeologia.

Il flusso

Il flusso bersaglio è una catena corta: opportunità, preventivo prezzato sul server, policy di sconto versionata, decisione di un umano nominato, versione immutabile del preventivo. Il risultato è una decisione commerciale prezzata sul server e versionata, con un confine di approvazione umano: stato, policy, decisioni umane ed evidence diventano parte del sorgente dell'applicazione.

Ogni passo lascia traccia: la versione del preventivo congela tutto ciò che serve a riprodurre la decisione — offerta, componenti, fasce, quantità, listino, sconto, netto — anche dopo che il catalogo è cambiato. Il confronto con le alternative, e i tradeoff di ciascuna, è nella solution Commercial Operations: leggila prima di scegliere, perché ogni strada ha un prezzo scritto.

Due esempi di come si decide

Il primo esempio è il discount approval con soglie ed evidence: sconti in basis point interi, policy versionata con le soglie nel config dichiarato, tre verdetti possibili — approvazione automatica, approvazione richiesta, rifiuto — e un solo attore che può decidere, l'umano. Con il limite dichiarato: l'etichetta del ruolo approvatore è un'etichetta, non sicurezza reale.

Il secondo è il workflow CPQ di approvazione quote: catalogo, righe prezzate sul server, versione immutabile alla sottomissione, e oltre — firma con eventi verificati e un unico ordine immutabile. Con il limite dichiarato: provider di catalogo e firma di comodo, nessun connettore reale verso l'esterno.

Cosa resta vero anche qui

Tutto il cluster poggia sulla stessa disciplina del pillar sull'autonomia sotto controllo: agenti che propongono, policy deterministica che governa, umani nominati che decidono, audit su ogni verdetto. Qui il confine è più affilato che altrove: un agente che chiede di approvare un preventivo scontato viene rifiutato con un 403, e solo un attore umano può decidere. Non è una promessa nel README: è un test che asserisce il rifiuto.

E valgono gli stessi confini: la verità di implementazione sta nel registro dei claim generato dalla suite di test, non nella descrizione di prodotto (2413 test, 0 falliti, misurati il 29 settembre 2026). Lo stato di ogni job dell'area — cosa è validato end-to-end, cosa è parzialmente supportato, cosa è escluso — è nel job Commercial Operations / CPQ: 7 job, 3 validati end-to-end, 4 parzialmente supportati. Se trovi un claim che i test non supportano, è un bug: si toglie il claim o si aggiunge il test.

Fatti e limiti, separati

Fatti: flusso opportunità-preventivo-policy-umano-versione; preventivi prezzati sul server da catalogo; policy di sconto versionata con tre verdetti; rifiuto 403 all'agente che chiede di approvare; versioni immutabili che restano byte-identiche al cambio di catalogo; stato job con validazioni nominate.

Limiti: catalogo sincronizzato contro provider di comodo, nessun catalogo esterno reale; denaro in centesimi interi senza cambi; etichetta ruolo non è sicurezza; firma su provider di comodo senza connettori reali; nessuna pretesa di production-readiness. Un flusso e due esempi non misurano quanto il disegno regga in produzione: misurano che esiste, gira e dichiara i suoi confini.

Domande frequenti

Quando serve una policy di approvazione in codice?

Quando spreadsheet e chat non riescono più a stabilire quali termini sono stati calcolati, approvati o congelati: il problema non è la velocità, è che la memoria del processo non è ricostruibile.

Cosa rende una decisione commerciale riproducibile?

La versione immutabile del preventivo, che congela offerta, componenti, fasce, quantità e totali: dopo un cambio di catalogo, le vecchie versioni restano byte-identiche e i nuovi preventivi usano la revisione nuova.

Può un agente approvare uno sconto?

No: solo un attore umano può approvare o rifiutare, e il rifiuto all'agente è asserito dai test. Il confine vale contro un agente onesto, non contro un attaccante con accesso alla rete — in sviluppo locale l'attore è dichiarato, non autenticato.

Come verifico cosa è vero e cosa è roadmap?

Nel registro dei claim generato dalla suite di test e nello stato del job, che dice per ogni riga se è validata end-to-end o solo parzialmente supportata — e cosa è escluso.