Due diligence sul pricing per il software AI: seat, usage, outcome

La due diligence sul modello di pricing è la disciplina che verifica se il modello di monetizzazione di un target — basato su seat, su usage o consumo, su outcome o valore, o un ibrido di questi — si adatta davvero all'economia di prodotto sottostante e al contesto d'acquisto in cui vende. Non è una revisione della pagina dei prezzi. Chiede quale unità l'azienda fattura, chi attiva quell'unità, se l'azienda è in grado di prevederla e se il modello sopravviverà al contatto con gli acquisti enterprise, l'automazione guidata dall'AI e la struttura dei costi dello stesso target. Sbagliare questa valutazione porta a prezzare in modo errato la qualità della crescita, la retention e il margine nella valutazione.

Il motivo per cui questa è diventata una domanda concreta di due diligence è che l'AI infrange l'assunzione su cui era costruito il pricing tradizionale dei SaaS. Il SaaS classico presupponeva un costo marginale nullo: una volta costruito il software, il cliente successivo costava più o meno quanto il precedente da servire, così gli abbonamenti flat per seat funzionavano. I prodotti AI comportano un costo di inferenza variabile e significativo, in cui ogni query, azione di un agente o artefatto generato attiva una spesa di calcolo che il fornitore paga. Quando il modello di pricing non segue quel costo variabile, il margine si riduce con l'adozione invece di espandersi.[1]

I team di due diligence dovrebbero calibrarsi sulla realtà di mercato piuttosto che sull'hype. AlixPartners ha analizzato 65 grandi aziende SaaS e concorrenti AI-native e ha scoperto che solo 4 hanno adottato pienamente un pricing basato sui risultati, mentre il 72% adotta un approccio ibrido che incorpora il consumo tramite crediti AI o misurazione dell'uso, e più della metà delle aziende restanti fa ancora principalmente affidamento su modelli per postazione.[2] La migrazione è reale ma più lenta e disomogenea di quanto suggeriscano i commenti, ed è per questo che il modello corretto è una questione di economia del prodotto, non di ideologia.

Per Seat: una tariffa fissa per utente con accesso all'AI, familiare per gli acquirenti ma fragile quando il costo variabile dell'inferenza cresce con l'utilizzo.

Per Token: misurazione di input e output del modello, il modello canonico del livello infrastrutturale, trasparente per gli ingegneri ma difficile da budgetare per gli acquirenti business.

Per Activity: un addebito per azione discreta come una conversazione, una chiamata API o un'esecuzione di workflow.

Per Output: un addebito per artefatto generato come un'immagine, un documento o una bozza di report.

Per Outcome: un addebito solo quando l'AI consegna un risultato aziendale definito, come un ticket risolto.

Hybrid: una base in abbonamento combinata con eccedenze di consumo, crediti prepagati o componenti basati sui risultati, lo schema che la maggior parte delle aziende AI in produzione adotta.

Ciascuno di questi modelli presenta un profilo di due diligence distinto. Per un trattamento più approfondito di come la compressione delle postazioni, il COGS dell'inferenza e le strutture ibride si riflettono nell'analisi delle transazioni, si veda il nostro articolo complementare sulla due diligence del pricing AI. Le sezioni seguenti offrono agli acquirenti un framework corrispondente, test modello per modello, una checklist di evidenze e i red flag che collegano i risultati del pricing alla valutazione.

Prima di giudicare se il modello di pricing di un target è buono o cattivo, gli acquirenti dovrebbero applicare una diagnostica che separi l'aderenza dalla moda. Un modello che appare aggressivo in un contesto può essere esattamente giusto in un altro. Sei domande strutturano tale giudizio:

Cosa viene monetizzato: l'accesso al software, un'attività contabile, un output generato o un risultato aziendale conseguito?

Chi innesca il consumo: un utente umano, un workflow automatizzato o l'agente AI stesso? Un modello fatturato per utente si comporta in modo molto diverso quando sono gli agenti a fare il lavoro.

Quanto è prevedibile l'utilizzo: il consumo è stabile e prevedibile, o oscilla con la stagionalità, il comportamento dei clienti e la complessità delle query?

Il valore o il risultato può essere misurato e attribuito: il successo è discreto e verificabile, o diffuso tra molti fattori concorrenti?

Il pricing è allineato agli acquisti enterprise: un CIO può budgetarlo, farlo passare attraverso l'ufficio acquisti e difenderlo internamente?

Quanto potere di pricing ha davvero l'azienda: il modello di pricing è difendibile perché il prodotto è radicato nei workflow e difficile da sostituire, o è esposto a riprezzamenti competitivi?

Due framework pubblicati aiutano a rispondere a queste domande. Il framework COMPASS di Zuora ordina i sei comuni modelli di pricing AI — per seat, per token, per activity, per output, per outcome e ibrido — in base all'unità di valore che l'AI consegna e a quanto chiaramente quel valore possa essere misurato, e rileva che la maggior parte delle aziende AI in produzione finisce per adottare modelli ibridi che combinano una base in abbonamento con eccedenze di consumo o crediti prepagati.[1] Il framework non dice a un'azienda quanto addebitare, ma mostra quando una dichiarazione di risultato è credibile e quando è un rivestimento di marketing: laddove il successo non può essere misurato in un modo che il cliente accetti, un misuratore di risultato è una posizione negoziale più che un modello di pricing.

AlixPartners aggiunge tre condizioni strutturali di esposizione che indicano agli acquirenti quanta pressione subisce un modello di pricing: un'alta concentrazione di postazioni in workflow automatizzabili come il servizio clienti o il ticketing IT, la vendita in funzioni dove il ROI dell'AI è facilmente misurabile, e l'affidamento su postazioni con limitati livelli di pricing secondario. Le aziende all'intersezione di tutte e tre le condizioni affrontano il bisogno più urgente di agire.[2] Il potere di pricing stesso dovrebbe essere testato separatamente: laddove un prodotto è profondamente radicato e il passaggio a un altro fornitore è costoso, un vendor ha più margine per difendere il valore delle postazioni, una dinamica che esaminiamo nella nostra analisi dei costi di switching dei workflow.

Ogni modello di pricing fallisce a modo suo, quindi ognuno richiede le proprie domande di due diligence. La tabella seguente riassume i test principali; i paragrafi successivi approfondiscono le due aree in cui gli affari vanno più spesso storti.

Modelli a postazione: la compressione è il churn silenzioso

Per i target basati su postazioni, la prova centrale è il rischio di compressione delle postazioni: laddove gli agenti AI possono gestire il carico di lavoro di utenti che altrimenti detterebbero una licenza, l'argomento del valore per postazione si indebolisce a ogni ciclo di deployment. La due diligence dovrebbe quantificare quanto fatturato dipenda da flussi di lavoro ripetitivi e basati su regole, ed esaminare separatamente lo shelfware, ovvero il divario tra postazioni licenziate e attive, perché gonfia l'adozione dichiarata e sottostima il rischio di rinnovo. Profondità degli sconti e realizzazione del prezzo completano il quadro: un'azienda che cresce in postazioni tagliando i prezzi non sta dimostrando potere di prezzo.

Modelli a risultato: la definizione è il prodotto

Per i target basati sui risultati, la definizione dei prezzi è di fatto parte del prodotto. Non esiste uno standard di settore condiviso per la valutazione dei risultati, quindi i prezzi per risoluzione pubblicati non sono confrontabili tra i vari fornitori.[3] Gli acquirenti dovrebbero chiarire come viene verificato il successo, come viene trattato il silenzio del cliente, cosa accade quando l'AI passa il compito a un umano a metà attività e chi sopporta il costo quando i tassi di risoluzione deludono. AlixPartners ha rilevato che le quattro aziende del suo campione con prezzi basati sui risultati confermati operano tutte nei flussi di lavoro del customer service, dove i risultati sono discreti e verificabili: un utile punto di riferimento su quanto sia ristretto lo spazio attualmente praticabile.[2]

I risultati dell'analisi dei prezzi sono validi solo quanto i documenti che li sostengono. Il data room dovrebbe essere setacciato alla ricerca di quanto segue, e le lacune in questo elenco sono esse stesse un riscontro:

Mappatura delle prove sui prezzi da contratti e dati di utilizzo ai riscontri della due diligence. · Generato con IA

Contratti con i clienti e moduli d'ordine con listini prezzi, comprese le condizioni di rinnovo e gli eventuali impegni di utilizzo o di risultato.

Listini prezzi e registri di approvazione degli sconti, per verificare il prezzo effettivo rispetto al prezzo di listino.

Dati di utilizzo e consumo per cliente, inclusi i meccanismi di consumo dei crediti e di riconciliazione (true-up) per modelli prepagati o basati su allowance.

Note di riconoscimento dei ricavi che descrivono come utilizzo, crediti e commissioni a risultato sono trattati ai sensi dell'ASC 606.

Prove di churn, downgrade ed espansione relative a modifiche pregresse di prezzi o packaging, a livello di coorte dove disponibile.

Le condizioni contrattuali determinano il trattamento contabile, che a sua volta modella la qualità dei ricavi dichiarati. Le linee guida DART di Deloitte evidenziano il giudizio chiave per i contratti di AI agentica: se la promessa del fornitore costituisce un'obbligazione di disponibilità continua (stand-ready) a fornire accesso continuativo all'agente, generalmente riconosciuta nel tempo, oppure un'obbligazione di consegnare una quantità specifica di risultati positivi, generalmente riconosciuta man mano che tali risultati si verificano. I criteri di successo e i diritti di riporto contano qui, e i crediti prepagati per risultati possono essere non rimborsabili su base use-it-or-lose-it oppure rimborsabili, il che cambia il comportamento dei ricavi differiti e delle controprestazioni variabili.[4]

Le prove di utilizzo devono inoltre essere ricondotte al contatore effettivamente in vigore, perché anche i contatori si evolvono. GitHub Copilot, ad esempio, misura le interazioni in base a token di input, output e cache a tariffe che variano per modello, le converte in crediti AI dove un credito equivale a un centesimo di dollaro USA, include un'allowance per piano e fattura l'utilizzo oltre tale allowance per token, mentre i completamenti di codice restano fuori dal contatore dei crediti.[5] Un dataset di utilizzo costruito su un contatore obsoleto può essere inutile per prevedere quello attuale. Gli strumenti di analisi di documenti finanziari aiutano i team di deal a estrarre queste condizioni da contratti densi e a confrontarle con i file di utilizzo.

I seguenti pattern dovrebbero innescare verifiche più approfondite prima di arrivare al comitato di investimento.

Il pattern alla base di diversi di questi segnali è l'allocazione del rischio. Delle 65 aziende analizzate da AlixPartners, 53 scaricano il rischio di performance sul cliente, 8 lo condividono e solo 4 lo sopportano in qualità di fornitore, il che significa che per l'82% delle aziende è il cliente a pagare il prezzo se il software non funziona.[2] E nello specifico del pricing a risultato, la parte che sceglie il sostituto del successo è la parte che invia la fattura, ed è per questo che le definizioni di risultato meritano lo stesso scrutinio del prezzo stesso.[3]

Per i professionisti degli investimenti in PE e VC, i risultati dell'analisi dei prezzi dovrebbero alimentare direttamente la valutazione della qualità dei ricavi. In materia di controprestazioni variabili, Deloitte rileva che quando un contratto si qualifica come una serie di servizi distinti, le commissioni a risultato possono essere riconosciute man mano che i risultati positivi si verificano anziché nel tempo, il che modifica la tempistica dei ricavi e rende la crescita dichiarata più sensibile ai volumi di risoluzione.[4] Prevedere un'impresa i cui ricavi dipendono da risultati che il cliente deve raggiungere è un esercizio diverso dal prevedere le postazioni, e l'analisi della qualità dell'ARR dovrebbe rifletterlo.

Il margine lordo è la seconda esposizione. Quando il pricing non segue il costo variabile, l'adozione espande la spesa di inferenza più rapidamente dei ricavi: è la trappola del margine che Zuora descrive.[1] La due diligence dovrebbe modellare il costo di servizio per unità di fatturazione, non solo il margine lordo aggregato, e sottoporlo a stress test rispetto alla crescita dell'utilizzo. Questo si collega direttamente al workstream della due diligence del modello finanziario, dove le ipotesi sull'unit economics spesso nascondono il rischio legato al modello di pricing.

In terzo luogo, le dinamiche dell'NRR e il rischio di multiplo si concentrano ovunque un modello sia a metà migrazione. AlixPartners avverte che passare troppo presto a un pricing basato sui risultati rischia di cannibalizzare i ricavi per postazione, mentre muoversi troppo tardi rischia di cedere posizioni di mercato.[2] Un target intrappolato tra due modelli può mostrare un NRR compresso sulla base storica e una retention non dimostrata su quella nuova, il che è una questione di multiplo, non una nota a piè di pagina.

Ripricing: correggere il prezzo realizzato verso il listino laddove gli sconti hanno eroso la realizzazione.

Ripackaging: ristrutturare franchigie, eccedenze ed entitlement dei moduli per allinearli al modo in cui i clienti consumano effettivamente.

Sequenza di migrazione: spostare le coorti di clienti verso i nuovi modelli in un ordine che protegga i ricavi per postazione finché la retention del nuovo modello non è dimostrata.

Queste leve sono il punto in cui il valore post-closing viene creato o distrutto, e i team che seguono mandati di advisory M&A dovrebbero trattare la questione della sequenzialità come voce del piano di creazione di valore, non come un ripensamento commerciale.

Il framework sopra descritto ha valore solo se arriva ai workstream del deal team in forma strutturata e supportata da evidenze. La piattaforma supporta questo flusso di lavoro end-to-end:

Usa Data Room Ingestion per analizzare contratti dei clienti, moduli d'ordine e listini prezzi entro pochi minuti dall'apertura della data room, così che le condizioni di pricing entrino nell'analisi dal primo giorno.

Usa l'AI-Analysis Engine per estrarre condizioni di pricing, definizioni dei meter e criteri di successo da contratti densi, e per incrociare i dati di utilizzo con i ricavi dichiarati.

Usa Risk Radar per evidenziare i rischi di pricing, assegnare loro un punteggio in base alla materialità e alla rilevanza per l'operazione, e classificarli insieme al resto del registro dei rischi.

Usa il Collaboration Hub per allineare i workstream di due diligence commerciale, finanziaria e tecnologica su un unico set di domande ed evidenze sul pricing.

Usa Report Builder per redigere conclusioni supportate da evidenze con piena tracciabilità delle fonti, così che ogni affermazione sul pricing nel report rimandi a un documento presente nella data room.

Un limite va dichiarato chiaramente: Plausity aiuta i deal team a strutturare le evidenze e a organizzare le domande di due diligence, ma non determina automaticamente il modello di pricing corretto. Quel giudizio resta al team, ed è meglio prenderlo nel modo in cui gli esperti di TechTarget consigliano agli acquirenti di farlo: facendo percorrere casi reali al pricing prima della firma, invece di discutere sui tassi d'ingresso.[3] I deal team che vogliono capire come questo si inserisce in una configurazione più ampia di deal team deal team supportato da evidenze, o di come l'IA supporta l'automazione del flusso di due diligence dalla triage della data room alla registrazione dei rischi, troveranno che le domande sul pricing sopra descritte si integrano direttamente in quei flussi di lavoro.

Nella pratica, conduci il workstream del pricing in quattro passi. Primo, classifica l'unità di fatturazione e il packaging del target dai moduli d'ordine, non dalla pagina dei prezzi, e annota dove postazioni, meter e fee sui risultati si sovrappongono. Secondo, applica le sei domande diagnostiche sopra indicate per verificare l'aderenza all'economia del prodotto e alla realtà degli acquisti. Terzo, collega ogni affermazione a un documento: contratti, listini prezzi, estratti di utilizzo e note sul riconoscimento dei ricavi, segnalando le lacune come risultanze a sé stanti. Quarto, traduci le risultanze nel caso di valutazione, mostrando cosa significano per la qualità della crescita, il margine lordo, la prevedibilità dei ricavi e il piano post-closing di ripricing, ripackaging e sequenza di migrazione. I team di due diligence commerciale possono portare questa struttura direttamente nel dossier per il comitato investimenti.

1. [1] zuora.com — https://www.zuora.com/guides/ai-pricing-models
2. [2] alixpartners.com — https://www.alixpartners.com/insights/102nf2s/outcome-based-software-pricing-hype-or-reality/
3. [3] techtarget.com — https://www.techtarget.com/enterprise-software/feature/Outcome-based-AI-pricing-hits-a-measurement-problem
4. [4] dart.deloitte.com — https://dart.deloitte.com/USDART/home/publications/deloitte/industry/technology/accounting-outcome-based-pricing-agentic-ai
5. [5] docs.github.com — https://docs.github.com/copilot/reference/copilot-billing/models-and-pricing