Il risultato non è un prezzo

Il cliente pronuncia una frase alla quale sembra impossibile opporsi: non voglio pagare le ore, voglio pagare il risultato. In pochi secondi il fornitore si trova dalla parte sbagliata della conversazione. Se difende le giornate sembra voler essere remunerato per l’inefficienza. Se chiede una quota fissa sembra non credere nel proprio lavoro. Se tenta di distinguere ciò che controlla da ciò che dipende dal cliente, appare già intento a costruirsi un alibi.

La frase funziona perché contiene una verità. Per troppo tempo abbiamo venduto attività come se il loro completamento coincidesse con il valore. Un software consegnato può non essere adottato, un’integrazione può non cambiare il processo, una consulenza può non produrre alcuna decisione. Il cliente ha ragione a non volere un inventario di ore. Ha ragione a chiedere che il fornitore condivida almeno una parte del rischio.

Lo so bene perché quella tesi l’ho sostenuta anch’io. A marzo ho scritto che il time & materials sta morendo e che il pricing a risultato è il modello più adulto che abbiamo. Lo penso ancora. Ma nei mesi successivi ho passato abbastanza trattative, da entrambi i lati del tavolo, per accorgermi che tra il desiderare quel modello e il saperlo scrivere dentro un contratto c’è una distanza che quasi nessuno sta misurando. Questo saggio è il secondo tempo di quel ragionamento, ed è meno comodo del primo.

Il problema inizia appunto quando si prova a mettere la frase per iscritto. Quale risultato? Misurato da chi? Rispetto a quale punto di partenza? In quale intervallo? Che cosa sarebbe accaduto senza l’intervento? Quali decisioni resteranno al cliente? Quali obblighi avrà nell’adozione? Che cosa succederà se cambierà prezzi, personale, processi o strategia mentre il fornitore aspetta di sapere se verrà pagato?

A quel punto diventa evidente che non si stava discutendo soltanto di prezzo. Si stava decidendo chi avrebbe avuto il diritto di raccontare la causa di ciò che sarebbe accaduto.

Quale risultato, esattamente

La parola outcome viene ormai applicata a quasi qualunque unità di fatturazione diversa dalle ore, e questa è la prima confusione da smontare. La valutazione delle politiche pubbliche usa da decenni una distinzione che il B2B farebbe bene a rubare: la catena dei risultati dell’OCSE separa gli input (le risorse impiegate), le attività (ciò che viene fatto), gli output (il prodotto direttamente consegnato), gli outcome (l’effetto prodotto o reso possibile) e gli impatti (la trasformazione di lungo periodo). Non è una tassonomia pedante: è una catena causale, e proprio per questo obbliga a esplicitare ipotesi, rischi e collegamenti tra ciò che il fornitore fa e ciò che infine accade.

Tradotta nel software e nei servizi, la scala è questa. La giornata e l’ora sono input. La funzionalità consegnata, l’integrazione, il report sono output. L’utente attivo, il token, la transazione sono consumo misurato. Il ticket risolto, la pratica completata, l’anomalia identificata sono outcome operativi. L’aumento dei ricavi, la riduzione del churn, il margine sono outcome economici. La salute, l’occupazione, la sicurezza sono impatti. Più ci si sposta lungo la catena, più l’unità fatturata somiglia al valore reale del cliente. Ma crescono anche il tempo necessario per osservarla, il numero delle variabili esterne, il costo della verifica e la difficoltà di attribuzione.

La regola si può condensare così: la desiderabilità di un outcome cresce con la sua distanza dal lavoro del fornitore. La sua contrattualizzabilità diminuisce con la distanza dalle variabili che il fornitore controlla.

C’è poi una seconda confusione, più insidiosa perché conviene a tutti. Nel value-based pricing il prezzo viene determinato in relazione al valore economico atteso: un intervento che potenzialmente vale un milione può essere venduto a centomila euro, ma il pagamento non dipende dal fatto che il milione si materializzi. Nell’outcome-based pricing il pagamento è subordinato al verificarsi del risultato. Non cambia il metodo con cui si calcola il prezzo: cambia chi sopporta il rischio. Molte offerte che si presentano come outcome-based sono in realtà value-based pricing, prezzi per output, usage-based pricing, bonus commerciali, SLA con penali, success fee su eventi facili da contare. Non è pignoleria lessicale. Chiamare outcome un output consente di promettere allineamento senza assumere davvero l’incertezza dell’impatto economico.

Il controfattuale

Il cuore del problema è che il risultato osservato non coincide con il risultato prodotto dal fornitore. Se le vendite aumentano dopo l’installazione di un CRM, l’aumento può dipendere dal CRM, dalla nuova campagna, da uno sconto, dall’ingresso di un commerciale bravo, dall’uscita di un concorrente o dalla stagionalità. Per attribuire il valore bisogna rispondere a una domanda che nessuna dashboard mostra: che cosa sarebbe accaduto nello stesso periodo, alle stesse condizioni, senza l’intervento?

Nella maggior parte dei rapporti commerciali non esiste un gruppo di controllo. Il controfattuale deve essere stimato, normalizzato o negoziato, e nel momento in cui diventa negoziato smette di essere un fatto tecnico. Un outcome senza controfattuale è un’opinione con una clausola economica.

E prima ancora del controfattuale serve la baseline. Per pagare un risultato bisogna conoscere il valore di partenza, la sua variabilità storica, la qualità del dato, le segmentazioni rilevanti, gli interventi concorrenti, la stagionalità, le modifiche avvenute durante il periodo e la fonte autorizzata a produrre il numero finale. Due dashboard possono mostrare valori diversi senza che nessuna delle due sia tecnicamente falsa: basta una finestra temporale, una deduplicazione o una definizione differente. Prima di discutere il prezzo bisogna stabilire quale realtà amministrativa avrà valore contrattuale. Un outcome senza baseline non è un risultato. È una narrazione retrospettiva.

Poi c’è il controllo, ed è qui che il discorso smette di essere statistico e diventa politico. Il principio è noto a chiunque scriva contratti pubblici seri: il rischio va attribuito alla parte più capace di gestirlo. La guidance del Cabinet Office britannico, aggiornata a giugno 2026, lo dice senza giri di parole: un fornitore caricato di un rischio che non governa produce quasi certamente un premio di rischio nel prezzo, sotto-performance man mano che il focus si sposta sul taglio dei costi, o un contratto così oneroso da collassare. E quando raccomanda i meccanismi di pagamento a risultato, la stessa guidance aggiunge una condizione che nelle trattative italiane sento nominare pochissimo: il fornitore deve avere un margine ampio per scegliere come raggiungere il risultato. Se il compenso dipende dall’aumento delle conversioni, chi controlla i prezzi, le campagne, l’assortimento, la qualità dei lead, i tempi di risposta, la forza vendita? Un fornitore può essere remunerato sul risultato soltanto nella misura in cui dispone delle leve per produrlo.

Infine, la cooperazione. Gran parte degli outcome è coprodotta: un sistema riduce i tempi amministrativi solo se il cliente ridisegna le procedure e impone l’adozione, una piattaforma genera opportunità solo se qualcuno le segue, un sistema predittivo riduce i guasti solo se la manutenzione interviene. Il cliente non è il beneficiario passivo del risultato: è uno dei suoi produttori. Un vero contratto outcome-based contiene quindi obblighi del cliente, con la stessa dignità economica del prezzo: accesso ai dati, tempi di risposta, personale dedicato, livelli di adozione, stabilità delle condizioni operative. Senza questi obblighi, il contratto contiene una responsabilità unilaterale per un risultato bilaterale.

Il mercato che vuole comprare ciò che non misura

Fin qui il meccanismo. La domanda successiva è se il mercato italiano possieda l’infrastruttura per farlo funzionare, e i dati disponibili suggeriscono una risposta scomoda ma precisa.

Nel 2025, secondo l’ISTAT, il 56% delle imprese italiane con almeno dieci addetti utilizzava almeno un software aziendale e il 68,1% acquistava servizi cloud intermedi o avanzati. Ma solo il 42,7% svolgeva analisi dei dati, internamente o tramite soggetti esterni: 41,9% tra le PMI, 83,6% tra le grandi imprese. L’ERP era usato dal 48,8% delle PMI, il CRM dal 21,1%, e la Business Intelligence risultava presente nel 16% delle imprese, senza variazioni significative rispetto al 2023. Questi numeri non dimostrano che le aziende italiane siano incapaci di misurare. Dimostrano qualcosa di più interessante: la capacità di raccogliere e interpretare dati economici e operativi è distribuita in modo molto diseguale. Un contratto a ore può essere amministrato anche da un’impresa con dati frammentari. Un contratto basato sulla riduzione del churn o dei tempi amministrativi no. Quando la baseline manca, il problema non è soltanto che non si riesce a misurare il risultato: non si riesce nemmeno a stabilire che cosa sarebbe successo senza il fornitore.

Il quadro più vicino al tema arriva dalla servitizzazione del machinery. L’osservatorio condotto con ASAP Service Management Forum su circa duecento imprese mostra un mercato che ha capito perfettamente la direzione strategica e fatica a trasformarla in organizzazione: il 57% dichiara una strategia mirata per il business dei servizi (83% tra le grandi, 48% tra le PMI), ma solo il 41% ha ruoli dedicati ai servizi, il 34% ha responsabilità specifiche per lo sviluppo di nuovi servizi e appena il 29% assegna loro un budget. I servizi digitali e connessi valgono circa l’1% dei ricavi, i contratti ricorrenti di manutenzione circa il 3%. Un’impresa su cinque dichiara di offrire modelli product-as-a-service, ma con ricavi ancora trascurabili. Non è conservatorismo: è la distanza fisiologica tra una slide e un conto economico. In Italia l’as-a-service è spesso già arrivato nella presentazione al consiglio di amministrazione. Non è ancora arrivato nel conto economico.

Nella pubblica amministrazione la tensione è ancora più visibile. Una ricerca esplorativa del Politecnico di Milano sui contratti outcome-based in un progetto pilota pubblico-privato rileva che gli ostacoli principali non sono giuridici ma infrastrutturali: mancano le competenze e i sistemi di archiviazione e gestione dei dati necessari ad amministrare strumenti di questo tipo. È un’evidenza accademica circoscritta, non una statistica nazionale, ma è coerente con il resto della diagnosi. Una PA può scrivere indicatori, penali e premialità; il problema è amministrare una fattura che dipende da un controfattuale, da dati distribuiti su più sistemi e da comportamenti di soggetti diversi dal fornitore. Per essere acquistabile, un risultato deve essere non soltanto vero, ma amministrativamente difendibile.

C’è infine un segnale che vale più di molte survey. Nel 2026 Assonime ha dedicato un position paper alla servitizzazione del Made in Italy, includendo i modelli pay-per-use e pay-per-outcome, e la proposta centrale non è un listino nuovo: è un’infrastruttura abilitante, una piattaforma che integri capacità produttive, servizi digitali, strumenti finanziari e competenze oggi frammentate. Quando un’associazione di imprese sente il bisogno di proporre un’infrastruttura per rendere possibile un modello di prezzo, sta implicitamente ammettendo che quel modello non è un trucco commerciale adottabile in autonomia. Richiede un ecosistema di dati, finanza, assicurazione e fiducia verificabile.

Il rischio travestito da prezzo

C’è un aspetto del pricing a risultato che quasi mai viene detto ad alta voce: il fornitore non sta semplicemente vendendo in modo diverso. Sta finanziando l’intervallo tra il lavoro svolto e il risultato osservato, e sta assicurando una parte della varianza del cliente. Un outcome che matura in dodici mesi implica dodici mesi di capitale immobilizzato. Se il risultato può essere contestato, il periodo si allunga. Se il contratto è interamente variabile, il fornitore sostiene anche il rischio di zero ricavi. Il cliente ottiene un finanziamento e una polizza incorporati nel prezzo; se il prezzo non contiene un premio per questi rischi, il fornitore li sta regalando oppure non li ha capiti.

Qui la struttura del sistema produttivo italiano smette di essere un dettaglio statistico. Nel Censimento permanente delle imprese, riferito alle imprese con almeno tre addetti, il 78,9% sono microimprese con meno di dieci persone, il 18,5% piccole, il 2,2% medie e lo 0,4% grandi. Non tutte fragili, non tutte sottocapitalizzate. Ma accettare una remunerazione a risultato significa finanziare anticipatamente il lavoro, sopportare volatilità nei ricavi, assorbire errori di misurazione, accantonare per le contestazioni e, soprattutto, distribuire il rischio su un portafoglio abbastanza ampio. Una piattaforma globale può spalmare il rischio su migliaia di clienti e milioni di eventi. Una software house di dieci, trenta o cinquanta persone non può comportarsi come una compagnia di assicurazione senza capitale assicurativo, dati attuariali e diversificazione. Perché consideriamo innovativo chiedere a una piccola impresa tecnologica di finanziare il progetto, assicurare le decisioni del cliente e incassare soltanto quando una metrica contestabile si muove nella direzione giusta?

Le patologie che ne derivano sono due, speculari. La prima è la proposta che il fornitore riceve: «non voglio pagare il progetto, ti riconosco una percentuale del risultato». Può sembrare fiducia; spesso è una richiesta di trasferimento asimmetrico del rischio, e i segnali si riconoscono. L’outcome è lontano dall’intervento, la baseline non esiste, i dati sono controllati solo dal cliente, le decisioni decisive restano al cliente, non c’è nessun obbligo di adozione, il pagamento è interamente variabile, non ci sono esclusioni per gli eventi esterni né un premio per il capitale immobilizzato. Il compratore sta chiedendo al fornitore di sottoscrivere insieme il rischio tecnologico, quello organizzativo e quello commerciale. Il cliente vuole il pricing dell’esito e la governance del capitolato.

La seconda patologia è l’offerta che il fornitore formula per vincere la gara, differenziarsi o aggirare l’obiezione sul prezzo: outcome definito in modo ambiguo, metrica manipolabile, condizioni necessarie taciute, premio al commerciale e rischio scaricato sul delivery, capitale necessario mai calcolato. E un fenomeno che chi vende sottovaluta sistematicamente: la selezione avversa. I clienti più desiderosi di pagare soltanto a risultato possono essere proprio quelli che conoscono meglio del venditore la fragilità della propria organizzazione, la qualità scadente dei propri dati, la bassa probabilità di adozione. Il fornitore non riceve un campione casuale di opportunità: riceve una concentrazione di casi che il cliente preferisce non finanziare direttamente. Nel pricing a risultato il cliente sa spesso più del fornitore su quanto sia improbabile il risultato.

Il punto di arrivo è lo stesso da entrambi i lati: molte offerte outcome-based non sono prezzi innovativi. Sono polizze assicurative scritte da persone che non sanno di essere diventate assicuratori.

Dove l’outcome funziona già

Sarebbe però falso dire che l’Italia non è pronta in assoluto, e le eccezioni sono la parte più istruttiva della storia, perché mostrano esattamente quali condizioni servono.

La prima è la farmaceutica. Nei registri di monitoraggio AIFA esistono da anni accordi di condivisione del rischio legati all’esito terapeutico: nel Payment by Results l’azienda farmaceutica rimborsa integralmente i trattamenti dei pazienti che non rispondono; nel Success Fee il Servizio sanitario ottiene inizialmente il farmaco gratuitamente e paga le confezioni soltanto dopo la verifica del successo terapeutico. Sono contratti in cui la fattura dipende letteralmente dal risultato clinico, e funzionano. Ma funzionano perché prima del prezzo esistono una popolazione eleggibile, criteri clinici, una finestra temporale, una definizione di risposta, una piattaforma nazionale, soggetti autorizzati a certificare e procedure di payback. Nessuno ha firmato un generico «pagheremo se i pazienti staranno meglio». Qualcuno ha costruito un’infrastruttura capace di tradurre un esito clinico in un evento amministrativo. L’outcome non precede l’infrastruttura di misurazione. Ne è il prodotto.

La seconda è l’energia. Negli Energy Performance Contract il miglioramento energetico viene definito, misurato e monitorato lungo tutta la durata del contratto: le linee guida ENEA insistono su baseline, risparmi garantiti, obblighi puntuali delle parti, procedure di verifica e regole per gestire i cambiamenti, dai prezzi dell’energia all’intensità d’uso degli impianti. Qui l’outcome è contrattualizzabile perché il consumo è misurabile, la baseline può essere storicizzata, esistono tecniche di normalizzazione, il fornitore controlla una parte rilevante delle leve e il risultato si osserva ripetutamente, non una volta sola. La gara Consip da 1,4 miliardi per il Servizio Integrato Energia degli enti locali, partita a marzo, combina canoni, risparmio energetico garantito, quota di fonti rinnovabili, comfort, tempi di intervento e un’estensione contrattuale legata alla qualità del servizio. Un modello ibrido, non una scommessa binaria su un generico «miglioramento».

Questi due casi permettono una conclusione più precisa della lamentela culturalista: l’Italia sa usare contratti a risultato quando il risultato è stato istituzionalizzato. Quello che non sa ancora fare diffusamente è improvvisare la stessa infrastruttura dentro una normale trattativa commerciale.

Il colpo di scena dell’AI

Il dibattito sull’AI sembra suggerire che il pricing a outcome sia ormai inevitabile: il costo marginale dell’esecuzione crolla, gli agenti lavorano da soli, il cliente non vuole comprare token o seat ma lavoro svolto. La direzione è reale. Ma se si guardano le offerte concrete dei vendor globali emerge un fatto molto più interessante: anche le aziende con più dati, più scala e più controllo tecnologico del pianeta evitano accuratamente di prezzare outcome economici ampi.

Intercom fattura Fin a 0,99 dollari per outcome, ma l’outcome è definito come risoluzione della conversazione, passaggio a una procedura o disqualificazione: una risoluzione può essere conteggiata quando, dopo l’ultima risposta, il cliente non chiede altro aiuto. HubSpot ha annunciato per aprile 2026 0,50 dollari per conversazione risolta e un dollaro per lead nell’outreach: non viene fatturata la fedeltà del cliente né la vendita conclusa, ma un evento operativo vicino al sistema del vendor. Salesforce usa i Flex Credits: ogni azione di Agentforce consuma venti crediti, circa 0,10 dollari, e l’unità concretamente misurata è l’azione, aggiornare un record, sintetizzare un caso, eseguire un flusso. La comunicazione parla di investimento allineato al valore; il contatore conta altro.

Non è una critica ai vendor: è probabilmente la scelta razionale. Stanno cercando la più piccola unità di valore che sia atomica, frequente, osservabile, attribuibile, governata dal loro sistema e fatturabile senza controversie infinite. Ogni requisito di quella lista è una risposta diretta a uno dei problemi visti sopra: attribuzione, baseline, controllo, costo di transazione. La parte pungente è semantica: il termine outcome si sta espandendo nella retorica proprio mentre si restringe nei listini, fino a includere eventi che qualche anno fa avremmo chiamato output, transazioni o automazioni riuscite. La frontiera commerciale dell’AI non sta prezzando i grandi risultati aziendali. Sta riducendo la distanza causale fino a trovare un evento abbastanza piccolo da poter essere chiamato outcome senza diventare una causa legale.

Questo permette di riportare il discorso sull’Italia senza provincialismo. Il problema non è che le imprese italiane siano arretrate rispetto a un mondo in cui tutti pagano l’EBITDA prodotto dall’AI, perché quel mondo non esiste: anche i vendor più avanzati preferiscono conversazioni risolte, lead qualificati, record aggiornati. E allora la previsione sensata è che il mercato italiano sarà pronto molto prima per outcome operativi stretti, il documento correttamente classificato, la pratica completata senza intervento umano, la fattura riconciliata, l’anomalia verificata, il tempo di processo sotto una soglia, che per compensi legati all’aumento dei ricavi, alla riduzione del churn o al successo complessivo di una trasformazione digitale. Sospetto che questa distinzione, tra l’outcome che si può contare e l’outcome che si può solo raccontare, varrà più di qualunque dibattito sul futuro del pricing.

Non tornare alle ore

Le obiezioni migliori a questo saggio meritano di essere prese sul serio, perché due su tre sono fondate.

La prima: il fornitore deve avere skin in the game. Vero, ed è l’obiezione più forte. Troppi fornitori vendono giornate, consegnano artefatti formalmente corretti e lasciano al cliente tutto il rischio che non producano valore. Ma la risposta giusta non è difendere il giorno-uomo: è pretendere che la condivisione del rischio sia proporzionale al controllo. Diventa estrazione quando una parte conserva le decisioni e trasferisce all’altra le conseguenze. Non si trasferisce responsabilità senza trasferire autorità.

La seconda: le ore premiano l’inefficienza. Anche questo è vero, e l’ho scritto io stesso. Un fornitore pagato a tempo può guadagnare di più lavorando più lentamente. Ma eliminare un’unità imperfetta e osservabile non autorizza a sostituirla con un’unità moralmente attraente e causalmente indecidibile. Il giorno-uomo sopravvive non perché sia intelligente. Sopravvive perché è verificabile. Il vero opposto del giorno-uomo non è il risultato: è l’osservabilità.

La terza: l’AI renderà tutto misurabile. Qui invece non ci siamo. L’AI rende più economico contare ciò che è accaduto; non stabilisce da sola perché sia accaduto. Il controfattuale, l’attribuzione, la cooperazione del cliente, il ritardo tra intervento ed effetto e gli eventi esterni restano esattamente dove erano. Come ho sostenuto a proposito delle metriche, contare meglio non è capire meglio.

E allora la direzione non è tornare alle giornate, ma costruire una scala di maturazione, che è poi il modo in cui lavoro quando posso scegliere. Prima si vende una fase pagata di osservabilità: definizione della baseline, mappatura delle fonti, verifica della qualità dei dati, identificazione delle leve, disegno del meccanismo di verifica. La provocazione è che la prima cosa che un fornitore serio dovrebbe vendere, in un progetto outcome-based, è il diritto di scoprire se l’outcome sia davvero vendibile. Poi una componente fissa che copra ciò che il fornitore sostiene comunque: avvio, infrastruttura, integrazione, presidio, rischio non controllabile. Poi una componente variabile circoscritta, indicativamente il 20-30% del valore, legata a uno o due outcome operativi, non a una costellazione di KPI. Con quattro proprietà non negoziabili: simmetria, perché un contratto in cui il cliente tiene tutto l’upside e trasferisce solo il downside non è allineamento; cap e floor, perché un rischio senza limite massimo e un compenso senza minimo sostenibile non sono un prezzo ma un’opzione gratuita concessa al cliente; obblighi del cliente trattati come condizioni economiche; e un change control causale, perché una variazione di prezzi, processo, personale o strategia può invalidare la baseline, e il contratto deve dire quando la metrica si ricalibra. Meglio, infine, misurazioni frequenti e regolazioni trimestrali su un registro interrogabile da entrambe le parti che una singola verifica dopo dodici mesi su un foglio Excel prodotto dal soggetto economicamente interessato.

Un rapporto commerciale può partire da output e SLA, passare a outcome operativi quando la baseline esiste, e arrivare eventualmente a una quota legata al risultato economico. Il pricing a risultato non dovrebbe essere il punto di partenza della fiducia. Dovrebbe essere uno dei suoi prodotti finali.

Il rischio che qualcuno sa governare

Il pricing basato sugli outcome arriverà anche nel mercato italiano. In alcuni settori è già arrivato, ma non è comparso grazie al coraggio di un commerciale disposto a rinunciare alla fee. È comparso dove qualcuno aveva costruito prima registri, baseline, criteri di eleggibilità, sistemi di misurazione, obblighi reciproci e procedure di verifica. L’outcome non ha sostituito la governance. È diventato contrattualizzabile perché la governance lo aveva reso un fatto amministrativo.

L’AI accelererà questa traiettoria, ma probabilmente in una forma meno eroica di quella annunciata. Pagheremo sempre meno token, seat e giornate. Pagheremo documenti elaborati, conversazioni risolte, pratiche completate e azioni eseguite. Chiameremo outcome eventi sempre più vicini alla macchina, perché sono quelli che la macchina può misurare e il fornitore può controllare. I risultati più grandi continueranno a essere prodotti da sistemi in cui tecnologia, organizzazione e decisioni umane restano inseparabili, e nessun listino li dividerà in fattura.

La diagnosi finale, allora, è meno provinciale e più dura di «il mercato italiano non capisce». Il mercato italiano non rifiuta il pricing a risultato perché non crede nei risultati. Lo rifiuta, o lo pratica male, perché tenta di far svolgere al prezzo il lavoro che non hanno fatto la governance, i dati e l’organizzazione. Vogliamo superare il giorno-uomo perché remunera ciò che il fornitore controlla invece di ciò che il cliente desidera. Ma, nel farlo, rischiamo di remunerare il fornitore per ciò che il cliente desidera e che nessuna delle due parti può attribuirgli con certezza.

Rifiutare di garantire un risultato che non si controlla non è mancanza di fiducia nel proprio lavoro. Può essere il segno di aver finalmente capito il lavoro del cliente. Allo stesso modo, chiedere al fornitore di condividere il rischio non è scorretto. Lo diventa quando il cliente conserva tutte le leve e considera innovativo trasferire altrove le conseguenze delle proprie decisioni. Un mercato maturo non è quello in cui ogni fornitore accetta di essere pagato soltanto in caso di successo. È quello in cui le parti sanno distinguere il rischio che ciascuna controlla, misurarlo e remunerarlo.

Non si paga un risultato. Si paga un rischio che qualcuno è davvero in grado di governare.

L'autore

Andrea MargiovanniAdvisory

Faccio advisory indipendente per chi compra servizi IT: assessment di fornitori, revisione contratti, seconda opinione su RFP. Non vendo ore. Vendo letture del contesto e decisioni difendibili.

Vai al percorso →