L'unico indicatore SaaS che sopravvive quando il mercato si fa duro
C'è un momento nel ciclo di vita di qualsiasi azienda di software in abbonamento in cui il cruscotto delle metriche inizia a sembrare un sintomo e non uno strumento. Utenti attivi giornalieri, tasso di apertura delle funzionalità, tempo di sessione, adozione dei moduli, NPS trimestrale. Si misura tutto. Tutto viene presentato in verde. Eppure, i contratti non vengono rinnovati.
Questo disallineamento tra attività e valore non è nuovo, ma non viene nemmeno corretto alla velocità che la pressione del mercato richiede. In un momento in cui gli acquirenti aziendali applicano un esame reale a ogni voce del budget tecnologico, la domanda che molti fornitori di software evitano di porsi con onestà è se i propri clienti stiano effettivamente guadagnando denaro grazie alla loro piattaforma, oppure stiano semplicemente utilizzando uno strumento che nessuno ha avuto il tempo di cancellare.
David Pickard, direttore globale di Phonexa, ha pubblicato di recente sul Forbes Technology Council una tesi che riassume questo disallineamento con una domanda di autovalutazione: se fossi il tuo stesso cliente, useresti il tuo software? La provocazione è efficace perché la diagnosi che la sorregge è precisa. Il settore SaaS ha costruito una cultura delle metriche di attività che funziona bene per le roadmap interne e le presentazioni agli investitori, ma che ha una correlazione sempre più debole con l'esperienza economica del cliente.
Quando la metrica del successo è interna
Il problema non è misurare. È cosa si sceglie di misurare e perché.
Le metriche di vanità — utenti attivi giornalieri, volume di accessi, numero di funzionalità adottate — hanno una funzione legittima nelle fasi iniziali di un prodotto: indicano se il software viene utilizzato, se l'onboarding funziona, se c'è un engagement sufficiente a giustificare un ciclo di raccolta feedback. L'errore si verifica quando quelle metriche migrano al centro del cruscotto esecutivo senza aver effettuato la transizione verso metriche di risultato economico.
Un cliente può generare un pattern di utilizzo elevato e allo stesso tempo guadagnare meno denaro rispetto a prima di implementare la piattaforma. Il software gli consuma tempo di configurazione, richiede integrazioni che il suo team non padroneggia, produce report che nessuno sa interpretare correttamente. Il tasso di retention appare sano per mesi perché i processi di cancellazione sono lenti e l'inerzia organizzativa è potente. Ma il contratto non viene rinnovato, e quando occorre spiegare il perché, la risposta non si trova nel cruscotto delle metriche interne.
Questo ha una conseguenza meno ovvia: i team di prodotto iniziano a ottimizzare in funzione di ciò che viene misurato. Se l'indicatore di successo è l'adozione delle funzionalità, si aggiungono funzionalità. Se è il tempo di sessione, si progettano flussi che trattengono l'utente all'interno della piattaforma anche quando non è necessario. Se è il NPS, si gestisce la percezione nel momento dell'indagine. L'ottimizzazione verso metriche di attività produce prodotti più complessi e clienti con un ritorno reale inferiore. Non per cattiva intenzione, ma perché l'architettura degli incentivi punta in una direzione diversa da quella di cui il cliente ha bisogno.
L'argomento di Pickard su quello che lui chiama "vanity development" — costruire funzionalità non guidate dai bisogni dei clienti, bensì dalle tendenze del mercato, dalla pressione competitiva o dall'affinità tecnologica interna — descrive esattamente questo meccanismo. Il risultato è una piattaforma che accumula strati di complessità senza che nessuno di essi sposti in modo dimostrabile i ricavi, l'efficienza o la riduzione dei costi del cliente.
La struttura degli incentivi che nessuno audita
Dietro alla proliferazione delle metriche di vanità non c'è ingenuità. C'è una struttura di incentivi che le produce in modo sistematico e che opera su almeno tre livelli simultaneamente.
Il primo è il ciclo di finanziamento. I round di capitali nelle fasi iniziali e intermedie di un'azienda SaaS sono stati storicamente legati a metriche di crescita degli utenti, tasso di crescita dei ricavi ricorrenti mensili e proiezioni di espansione del mercato. Quelle metriche sono rilevabili con dati di attività. Il ritorno economico del cliente, al contrario, è più lento da misurare, richiede accesso a dati che il cliente non condivide sempre e non appare in modo nitido in un pitch deck di Serie B. La conseguenza è prevedibile: i team ottimizzano per gli indicatori che muovono il prezzo del prossimo round, non necessariamente per quelli che riflettono il valore consegnato.
Il secondo livello è la struttura dei team di Customer Success. Per anni, questa funzione è stata progettata come supporto tecnico-relazionale: risolvere problemi di implementazione, rispondere ai ticket, gestire l'onboarding. In quel modello, l'indicatore di prestazione del team era la soddisfazione del cliente e il tasso di retention, non l'espansione dei ricavi del cliente. Ciò crea un team ben posizionato per rilevare attriti ma privo di strumenti e mandato per quantificare l'impatto finanziario della piattaforma sul business del cliente.
Il terzo livello — e il più resistente al cambiamento — è la distanza tra il team di prodotto e il cliente che opera nel quotidiano. Le decisioni di roadmap si alimentano di interviste agli utenti, analisi del comportamento all'interno del prodotto e benchmarking competitivo. Raramente si alimentano dei bilanci del cliente, delle sue metriche di efficienza operativa o di una valutazione onesta di se la piattaforma abbia ridotto il suo costo per transazione o aumentato il suo tasso di conversione. La distanza produce funzionalità che risolvono problemi percepiti ma non problemi economici.
Pickard indica come soluzione a questo quello che descrive come "vanillificare" i requisiti: quando un cliente richiede una funzionalità specifica, il team di prodotto deve generalizzare quella richiesta affinché si ridimensioni verso altri segmenti e sia sufficientemente flessibile per casi d'uso futuri. Il principio è corretto, ma c'è una condizione preliminare che l'argomento non risolve direttamente: per sapere se una funzionalità generalizzata crea valore, è necessario avere una definizione operativa di cosa significhi valore per il cliente. Senza quella definizione, la generalizzazione può produrre complessità allo stesso modo in cui lo fa la copia dei concorrenti.
Il ritorno del cliente come indicatore finanziario della salute del fornitore
Esiste una ragione strutturale per cui il ritorno del cliente finisce per essere il miglior indicatore anticipatore della salute finanziaria del fornitore SaaS, e vale la pena renderla esplicita.
I modelli di business in abbonamento dipendono da due variabili: la retention dei ricavi esistenti e l'espansione all'interno della base clienti attuale. La Net Revenue Retention (NRR), uno degli indicatori più monitorati nel settore, misura esattamente questo: se i ricavi provenienti dai clienti attivi crescono, si mantengono o si contraggono dopo aver incorporato cancellazioni, downgrade ed espansioni. Una NRR superiore al 100% indica che la base clienti esistente sta espandendo il proprio utilizzo, il che tende a essere l'indicatore di crescita più efficiente perché evita il costo di acquisizione di nuovi clienti.
Quel numero non si sostiene senza un ritorno economico dimostrabile per il cliente. Un cliente che non sta generando ricavi incrementali, risparmiando costi o guadagnando efficienza operativa attraverso la piattaforma non ha una ragione economica per espandere il proprio contratto. Può rinnovare per inerzia durante uno o due cicli, ma la logica di espansione — che è ciò che fa superare alla NRR la soglia del 100% — richiede che il cliente abbia collegato il software a un risultato di business positivo.
La catena causale è quindi precisa: ritorno del cliente → retention dei contratti → espansione della spesa → NRR sana → valutazione del fornitore. Misurare unicamente gli anelli intermedi di quella catena — retention ed espansione — senza verificare l'anello iniziale produce un'illusione di solidità che il mercato corregge nel successivo ciclo di rinnovi.
Pickard punta nella stessa direzione quando osserva che nei modelli di ricavi basati sull'utilizzo, la crescita della spesa del cliente sulla piattaforma dovrebbe essere un sintomo del fatto che quel cliente sta generando più ricavi attraverso il sistema. Se il cliente raddoppia la sua spesa sulla piattaforma, il suo guadagno dovrebbe crescere di un multiplo maggiore. Se ciò non accade, il modello non sta consegnando valore: sta catturando una porzione crescente di un ricavo che non sta crescendo.
I servizi gestiti che l'articolo menziona funzionano come un acceleratore di quel ciclo quando sono ben progettati: riducono il tempo tra l'implementazione e il ritorno dimostrabile, il che a sua volta accelera la decisione del cliente di espandere l'utilizzo. Il rischio — che l'articolo non tematizza esplicitamente ma che è reale — è che i servizi gestiti diventino un cerotto per piattaforme che non sono sufficientemente intuitive o che richiedono troppo intervento per produrre risultati. In quel caso, il livello di servizi sovvenziona indefinitamente una complessità che il prodotto avrebbe dovuto eliminare.
Ciò che precede il numero visibile
L'argomento di centralizzare tutto sul ritorno del cliente è corretto nella sua diagnosi, ma la sua implementazione affronta una condizione preliminare che poche aziende SaaS hanno risolto: come misurare quel ritorno in modo sistematico e non aneddotico.
I casi di successo dei clienti esistono in tutte le aziende di software. Sono il carburante delle presentazioni di vendita e delle pagine di testimonianze. Il problema è che un caso di successo narrato a posteriori ha valore commerciale ma scarsa utilità operativa. Non dice cosa ha prodotto il ritorno, in quali condizioni si replica, né quali variabili lo hanno reso possibile in quel cliente e non in altri con profili simili.
Costruire una metodologia di misurazione del ritorno del cliente che sia comparabile tra segmenti, che si aggiorni in tempo reale e che alimenti le decisioni di prodotto e di Customer Success richiede accesso a dati che il cliente spesso non condivide per impostazione predefinita. Richiede che la piattaforma sia strumentata per catturare non solo il comportamento all'interno del sistema, ma i suoi effetti downstream sugli indicatori di business del cliente. E richiede che i team di prodotto e di Customer Success parlino lo stesso linguaggio economico degli acquirenti esecutivi che valutano il rinnovo.
La frizione che nessuno sta contando nel dibattito sulle metriche di vanità è precisamente questa: il problema non è che le aziende SaaS non vogliano misurare il ritorno del cliente. È che l'infrastruttura dei dati, gli accordi di scambio di informazioni con i clienti e la capacità analitica per convertire quei dati in segnali di roadmap non sono costruiti nella maggior parte dei fornitori di medie dimensioni. Cambiare il cruscotto esecutivo è semplice. Cambiare l'architettura informativa che alimenta quel cruscotto è il lavoro che richiede anni.
Questo non invalida la tesi di Pickard. La rafforza. Ma colloca il vero problema dove deve essere: non nella scelta di cosa misurare, ma nella capacità di misurare ciò che conta in modo sistematico. Le aziende SaaS che riusciranno a costruire quella capacità per prime — inclusi gli accordi con i clienti che abilitano la visibilità sui loro risultati — avranno un vantaggio che non si replica semplicemente cambiando il nome di un indicatore nel report trimestrale.
Il cruscotto delle metriche non cambia se la piattaforma non sta generando un ritorno dimostrabile. Ma l'architettura che produce quel cruscotto — e i team capaci di interpretarlo con onestà — è l'investimento che separa i fornitori che sopravvivono alle rinegoziazioni di budget da quelli che non arrivano al prossimo ciclo di rinnovo.
