La qualità di un prodotto SaaS si vede non tanto nel numero di funzionalità offerte, quanto da quanto in modo affidabile il cliente riesce a portare a termine il proprio compito principale. Registrarsi può essere semplice; ciò che conta è ottenere il primo risultato, invitare i colleghi del team e continuare con lo stesso ordine quando l'attività cresce.
Se non ha ancora deciso tra un SaaS già pronto e un software realizzato su misura, può consultare prima il nostro articolo SaaS pronto o software su misura?. Questo articolo è pensato per i team che hanno già deciso di sviluppare un proprio prodotto SaaS.
01Facilitare il raggiungimento del primo valore
Un utente non dovrebbe dover imparare tutte le impostazioni al primo accesso. In un prodotto per la gestione di appuntamenti, ad esempio, il primo obiettivo è creare un calendario e registrare un appuntamento. Ordini i passaggi di configurazione in funzione di questo risultato. Nelle schermate vuote, spieghi il passaggio successivo; non presenti dati di esempio come se fossero registrazioni reali. Valuti il successo non solo in base al numero di registrazioni, ma alle operazioni principali effettivamente completate.
02Separare il piano dai permessi
Il piano definisce le funzionalità acquistate dall'organizzazione; il ruolo definisce quali operazioni può compiere una persona. Nascondere una voce di menu dei report non basta: anche l'operazione corrispondente deve essere verificata lato server. I diritti del team all'interno della stessa organizzazione e la separazione dei dati tra organizzazioni diverse richiedono scenari di test distinti. La guida OWASP sull'autorizzazione è una risorsa tecnica utile per questi controlli.
03Progettare i momenti critici dell'abbonamento
Non solo l'upgrade, ma anche il downgrade del piano, i ritardi di pagamento, la fine del periodo di prova e la disdetta fanno parte del prodotto. Spieghi in anticipo cosa succede quando l'utente supera il limite del piano. Renda visibile la regola che verrà applicata, invece di eliminare silenziosamente i dati. Poiché le notifiche del fornitore di pagamento possono arrivare più volte, il flusso deve essere progettato in modo che lo stesso evento non generi un secondo diritto o un secondo addebito.
04Includere il periodo successivo al lancio nell'ambito
Fare un backup e poter effettivamente ripristinare non sono la stessa cosa. Pianifichi una prova di ripristino, il monitoraggio degli errori e una migrazione di versione controllata. In fase di collaudo, ponga queste domande: i dati delle diverse organizzazioni sono protetti tra loro, il limite del piano viene realmente applicato, un'operazione fallita può essere ritentata in sicurezza? Un buon SaaS risponde a queste domande mostrando le schermate e fornendo prove di test. Nel nostro servizio di sviluppo SaaS affrontiamo queste domande come parte dell'ambito di consegna.
05Checklist rapida
- Il nuovo utente riesce a completare il proprio compito principale già nella prima sessione?
- I limiti del piano e i permessi dei ruoli sono verificati separatamente lato server?
- I dati di un'organizzazione non sono visibili a un'altra organizzazione in nessuna schermata, ricerca o esportazione?
- È documentato cosa succede in caso di downgrade del piano, ritardo di pagamento o disdetta?
- Una notifica di pagamento ripetuta non genera un secondo diritto o un secondo addebito?
- Il ripristino da backup è stato testato almeno una volta?
Scritto da
Il team Paradigma7
Prodotto, ingegneria e operations
Siamo un team con base a Ankara che sviluppa software per l'Europa. Qui non c'è teoria: sono i processi che usiamo davvero nei progetti dei clienti.
Chi siamo