La maggior parte dei dibattiti sul pricing SaaS parte dal punto sbagliato.
I team discutono di tier. Si arrovellano tra numero di postazioni e limiti di utilizzo. Fanno benchmark con i competitor. Lanciano sondaggi per chiedere ai clienti quanto sarebbero disposti a pagare. Poi vanno sul mercato, vedono i margini comprimersi e si domandano cosa sia andato storto.
Ecco cosa è successo: il modello di pricing è stato costruito su stime dei costi, non sulla realtà. E le stime invecchiano male. Il segreto scomodo dell'unit economics nel SaaS
Quando un VP of Product o un consulente di pricing costruisce un modello per un nuovo piano, ragiona a ritroso partendo da ipotesi. I costi dell'infrastruttura vengono approssimati. Il consumo delle risorse condivise viene mediato. L'utilizzo dell'AI si stima a occhio. La varianza tra i clienti viene appiattita in un'unica linea.
Il modello dice che servire un cliente sul piano Growth dovrebbe costare 80 $/mese. Il costo reale, una volta ricostruito sull'infrastruttura effettiva, si avvicina ai 190 $ per gli account più pesanti e ai 12 $ per quelli più leggeri. La media sembra sana. È la coda a ucciderla in silenzio.
Non è un problema di strategia di pricing. È un problema di dati. Nello specifico, è un problema di dataset mancante.
Perché esiste questo gap
Gli strumenti tradizionali per i costi cloud sono nati per i team FinOps che gestiscono i budget dell'infrastruttura. Leggono gli export di fatturazione, analizzano i log di CloudTrail e organizzano la spesa per account, regione o tag. Utile per il team di engineering che deve fare right-sizing delle istanze EC2.
Non utile per il pricing.
I team pricing hanno bisogno di costi organizzati in modo diverso: per cliente, per linea di prodotto, per funzionalità, per l'unità di consumo che effettivamente fatturano. Un export di fatturazione non sa quale cliente abbia innescato quale workload. Non sa che un singolo account enterprise esegue job di scansione che consumano 40 volte più compute rispetto a chiunque altro sullo stesso piano. Non sa che la sua funzionalità AI costa tre volte di più per i power user rispetto agli utenti occasionali.
Il livello di fatturazione non ha questo contesto. Non l'ha mai avuto. È stato progettato per dire ai cloud provider quanto addebitarle, non per dirle quanto costa far girare i workloads di ogni singolo cliente.
Per rispondere a quella domanda serve una fonte dati completamente diversa.
Cosa cambia con i dati a runtime
Quando si strumenta l'infrastruttura sulla base di dati a runtime, leggendo traffico reale, chiamate ai servizi reali e consumo effettivo delle risorse nel momento in cui avvengono, il quadro dei costi cambia radicalmente.
Si vede quali clienti stanno generando quali workloads. Si può risalire da una query di database alla funzionalità che l'ha innescata, e da lì al cliente che l'ha usata. Si possono osservare risorse condivise come Kafka o Elasticsearch e capire quali tenant stanno consumando quanto, senza chiedere agli engineer di applicare tag a nulla.
Non è una capacità teorica. Esiste oggi, in produzione, presso aziende che stanno facendo esattamente questo tipo di analisi.
Cosa scoprono?
Nella maggior parte dei casi, scoprono che il loro modello mentale sulla distribuzione dei costi è sbagliato. Lo scarto tra i consumatori più leggeri e quelli più pesanti è più ampio del previsto. Una piccola percentuale di account, di solito enterprise, di solito collocati a metà dello stack dei piani, consuma a un ritmo tale da far sembrare il loro ARR uno sconto.
Un'azienda ha individuato 360 account in cui il cost-to-serve superava il fatturato. Esposizione totale: 1,3 milioni di dollari di perdite annue, invisibili finché l'attribuzione a runtime non ha ricondotto i costi ai singoli clienti. Le perdite non erano negli account in rosso che ci si aspettava fossero in rosso. Si nascondevano in piani che sembravano generare ARR sano.
Il pricing dell'AI è l'anticipazione di ciò che sta arrivando
Questo tipo di compressione dei margini sta peggiorando, non migliorando.
Le funzionalità AI cambiano la struttura dei costi di un prodotto SaaS in modi che il pricing per postazione, o persino quello a consumo, spesso non riesce a catturare. Un agente AI che esegue un workflow multi-step non consuma una quantità fissa di compute. Consuma in base alla complessità, alla dimensione dell'input, al numero di tool che chiama, al numero di token che brucia lungo il percorso. Due clienti che usano la stessa funzionalità AI possono avere profili di costo che differiscono di 10 volte.
Se il modello di pricing li tratta allo stesso modo, uno dei due sta sussidiando l'altro.
Le aziende che riusciranno a impostare correttamente il pricing dell'AI sono quelle in grado di vedere consumo di token, azioni degli agenti e volume delle chiamate ai tool a livello di singolo cliente, e di costruire un pricing che rispecchi questa realtà. Non per postazione. Non per migliaia di richieste. Strutture di pricing che riflettono i veri driver di costo del prodotto.
Servono dati a runtime. Non c'è altro modo per ottenerli con questo livello di granularità.
Cosa si sblocca per i team di pricing
Può identificare quali segmenti hanno margine negativo prima che compaiano in una presentazione al board. Può vedere quali tier di piano hanno la varianza di costo più ampia e progettare limiti di utilizzo o add-on aderenti al consumo reale. Può testare l'impatto sul margine di una nuova capability prima di prezzarla e rilasciarla, usando dati di baseline reali invece di ipotesi modellate.
Può anche costruire modelli di pricing prima impensabili. Il consumption-based pricing smette di essere una scommessa quando sa esattamente quanto costa erogare ogni unità di consumo. Il value-based pricing diventa difendibile quando può mostrare quanto spende effettivamente per generare il risultato che sta facendo pagare.
L'era agentica rende tutto questo ancora più urgente. Se fattura 250 $ per ogni task completato, deve sapere se quel task è costato 80 $ o 380 $. La risposta cambia tutto: quali workflow prezzare più alti, quali riprogettare, quali clienti sono profittevoli alla tariffa attuale. Senza dati a runtime, sta volando alla cieca sulle decisioni di pricing più importanti.
Può rispondere alla domanda a cui i team di pricing hanno sempre avuto bisogno di rispondere, ma che raramente sono riusciti a chiarire: quanto costa davvero erogare questo valore a questo cliente?
Quando ha questa risposta, la strategia di pricing smette di essere un esercizio di intuito. Diventa un vantaggio competitivo.
La domanda da porsi alla prossima pricing review
Prima di discutere di tier di packaging o di gating delle funzionalità, si ponga una domanda preliminare: sappiamo davvero quanto costa servire ogni singolo cliente, ogni piano, ogni funzionalità?
Se la risposta passa da fogli di calcolo e stime, il modello di pricing poggia su fondamenta che non reggeranno alla crescita del prodotto.
Parta dalla realtà dei costi. Tutto il resto viene di conseguenza.
Attribute™ mappa i costi dell'infrastruttura cloud e AI su clienti, prodotti e funzionalità usando dati a runtime, senza tagging. Scopra come funziona per i team di pricing.