Quando un SaaS introduce più piani, è facile risolvere ogni differenza con una condizione nel codice: se il cliente ha il piano avanzato, mostra questa opzione; altrimenti, nascondila. All’inizio l’approccio funziona, ma diventa fragile quando arrivano cambi di abbonamento, componenti aggiuntivi, prove temporanee ed eccezioni commerciali. La domanda non è più quale pulsante mostrare, ma quali capacità ha un account, chi può utilizzarle e a quali condizioni.
Un modello chiaro separa le decisioni commerciali dalle regole applicate dal prodotto. In questo modo è più semplice modificare l’offerta, verificare una transizione e mantenere un comportamento coerente nell’interfaccia, nell’API e nelle attività interne. Questa guida propone criteri per progettare tale modello e capire quando quello attuale ha bisogno di essere semplificato.
Il piano non dovrebbe essere una regola diretta dell’applicazione
Un piano è un modo per presentare e vendere un’offerta. Può raggruppare capacità e limiti, ma non dovrebbe diventare l’unica fonte di verità per decidere ogni operazione. Se l’applicazione verifica ripetutamente se un account appartiene al piano «Pro», la logica resta legata a nomi commerciali che possono cambiare anche quando la capacità continua a esistere.
È preferibile tradurre l’abbonamento in un insieme esplicito di diritti effettivi. Per esempio, un account può avere l’esportazione abilitata, un numero massimo di progetti e l’accesso a un’integrazione. Il prodotto valuta questi diritti, non l’etichetta di marketing. Così, cambiare il nome o la composizione di un piano non obbliga a rivedere tutte le parti dell’applicazione che lo citano.
Questo disaccoppiamento facilita anche le offerte non standard. Due account con piani diversi possono condividere una capacità; un account con lo stesso piano di un altro può avere un componente aggiuntivo sottoscritto. La soluzione non consiste nell’aggiungere altri rami condizionali, ma nel rappresentare esplicitamente il risultato di cui il prodotto ha bisogno.
Separare funzionalità, limiti e permessi
Prima di scegliere un’architettura, distingui quattro concetti che spesso vengono confusi:
- Piano: offerta commerciale assegnata a un account, con condizioni e periodo di validità.
- Funzionalità abilitata: capacità disponibile per l’account, come esportare dati o usare un’integrazione.
- Limite di utilizzo: quantità massima o quota applicabile a una risorsa, per esempio utenti, progetti o spazio di archiviazione.
- Permesso: azione che una persona specifica può eseguire all’interno dell’account, in base al suo ruolo o alla configurazione.
Una funzionalità può essere inclusa nell’abbonamento e, comunque, non essere consentita a tutti gli utenti. Al contrario, un utente può avere il permesso di gestire progetti, ma l’account potrebbe aver raggiunto il proprio limite. Per autorizzare un’operazione può quindi essere necessario verificare il diritto dell’account, il permesso individuale e lo stato della risorsa.
Definisci anche il significato di ogni limite. «Fino a 10 progetti» può riferirsi ai progetti attivi, a quelli creati durante un periodo oppure al numero totale di progetti esistenti. Chiarisci quando si azzera il contatore, cosa accade al raggiungimento del massimo e come vengono trattati i dati che superano già il limite dopo un cambio di piano. Se queste regole restano implicite, il team finirà per prendere decisioni diverse nelle schermate e nei processi.
Dove rappresentare le regole
La collocazione più adatta dipende dalla complessità e da chi deve poter modificare l’offerta. Per un prodotto con pochi piani e cambiamenti poco frequenti, può bastare una configurazione versionata insieme all’applicazione. È una soluzione semplice da rivedere e testare, purché le regole non vengano ripetute in molti punti.
Se il team commerciale deve poter modificare la composizione dei piani senza distribuire nuovo codice, può essere opportuno archiviare il catalogo e le assegnazioni in una fonte dati amministrabile. Questo introduce nuove responsabilità: controllare chi può modificare la configurazione, convalidare le modifiche e conservare uno storico che permetta di spiegare quali regole fossero in vigore in una certa data. La modifica dinamica non è un vantaggio se ogni cambiamento può lasciare gli account in uno stato incoerente.
Una terza possibilità consiste nel registrare prodotti, periodi e componenti aggiuntivi nel sistema di abbonamento, mentre il prodotto mantiene una rappresentazione interna dei diritti effettivi. È meglio evitare che ogni schermata interroghi direttamente il sistema di fatturazione: oltre a creare un accoppiamento tra componenti, questo può produrre risultati diversi in caso di ritardi o problemi di sincronizzazione. Stabilisci qual è la fonte di verità per ciascun dato e come si aggiorna l’altra.
In tutte queste soluzioni, evita di implementare in modo indipendente lo stesso significato nell’interfaccia, nell’API e nei processi in background. Centralizza la valutazione degli accessi in un livello riutilizzabile e documentane il contratto. L’interfaccia può avvisare l’utente che un’opzione non è disponibile, ma l’API deve convalidare di nuovo l’operazione: nascondere un controllo non equivale ad autorizzare l’accesso.
Gestire modifiche, transizioni e componenti aggiuntivi
Un abbonamento cambia nel tempo. Può esserci una data futura di decorrenza, un periodo di prova, un rinnovo in attesa o una cancellazione programmata. Salva lo stato e le date rilevanti e definisci quali diritti si applicano prima e dopo la transizione. Evita di basare la decisione soltanto su un’etichetta attuale se è già stata concordata una modifica futura per l’account.
Per ogni cambio di piano, rispondi in modo esplicito alle seguenti domande:
- Quando entra in vigore la modifica: subito, alla fine del periodo o in una data concordata?
- Che cosa accade alle risorse che superano il nuovo limite?
- Si impedisce la creazione di elementi, si limitano altre azioni o è necessario un intervento?
- Come viene comunicato lo stato all’amministratore dell’account?
Non eliminare né modificare dati automaticamente come reazione generica a una riduzione del piano. Decidi quali azioni vengono limitate e come si può ripristinare il normale funzionamento. Per una funzionalità acquistata separatamente, rappresenta il componente aggiuntivo come un diritto indipendente, con un proprio periodo di validità quando necessario; così non occorre creare un nuovo piano per ogni combinazione.
Eccezioni per cliente: esplicite, circoscritte e verificabili
Le eccezioni possono essere legittime: un progetto pilota, una compensazione o un’esigenza contrattuale. Il rischio emerge quando vengono implementate come condizioni speciali sparse nel codice o come modifiche manuali senza un responsabile né una data di revisione.
Registra per ogni eccezione il cliente o l’account interessato, la capacità o il limite modificato, il motivo, chi l’ha approvata e il periodo di validità. Se è temporanea, definisci fin dall’inizio come scade e quale comportamento segue alla scadenza. Un’eccezione senza data può diventare parte permanente del prodotto senza che nessuno ricordi perché esiste.
Prima di aggiungere un’altra eccezione, verifica se rivela un’esigenza di prodotto più generale. Se più account hanno bisogno dello stesso componente aggiuntivo, potrebbe essere meglio offrirlo come opzione. Se una regola dipende da un obbligo contrattuale, mantienila identificabile e separata dalla logica generale. Il criterio è che il team possa spiegare e verificare lo stato di un account senza cercare condizioni sparse.
Test, diagnosi e migrazione
Testa non solo l’assegnazione iniziale, ma anche i cambiamenti di stato e i loro effetti. Come minimo, copri una capacità abilitata e una non disponibile, un limite appena prima e subito dopo il raggiungimento, un cambio di piano in attesa, un componente aggiuntivo in scadenza e un’eccezione scaduta. Verifica la stessa decisione nell’interfaccia, nell’API e nei processi interni che creano o modificano risorse.
Registra informazioni sufficienti per diagnosticare perché un’operazione è stata consentita o rifiutata: account, diritto valutato, limite pertinente ed esito. Evita di includere dati sensibili non necessari. Il messaggio comprensibile per l’utente può essere diverso dal dettaglio tecnico, ma entrambi dovrebbero corrispondere alla stessa decisione effettiva.
Ci sono segnali che indicano la necessità di rivedere il modello: numerosi controlli basati sul nome del piano, discrepanze tra schermate e API, eccezioni senza responsabile, limiti di cui nessuno sa precisare il significato o modifiche commerciali che richiedono interventi in molte aree del prodotto. Per migrare, fai prima un inventario delle regole esistenti; definisci poi diritti e limiti con nomi stabili, centralizza la valutazione e confrontane i risultati con il comportamento attuale su casi rappresentativi. Migra per fasi e conserva un meccanismo che rilevi le differenze prima di rimuovere la logica precedente.
La scelta pratica è modellare ciò che il prodotto consente, non il nome che il team commerciale dà a ciascuna offerta. Piani e fatturazione possono cambiare; capacità effettive, limiti e permessi devono restare comprensibili, verificabili e coerenti in tutti i punti di accesso.