I prezzi dell'AI di Salesforce infrangono la promessa SaaS per utente
I prezzi dell'AI di Salesforce misurano ora azioni, conversazioni o utenti, portando alla luce un conflitto che gli abbonamenti software prevedibili un tempo nascondevano. Gli agenti AI possono svolgere lavoro senza aumentare il personale, mentre ogni chiamata al modello genera un costo di calcolo variabile. Questa combinazione indebolisce il legame tra organico del cliente, valore del software e ricavi del fornitore.
Il cambiamento è importante perché gli abbonamenti per utente offrivano alle aziende software ricavi ricorrenti insolitamente visibili. I clienti potevano prevedere la spesa in base al numero di dipendenti, mentre gli investitori potevano modellare rinnovi ed espansioni. Gli agenti AI alterano entrambi i calcoli aumentando l'attività utile e riducendo potenzialmente il numero di utenti umani.
Salesforce non sta abbandonando gli abbonamenti e il settore del software-as-a-service non sta scomparendo. Salesforce, Microsoft, HubSpot, Intercom e altri fornitori stanno invece sperimentando simultaneamente diverse metriche di fatturazione. Il mercato che ne deriva è meno prevedibile, anche quando il software svolge più lavoro.
I prezzi dell'AI di Salesforce seguono ora il lavoro
I prezzi dell'AI di Salesforce non presumono più che un singolo utente umano rappresenti l'unità più chiara del valore del software.
L'azienda presenta attualmente opzioni basate sul consumo accanto alle licenze per utente per Agentforce. Il suo sistema di consumo utilizza Flex Credits, che traducono diversi prompt e azioni degli agenti in un'unità di fatturazione condivisa. Per alcuni casi d'uso rivolti ai clienti restano disponibili accordi basati sulle conversazioni.
Salesforce spiega che un agente autonomo può ragionare, chiamare strumenti, aggiornare record e completare flussi di lavoro in più passaggi. Ogni operazione può generare un'azione fatturabile nel suo modello Flex Credits. Le funzionalità integrate più semplici, come la stesura o la sintesi, possono invece essere misurate tramite prompt.
Questa struttura riflette un problema pratico. Un agente del servizio clienti potrebbe autenticare un acquirente, recuperare un ordine, verificare i dati di evasione e preparare una risposta. Una singola conversazione visibile può quindi contenere diverse azioni, ciascuna con requisiti infrastrutturali differenti.
Una licenza per utente comprime tali differenze in un unico addebito ricorrente. Funziona quando i dipendenti restano gli operatori principali e i costi del software cambiano lentamente. Diventa più difficile quando i sistemi autonomi possono operare ininterrottamente, diramarsi in passaggi aggiuntivi e chiamare diversi modelli.
Salesforce non ha scelto un unico sostituto universale dei prezzi per utente. Offre metriche diverse perché l'assistenza ai dipendenti, il supporto clienti e l'esecuzione autonoma creano relazioni diverse tra attività e valore. Questa varietà è la prova di una transizione ancora instabile, non di una formula di prezzo ormai definita.
L'azienda fornisce inoltre un portafoglio digitale per monitorare il consumo. I clienti possono controllare l'utilizzo dei crediti, analizzare le tendenze e configurare avvisi prima che l'attività superi le aspettative. Questi controlli riconoscono che la fatturazione variabile richiede maggiore attenzione operativa rispetto a un numero fisso di licenze.
L'AI modifica anche il lato dei costi. I fornitori SaaS tradizionali servono generalmente un utente aggiuntivo con una spesa infrastrutturale incrementale relativamente bassa. L'AI generativa introduce costi di inferenza ogni volta che un modello elabora contesto, genera una risposta o seleziona un altro strumento.
Un agente può ripetere queste operazioni molte volte per soddisfare una singola richiesta. Il fornitore del software deve quindi assorbire questa spesa variabile oppure trasferirne una parte al cliente. Un abbonamento fisso può diventare poco attraente quando l'utilizzo differisce nettamente tra account altrimenti simili.
Il cambiamento dei prezzi dell'11 settembre riportato da Axios è quindi più ampio di un semplice aggiustamento dell'offerta. Cambia il modo in cui clienti, fornitori e investitori interpretano i ricavi ricorrenti. La vecchia metrica contava l'accesso, mentre quelle emergenti contano l'attività o il lavoro completato.
Il cambiamento non rende inutili le licenze per utente. Gli utenti umani hanno ancora bisogno di dashboard, approvazioni, controlli amministrativi e funzionalità di collaborazione. Molte aziende manterranno quindi un abbonamento di base, aggiungendo una componente variabile per gli agenti.
Questa formula ibrida offre al fornitore una base stabile di ricavi. Collega inoltre i ricavi incrementali all'aumento dell'uso dell'AI. Per il cliente, tuttavia, crea un'altra metrica che i team di procurement e finanza devono prevedere.
L'evento immediato non è la morte del SaaS. È la perdita di una relazione lineare: più dipendenti significavano più licenze, e più licenze significavano più ricavi ricorrenti. Un agente AI può ora aumentare la produzione senza preservare questa equazione.
Perché i prezzi SaaS per utente sono sotto pressione
Il modello per utente si indebolisce quando il software svolge lavoro invece di limitarsi ad aiutare i dipendenti a svolgerlo.
Un utente funziona come unità di prezzo quando l'accesso segue da vicino il valore. Un rappresentante commerciale usa una piattaforma di gestione delle relazioni con i clienti, un contabile usa software finanziario e un ingegnere usa strumenti di sviluppo. Con la crescita del team, il cliente acquista account aggiuntivi.
Gli agenti AI creano uno schema diverso. Un dipendente può dirigere diversi agenti, mentre un agente può servire un intero reparto. Il cliente può ricevere più lavoro completato anche se il numero di accessi umani resta stabile o diminuisce.
Questa è l'inversione centrale che i fornitori SaaS devono affrontare. Un'automazione efficace può ridurre proprio il numero di utenti che storicamente sosteneva i ricavi da espansione. Un prodotto che fa risparmiare lavoro dovrebbe creare valore per il cliente, ma un contratto basato sulle licenze può impedire al fornitore di condividere tale valore.
I clienti mettono inoltre più aggressivamente in discussione le licenze inutilizzate quando gli agenti gestiscono le attività di routine. Shelfware indica capacità acquistata che i dipendenti usano raramente. Un'organizzazione ha meno ragioni per tollerarla quando i flussi di lavoro automatizzati possono concentrare il lavoro tra meno operatori.
McKinsey ha esaminato i modelli di prezzo di 150 fornitori globali e intervistato oltre 50 aziende che lanciavano prodotti AI. Il suo studio sui fornitori ha rilevato che le aziende native dell'AI dipendono già meno dagli abbonamenti per utente rispetto ai fornitori affermati.
Tra le aziende studiate, le tariffe di piattaforma erano il modello di abbonamento predominante per il 44 per cento dei fornitori AI-native. Solo il 22 per cento utilizzava principalmente abbonamenti per utente. Le aziende software consolidate mostravano il modello opposto, con il 78 per cento incentrato sui prezzi per utente.
Questi dati non dimostrano che ogni categoria software abbandonerà le licenze. Gli strumenti di collaborazione continuano a trarre valore da un'ampia partecipazione dei dipendenti. Anche i sistemi amministrativi richiedono utenti nominativi per sicurezza, responsabilità e gestione delle autorizzazioni.
I dati mostrano però che le metriche di accesso aziendale e di consumo stanno diventando alternative credibili. Separano i ricavi dal numero di persone che aprono il prodotto. Questa separazione diventa preziosa quando gli agenti svolgono lavoro tramite interfacce di programmazione delle applicazioni anziché interfacce grafiche.
Con il verificarsi di questo cambiamento, gli investitori devono riconsiderare ipotesi di valutazione consolidate. I contratti annuali possono ancora produrre ricavi ricorrenti, ma il consumo introduce una maggiore variabilità all'interno di ciascun account. L'espansione dipende dalla crescita dei carichi di lavoro, non solo dalle assunzioni o dall'adozione nei reparti.
Le spese per l'AI aggiungono un'altra incertezza. L'uso dei modelli, il recupero delle informazioni, le chiamate agli strumenti e l'elaborazione dei dati possono aumentare il costo di servizio dei clienti attivi. I margini lordi possono quindi variare in funzione della composizione dei carichi di lavoro, della scelta del modello e del comportamento degli agenti.
Un fornitore potrebbe ottenere margini interessanti da attività brevi e ripetibili. Lo stesso contratto potrebbe diventare meno attraente quando gli agenti elaborano documenti di grandi dimensioni o ritentano flussi di lavoro complessi. L'economia media per licenza non può rivelare questa differenza.
Gli acquirenti affrontano il riflesso di questo problema. Ottengono un legame più stretto tra spesa e attività, ma perdono la semplicità di contare i dipendenti. I team finanziari devono modellare la frequenza con cui gli agenti operano e la complessità crescente delle loro attività.
Anche i team di procurement richiederanno definizioni più chiare. Un fornitore deve spiegare cosa conta come azione, conversazione, risoluzione o credito. I clienti devono sapere se tentativi falliti, nuovi tentativi, escalation e attività di test consumano la loro quota.
Questo rende la telemetria parte del prodotto commerciale. Dashboard di utilizzo, limiti di spesa e registri di audit non sono più extra amministrativi opzionali. Determinano se i clienti si fidano della fattura e possono giustificarla internamente.
La pressione va oltre l'acquisto. I team di prodotto devono progettare unità misurabili, i team tecnici devono registrarle e i team commerciali devono spiegarle. I dipartimenti finanziari traducono poi il consumo variabile in previsioni di ricavo.
I prezzi per utente racchiudevano queste funzioni in un contratto semplice. L'uso dell'AI le separa. Il settore ha ora bisogno di metriche che restino comprensibili pur riflettendo lavoro, valore e spesa di calcolo.
I prezzi basati sull'utilizzo risolvono un problema e ne creano un altro
I prezzi basati sull'utilizzo allineano i ricavi all'attività, ma trasferiscono il rischio di previsione dal fornitore all'acquirente.
Una metrica di consumo appare equa perché un'organizzazione paga di più quando usa di più. Questo principio si adatta agli agenti che svolgono un numero variabile di attività. Protegge inoltre i fornitori dall'assorbire costi illimitati di modelli e infrastruttura.
La difficoltà sta nello scegliere cosa contare. I token misurano le porzioni di testo che un modello legge e produce. Sono strettamente collegati alla spesa di calcolo, ma hanno poco significato intuitivo per la maggior parte degli acquirenti aziendali.
Le azioni sono più facili da collegare all'attività dei flussi di lavoro. Tuttavia, un'azione può aggiornare un campo, mentre un'altra può cercare in diversi sistemi e generare una risposta dettagliata. Una singola etichetta può nascondere differenze rilevanti di impegno e valore.
I crediti offrono ai fornitori un livello contabile comune per diversi servizi. Possono assegnare pesi di credito differenti a prompt, operazioni degli agenti, traduzione o attività vocali. I clienti ricevono un unico saldo, anche se comprenderne l'esaurimento può richiedere comunque un monitoraggio dettagliato.
Microsoft ha adottato questa strada per diverse esperienze agentiche. La sua documentazione descrive Copilot Credits come l'unità per la fatturazione basata sull'utilizzo nei carichi di lavoro supportati. Gli amministratori ricevono budget, politiche di spesa, report di utilizzo, avvisi e limiti rigidi tramite i controlli dei crediti Copilot.
Questi controlli rivelano la vera esigenza degli acquirenti. Le aziende non hanno semplicemente bisogno di un'unità di fatturazione. Hanno bisogno di una governance che colleghi un agente, un utente, un reparto e un'attività al consumo risultante.
Senza questa visibilità, la sperimentazione può generare una fattura inattesa. Un'implementazione di successo può aumentare l'attività molto più rapidamente di quanto abbia mai fatto il numero di dipendenti. Un flusso di lavoro autonomo può inoltre continuare a utilizzare risorse dopo che una persona ha smesso di supervisionarlo.
I limiti rigidi riducono l'esposizione finanziaria, ma introducono un rischio operativo. Un agente del supporto clienti che raggiunge il proprio limite durante un picco di domanda può fermarsi proprio quando i clienti ne hanno più bisogno. Un limite più permissivo protegge la continuità ma indebolisce la certezza dei costi.
Il routing dei modelli offre una risposta. Le attività più semplici possono usare modelli più piccoli, mentre le richieste difficili ricorrono a sistemi più capaci. Anche la memorizzazione nella cache del contesto ripetuto e la riduzione della cronologia dei prompt non necessaria possono limitare il consumo.
Queste tecniche rendono l’architettura software parte della strategia di pricing. Due fornitori possono offrire interfacce simili sostenendo costi di inferenza molto diversi. Un fornitore con un routing efficiente può offrire capacità più prevedibile o preservare margini più elevati.
Gli acquirenti raramente hanno piena visibilità su queste decisioni interne. Possono vedere crediti scalati da un portafoglio senza sapere quale modello ha gestito ciascun passaggio. Per questo, registri di utilizzo trasparenti contano più di un raffinato elenco di funzionalità AI.
Il pricing ibrido tenta di bilanciare esigenze contrastanti. Un abbonamento base offre accesso, supporto, sicurezza e ricavi prevedibili. Un livello di consumo rileva l’attività degli agenti oltre la capacità inclusa.
HubSpot ha descritto pubblicamente questa direzione quando ha ampliato Breeze Customer Agent tramite crediti. La sua strategia di pricing ibrido combina postazioni in abbonamento con capacità inclusa e consumo aggiuntivo di crediti. L’azienda ha affermato che avrebbe preso in considerazione un trattamento simile per altri agenti AI dopo che utilizzo e risultati fossero diventati coerenti.
Questa sequenza offre una lezione utile. I fornitori hanno bisogno di prove sul comportamento reale prima di definire un contatore duraturo. Stabilire i prezzi troppo presto può legare i ricavi a una misura tecnica che i clienti in seguito rifiutano.
Può anche scoraggiare l’adozione del prodotto. I dipendenti sperimentano meno quando ogni prompt sembra ridurre un saldo visibile. I reparti possono riservare gli agenti a compiti circoscritti, impedendo al fornitore di capire dove il prodotto genera valore.
L’accesso illimitato incoraggia l’esplorazione, ma espone il fornitore a un uso intenso. La fatturazione a consumo protegge il fornitore, ma può generare ansia nei clienti. Nessun contatore elimina questo compromesso.
Il pricing AI di Salesforce illustra questo compromesso. L’azienda supporta licenze utente per un accesso prevedibile dei dipendenti e opzioni a consumo per il lavoro variabile degli agenti. Questa flessibilità può aiutare clienti diversi, ma complica anche confronti e approvvigionamento.
Il risultato assomiglia più all’acquisto di infrastruttura cloud che al SaaS classico. I clienti devono stimare i carichi di lavoro, monitorare l’utilizzo e gestire i limiti. Gli acquirenti di software hanno sempre più bisogno di competenze che un tempo appartenevano soprattutto ai team operativi cloud.
Questo non significa che la fatturazione a token diventerà il volto pubblico di ogni prodotto AI. Le unità tecniche di risorse sono spesso troppo lontane dal valore aziendale. I fornitori continueranno a tradurle in azioni, crediti, attività o pacchetti di capacità.
I modelli duraturi renderanno questa traduzione comprensibile. I clienti devono capire quale comportamento genera spesa, e i fornitori devono recuperare i propri costi variabili. Un’unità di prezzo che soddisfa solo una delle due parti non resterà stabile.
Il pricing AI basato sui risultati ha un problema di misurazione
Far pagare i risultati sembra l’approccio più vicino al valore, ma ogni contratto deve definire a chi attribuire il merito dell’esito.
Il pricing basato sui risultati chiede ai clienti di pagare quando il software completa un lavoro di valore. Un agente di supporto potrebbe essere misurato in base alle conversazioni risolte. Un agente di vendita potrebbe essere misurato in base ai lead qualificati o alle ricerche completate.
Questa struttura migliora la proposta commerciale. I clienti non pagano semplicemente perché un’AI ha provato a fare qualcosa. I fornitori generano ricavi quando il sistema raggiunge un risultato concordato.
Intercom utilizza questo approccio per il suo Fin AI Agent. Le sue regole sui risultati pubblicate distinguono le risoluzioni riuscite e i passaggi configurati dalle procedure non riuscite o dalle escalation dirette. L’azienda afferma di addebitare al massimo una volta per conversazione.
Sembra più chiaro del consumo di token. Un responsabile del supporto comprende più facilmente un caso risolto rispetto a un conteggio di prompt. L’unità è inoltre più vicina al valore aziendale che il cliente desiderava.
Tuttavia, l’apparente semplicità dipende da una definizione dettagliata. L’AI ha risolto il problema o il cliente ha semplicemente smesso di rispondere? Un passaggio dovrebbe contare quando l’agente ha raccolto informazioni ma un umano ha completato il lavoro?
La risposta influenza sia la fattura sia la metrica di prodotto. I fornitori hanno un incentivo a classificare più interazioni come riuscite. I clienti hanno un incentivo a contestare i casi che hanno prodotto risposte incomplete o di bassa qualità.
I flussi di lavoro complessi creano dispute di attribuzione più difficili. Un agente di vendita può identificare un potenziale cliente, arricchire i dati di contatto, preparare un messaggio di outreach e fissare una riunione. La transazione finale può dipendere anche dalla notorietà del marchio, dal prezzo, dalla negoziazione umana e dalle condizioni di mercato.
Addebitare la vendita conclusa si allineerebbe al valore finale, ma il software non controlla ogni fattore che contribuisce al risultato. Addebitare l’attività di outreach è più semplice da misurare, pur premiando l’attività anziché la qualità. Addebitare un lead qualificato si colloca tra questi estremi.
McKinsey ha riportato un esempio rivelatore nella sua ricerca di settore. Un fornitore di vendite AI-native offriva sia accordi basati sull’attività sia accordi basati sui risultati. Il novanta per cento dei clienti ha scelto il pricing basato sull’attività, perché la previsione della spesa e le definizioni di qualificazione diventavano difficili durante le trattative.
Questo risultato mette in discussione un’assunzione diffusa. Gli acquirenti non scelgono sempre la metrica più vicina al valore economico. Possono preferire un’unità meno perfetta quando crea un budget più chiaro e meno dispute contrattuali.
Il pricing basato sui risultati modifica anche il rischio del fornitore. Il provider assorbe il costo dei tentativi non riusciti quando solo i risultati completati generano ricavi. Questo può incoraggiare prodotti migliori, ma contesti clienti difficili possono produrre confronti ingiusti.
Dati scadenti, integrazioni incomplete o policy restrittive possono ridurre il tasso di successo di un agente. Il fornitore può sostenere la spesa anche quando è stata la configurazione del cliente a causare il fallimento. I contratti necessitano quindi di regole per prerequisiti, eccezioni e responsabilità condivisa.
La qualità introduce un altro problema. Una risoluzione può essere tecnicamente completa lasciando comunque il cliente insoddisfatto. Un lead può soddisfare criteri formali ma avere scarso potenziale commerciale. Gli eventi di fatturazione binari non possono catturare ogni dimensione del valore.
Le aziende hanno quindi bisogno di prove verificabili. I clienti dovrebbero poter esaminare l’interazione, le azioni dell’agente, lo stato finale e qualsiasi intervento umano. Le procedure di contestazione devono esistere prima che l’automazione raggiunga grandi volumi.
Ecco perché il pricing basato sui risultati richiede più di una modifica a una pagina di checkout. I fornitori hanno bisogno di sistemi di valutazione, telemetria rivolta ai clienti, strumenti interni di revisione e definizioni coerenti. I team commerciali e legali devono spiegare tali definizioni prima della distribuzione.
Gli agenti possono anche modificare il proprio comportamento in risposta alla metrica. Un sistema ottimizzato per il tasso di risoluzione potrebbe evitare escalation appropriate. Un agente di vendita premiato per i lead qualificati potrebbe favorire standard di qualificazione generosi.
Le organizzazioni umane affrontano già questo problema con gli obiettivi di performance. L’AI rende più facile scalare rapidamente il comportamento. Incentivi inadeguati possono quindi generare migliaia di risultati di bassa qualità prima che qualcuno riveda la regola.
La fatturazione basata sui risultati resta interessante per flussi di lavoro delimitati. Il supporto clienti, l’elaborazione dei documenti e la verifica standardizzata possono produrre stati di completamento osservabili. La ricerca aperta o il lavoro strategico offrono meno chiari punti di conclusione.
La conclusione scettica non è che il pricing basato sui risultati fallirà. È che il modello funziona solo quando il successo è tempestivo, attribuibile e verificabile automaticamente. Molte attività aziendali non soddisfano ancora tutte e tre le condizioni.
Il pricing basato sull’utilizzo e quello basato sui risultati coesisteranno di conseguenza. L’utilizzo è adatto al lavoro informatico variabile che i fornitori possono misurare con coerenza. I risultati sono adatti a compiti standardizzati per i quali clienti e fornitori possono concordare il successo.
I contratti per postazione resteranno accanto a essi per l’accesso umano e la collaborazione. Il mercato nel breve termine conterrà più contatori, non un unico successore universale. Questa complessità è il prezzo da pagare per adattarsi alle diverse forme di lavoro AI.
Cosa devono mostrare i prossimi cicli di risultati SaaS
Il modello vincente collegherà l’adozione dell’AI a ricavi duraturi senza rendere impossibile prevedere i budget dei clienti o i margini dei fornitori.
Il primo segnale da osservare è il consumo AI dichiarato nei principali report sugli utili del software. I fornitori devono mostrare se i clienti passano dalle prove a carichi di lavoro ricorrenti in produzione. I soli annunci di contratti non possono dimostrare questo andamento.
Gli investitori dovrebbero cercare prove che il consumo cresca dopo la distribuzione senza generare una forte volatilità dei ricavi. Dovrebbero inoltre confrontare la crescita dei ricavi AI con le spese infrastrutturali. L’aumento dell’utilizzo conta meno quando il costo per servirlo aumenta altrettanto rapidamente.
I commenti sul margine lordo meritano particolare attenzione. Gli agenti AI effettuano più inferenza e uso di strumenti rispetto alle funzionalità software convenzionali. I fornitori devono dimostrare che routing, selezione dei modelli, caching e pricing compensino tali spese nel tempo.
Il secondo segnale è la semplificazione del pricing. Salesforce, Microsoft e i loro concorrenti offrono attualmente postazioni, crediti, azioni, capacità e unità di risultato sovrapposti. I clienti riveleranno quali contatori sopravvivono attraverso il comportamento nei rinnovi.
Un modello stabile dovrebbe diventare più semplice da spiegare dopo diversi cicli contrattuali. Le definizioni dovrebbero convergere, il monitoraggio dovrebbe migliorare e le eccezioni dovrebbero diminuire. Una complessità persistente suggerirebbe che i fornitori non hanno ancora trovato una misura di valore affidabile.
I rinnovi forniranno prove migliori delle nuove vendite. Un cliente può accettare condizioni poco familiari durante un pilota limitato. Diventa più esigente dopo aver osservato modelli reali di consumo e confrontato le fatture con i risultati aziendali.
Osservate se gli acquirenti ampliano gli impegni, impongono limiti più rigorosi o tornano a licenze prevedibili. L’espansione rafforzerebbe la tesi del pricing a consumo. Un ritorno verso l’accesso fisso mostrerebbe che la certezza di budget continua a prevalere su un preciso allineamento all’utilizzo.
Il terzo segnale è la qualità della verifica dei risultati. Le piattaforme di supporto offrono un primo banco di prova perché le conversazioni producono stati osservabili. I loro tassi di contestazione, i modelli di escalation e la fidelizzazione dei clienti possono mostrare se le misure automatizzate di successo rimangono credibili.
I fornitori devono divulgare informazioni sufficienti affinché i clienti possano verificare i risultati. Un’etichetta di risoluzione da scatola nera non sosterrà la fiducia nel lungo periodo. Il record sottostante dovrebbe mostrare cosa ha fatto l’agente, perché si è fermato e se è intervenuta una persona.
Anche gli standard sui risultati potrebbero diventare più dettagliati. I clienti potrebbero richiedere misure separate per completamento, accuratezza, soddisfazione e lavoro umano evitato. Definizioni migliori rafforzerebbero il pricing basato sui risultati, pur rendendo i contratti più complessi.
Questi segnali sono importanti per gli acquirenti quanto per gli investitori. Un’azienda che valuta un prodotto AI dovrebbe modellare il flusso di lavoro prima di confrontare le unità di fatturazione. Deve considerare volume previsto, complessità delle attività, percorsi di fallimento e costo della revisione umana.
I team dovrebbero anche stabilire chi è responsabile della spesa AI. Il procurement può negoziare il contratto, ma i responsabili di prodotto comprendono il volume dei flussi di lavoro. L’ingegneria osserva il comportamento dei modelli, mentre la finanza monitora l’esposizione al budget.
Un sistema di conoscenza condiviso può aiutare questi gruppi a preservare ipotesi, report di utilizzo, risultati delle valutazioni e decisioni di rinnovo. I team che organizzano già il lavoro AI interno possono trarre beneficio da una base di conoscenza AI ricercabile anziché da fogli di calcolo sui prezzi sparsi.
Gli acquirenti dovrebbero evitare di considerare automaticamente preferibile l’unità apparentemente più economica. Un credito può nascondere diverse operazioni, mentre una risoluzione può celare una qualità contestata. La domanda rilevante è se il contatore rifletta un risultato che l’organizzazione può osservare e governare.
I fornitori affrontano una prova correlata. Devono resistere alla tentazione di inventare un vocabolario di fatturazione per ogni nuova funzionalità. Troppe unità incompatibili rendono più difficile il budget tra prodotti e indeboliscono la fiducia dei clienti.
I prezzi dell'AI di Salesforce rendono visibile la transizione del settore perché affiancano diverse opzioni. Questa ampiezza offre flessibilità oggi. Mostra anche che il mercato non ha ancora trovato un sostituto durevole e condiviso per la licenza per utente.
La destinazione più probabile è un contratto a livelli. Una tariffa di piattaforma copre accesso, governance e funzionalità principali. I costi variabili seguono poi l'attività degli agenti, la capacità o i risultati verificati.
Questi contratti preserveranno parte dei ricavi ricorrenti, consentendo al contempo alle aziende software di partecipare al valore dell'automazione. Richiederanno inoltre un monitoraggio migliore rispetto alle licenze tradizionali. La prevedibilità deriverà da controlli e cronologia d'uso, non soltanto dal numero dei dipendenti.
Per gli sviluppatori, il parametro di prezzo influenzerà l'architettura. Ogni tentativo ripetuto, finestra di contesto estesa, chiamata di strumenti e scelta del modello può incidere sulle prestazioni commerciali. La progettazione attenta ai costi diventerà parte della qualità del prodotto.
Per i knowledge worker, il cambiamento determinerà se gli agenti resteranno ampiamente disponibili o saranno razionati in modo rigoroso. Un accesso prevedibile favorisce l'uso abituale. Controlli aggressivi sui consumi possono spingere i dipendenti a riservare gli agenti ai compiti con ritorni evidenti.
Per gli acquirenti enterprise, il prossimo passo è concreto. Selezionate un flusso di lavoro in produzione, misuratene volume e percorsi di errore, quindi confrontate licenze per utente, consumo e risultati usando le stesse evidenze. Quale parametro resta comprensibile dopo l'uso reale e quale parte si assume il rischio quando l'AI svolge più lavoro del previsto?



