Ogni anno, da sessanta a novanta giorni prima del rinnovo, arriva la stessa lettera. Il prezzo è salito. Il mix di prodotti è cambiato. C'è un nuovo tier di agenti che dovrebbe considerare. La conversazione è inquadrata come una discussione di prezzo. La maggior parte dei revenue leader tratta la lettera come il colpo di pistola di partenza. Non lo è. Quando la lettera arriva, la negoziazione è in gran parte finita, la leva doveva essere costruita nei novanta giorni prima, e quasi nessuno la costruisce. Questo è l'audit che nessuno vuole fare, ed è l'unico che muove in modo significativo il numero del rinnovo.
Perché conta proprio adesso
Il pricing Salesforce è diventato più difficile, non più facile, da leggere. Jason Lemkin di SaaStr l'ha documentato in dollari l'anno scorso, il suo team ha tagliato gli utenti umani Salesforce da dieci+ a due, eppure il loro conto annuale è salito di circa l'83% perché i loro AI agent ora usano la piattaforma molto più di quanto gli umani abbiano mai fatto (SaaStr, 2026). La riga del seat-count non è più l'unica riga che conta. Licenze Service, tier di piattaforma di integrazione, add-on sandbox, seat community e capacità agent siedono tutti sulla stessa fattura, e la maggior parte di essi non viene mai ri-scoped tra i rinnovi. Lo sconto negoziabile sul solo prezzo è piccolo. Lo sconto negoziabile rimuovendo intere linee di prodotto non lo è.
Il problema della lettera di rinnovo
La lettera di rinnovo è una conversazione di prezzo by design. Cita un uplift percentuale sul contratto dell'anno scorso, fa riferimento a qualche nuovo SKU e chiede una firma entro una finestra fissa. La conversazione che invita è stretta: quanto dell'uplift può il vendor restituire. Quella più ampia, quale scope stiamo pagando, e quale scope ci serve ancora, è quella che il vendor preferirebbe Lei non avesse. L'audit pre-rinnovo la forza.
La diagnostica è semplice. Guardi il contratto dell'anno scorso riga per riga: licenze sales, licenze service, licenze platform, tier di piattaforma di integrazione, tier sandbox, tier community, capacità agent, premier support. Per ogni riga, risponda a due domande, chi sta usando questo, e cosa cambierebbe se lo tagliassimo a metà. Se non conosce la risposta a nessuna delle due, quella riga è candidata per la pila d'audit.
Tre categorie di seat, attivi, passivi, ghost
L'audit dei seat Salesforce divide le licenze utente in tre bucket. I bucket contano perché la mossa di negoziazione è diversa per ognuno.
Seat attivi
Loggati negli ultimi trenta giorni, hanno usato una funzionalità core, legati a un ruolo nominato su un organigramma attuale. Sono i seat che tiene. Il conteggio attivo è ciò a cui ancora il prossimo contratto.
Seat passivi
Loggati negli ultimi novanta giorni ma a malapena. Comportamento read-only, vista occasionale di dashboard, nessuna creazione o edit di record. Spesso sono seat exec o finance che potrebbero essere fatti scendere a una platform license, una read-only license, o rimossi del tutto senza impatto operativo. La maggior parte delle istanze in mid-stage porta tra il quindici e il trenta percento di passivi.
Seat ghost
Nessun login in novanta giorni, oppure assegnati a un ex-dipendente, oppure assegnati a un utente sandbox mai deprovisionato. Si tagliano. Il numero ghost è la voce più facile dell'audit e quella in cui il team più spesso si sorprende. Un audit serio su un'istanza Salesforce brownfield trova regolarmente tassi di ghost a nord del dieci percento del seat count pagato.
La piattaforma di integrazione e il calcolo del cost-of-staying
Il tier di piattaforma di integrazione adiacente a Salesforce è la singola leva più grande dell'audit e la sua decisione più rinviata. Il pattern è coerente: un team ha comprato il tier due o tre anni fa per risolvere una specifica integrazione: un handoff ERP, un sync di billing, una pipe verso il data warehouse, e l'integrazione è stata costruita e silenziosamente ritirata, sostituita da un iPaaS più economico, oppure mai finita. La riga è rimasta sul contratto perché nessuno possedeva la domanda se dovesse esserci.
La diagnostica giusta è un calcolo del cost-of-staying. Elenchi ogni integrazione attiva sulla piattaforma. Per ognuna, documenti cosa fa, chi ne dipende, e cosa costerebbe migrarla a un'alternativa più snella, un bundle operations HubSpot, un flow Zapier, un'integrazione serverless. Se il costo di migrazione su tutte le integrazioni attive è significativamente inferiore al tier di piattaforma del prossimo anno, la piattaforma è candidata al sunset.
Il playbook di audit pre-rinnovo a 90 giorni
L'audit è semplice nella forma e implacabile nella disciplina. Il team che dice «lo guarderemo prima del rinnovo» non lo fa mai. Il team che mette una finestra di novanta giorni in calendario sì.
Tre workstream girano in parallelo. Primo, l'audit dei seat: tirare i log di login, classificare ogni licenza utente contro il frame attivo / passivo / ghost, nominare ogni decisione di downgrade o cancellazione. Secondo, l'audit dei prodotti: ogni prodotto non-seat sul contratto viene mappato per owner e use case. Terzo, l'audit di integrazione, ogni pipe, ogni consumer di API, ogni add-on di sandbox. L'output è un singolo foglio di calcolo che sta in uno schermo e Le dice esattamente quale scope vuole il prossimo anno, indipendentemente dal prezzo.
Quando usare l'audit come minaccia di switch (e quando no)
L'audit è leva di per sé. L'audit più un'alternativa credibile è più leva. L'audit più una minaccia di switch vuota è meno leva dell'audit da solo, nel momento in cui l'account team del vendor capisce che la minaccia è performativa, la posizione collassa.
Il test onesto: eseguirebbe davvero la migrazione quest'anno se il rinnovo tornasse invariato. Se sì: una migrazione HubSpot, Microsoft Dynamics o Pipedrive è genuinamente scoped, costed e in roadmap, allora nominarla nella conversazione di rinnovo è giusto. Se no, nomini l'audit e lasci che l'audit faccia il lavoro. Il pezzo fondazionale di Harvard Business Review sulla negoziazione con fornitori potenti fa lo stesso punto in linguaggio diverso, la leva che sopravvive a una controparte sofisticata è quella che può davvero esercitare (HBR, 2015). Bluffare con un account team che ha condotto mille di queste conversazioni è una mossa perdente.
Pattern dal campo
Una società di wealth management DACH è entrata in un ciclo di rinnovo affrontando un aumento di circa cinquanta euro per seat. L'istinto era spingere indietro sul numero per-seat. Abbiamo eseguito invece l'audit pre-rinnovo. L'audit ha fatto emergere un tier di piattaforma di integrazione che portava una singola integrazione da diciotto mesi, sostituita internamente da una pipe più snella e mai deprovisionata. Ha fatto emergere due licenze service in cui nessun umano si era loggato in novanta+ giorni. Ha fatto emergere un tier customer-community, prezzato per utente registrato, che si era silenziosamente gonfiato man mano che il portale di support cresceva, un cambio SKU base di experience-cloud lo avrebbe ri-prezzato a una frazione. Nessuno di questi era un numero da titolo da solo. Sommati, erano più grandi dell'uplift proposto. Il contratto rinegoziato è atterrato sotto il numero dell'anno precedente, non sopra. La conversazione era su scope, non prezzo. L'audit era la leva.
Risoluzione, il playbook pre-rinnovo
Per qualunque team che si avvii a un rinnovo Salesforce nei prossimi due trimestri, il playbook è lo stesso:
- Apra la finestra dei novanta giorni. Metta l'audit in calendario prima che arrivi la lettera di rinnovo. Dopo la lettera è il momento sbagliato, il vendor controlla la timeline da lì.
- Tiri i log di login e classifichi ogni licenza utente. Attivo, passivo, ghost. Metta un nome su ogni decisione di downgrade o cancellazione. Il numero ghost da solo di solito ripaga l'audit.
- Mappi per owner ogni linea di prodotto non-seat. Licenze service, licenze platform, tier sandbox, premier support, seat community, capacità agent. Ogni riga riceve un owner e uno use case. Le righe senza nessuno dei due sono candidate alla rimozione.
- Esegua il calcolo cost-of-staying della piattaforma di integrazione. Elenchi ogni integrazione attiva, costi ogni alternativa di migrazione, decida se il tier di piattaforma è un sunset.
- Decida onestamente la questione dello switch. O committa una migrazione credibile in roadmap o non ne nomini una. Non bluffi con un account team sofisticato.
- Mandi la richiesta post-audit per iscritto. Una controproposta specifica, riga per riga, che nomina lo scope che vuole, i seat che tiene e i prodotti che rimuove. La conversazione di sconto del vendor viene inquadrata contro il Suo scope, non il loro.
- Rifaccia l'audit annualmente. Le istanze brownfield accumulano licenze allo stesso modo in cui accumulano proprietà personalizzate: silenziosamente, tra i rinnovi.
Se fa queste sette cose, la conversazione di rinnovo è breve e lo sconto è reale. Se le salta, lo sconto è quello che l'account team decide di darLe, che è lo sconto già prezzato dalla lettera di rinnovo.
Dove entra in gioco Checkpoint
Gli audit di licenze Salesforce sono la maggior parte del lavoro su stack ereditati che eseguiamo a Checkpoint. Gli audit pre-rinnovo sono scoped, riga per riga, e consegnati con una controproposta scritta. Se la Sua finestra di rinnovo è dentro i prossimi due trimestri, l'audit è la conversazione che vale la pena avere adesso.
Fonti
- Lemkin, Jason. The AI agent seat problem is real (Salesforce spend up 83% year over year). SaaStr, 2026. saastr.com
- Paranikas et al. How to negotiate with powerful suppliers. Harvard Business Review, luglio–agosto 2015. hbr.org