ARTICOLO

Prova gratuita scritta male nel software: cosa controllare

SaaSsubscriptionstesting

Se vendete un abbonamento con una prova gratuita, dentro il software c'è una regola che decide quanto può usare chi sta provando. Sembra una riga da niente. Nel mio caso quella riga era scritta pensando agli abbonati, e una prova a cavallo di due mesi valeva il doppio.

Ve lo racconto perché lo stesso errore, girato al contrario, blocca un cliente a metà prova. E un cliente in prova bloccato non chiama l'assistenza: chiude la pagina e prova il concorrente.

Cosa è successo

Miraviso, l'app che ho costruito per i saloni di parrucchieri, ha una prova gratuita di 14 giorni. Durante la prova c'è un tetto alle anteprime del taglio, perché ogni anteprima ha un costo che pago io.

Per i saloni abbonati il contatore riparte da zero il primo di ogni mese. Ha senso: pagano ogni mese, ogni mese hanno il loro pacchetto. Il problema è che la prova usava la stessa regola. Un salone che iniziava la prova il 25 ottobre la finiva l'8 novembre. Il primo novembre il contatore ripartiva, e quel salone aveva due pacchetti pieni invece di uno.

Nessun cliente l'avrebbe mai segnalato, ovviamente. E nessun controllo lo cercava, perché per gli abbonati la regola era giusta.

Lo stesso errore, nell'altro verso

A me costava un po' di margine. Ma una regola sulla prova scritta male può fare danni peggiori, e ho rischiato di farne qualcuno anch'io mentre la correggevo.

Perché nessuno se ne accorge

Le regole commerciali nel software si scrivono una volta, all'inizio, quando c'è un solo tipo di cliente. Poi arrivano la prova, lo sconto di lancio, l'account demo, il piano annuale. Ognuno ha bisogno di una regola un po' diversa, e spesso eredita quella che c'era già.

Il guaio sta tutto in una parola che sembra ovvia. Per me era «il periodo». Per l'abbonato voleva dire il mese di fatturazione. Per chi era in prova doveva voler dire i 14 giorni della prova. Il software usava la stessa parola per due cose diverse.

Questi errori si vedono solo in giorni precisi: a fine mese, a febbraio, quando un cliente passa dalla prova all'abbonamento. Se nessuno prova proprio quei giorni, restano lì per mesi.

Cosa controllare nel vostro software

Non serve leggere il codice. Basta sedersi mezz'ora con chi l'ha scritto e fare queste prove insieme.

Come l'ho sistemata

Prima di toccare la regola ho scritto una prova automatica che riproduceva il problema: una prova iniziata a fine ottobre, un po' di anteprime, poi il calendario spostato ai primi di novembre. Il contatore doveva restare dov'era. Ne ho scritta subito un'altra per gli abbonati, che diceva il contrario: il primo del mese si riparte. Così non rischiavo di sistemare la prova rompendo l'abbonamento.

Poi ho cambiato la regola: per chi è in prova il conto parte dal primo giorno e arriva all'ultimo, senza azzerarsi. L'uso già fatto da chi era a metà prova è rimasto nel conto, quindi nessuno ha visto il suo numero cambiare dalla sera alla mattina. Gli account dimostrativi hanno tenuto il conteggio mensile, apposta. E nel pannello, per chi è in prova, adesso c'è scritto «nella prova» invece di «nel mese».

Una statistica interna che uso solo io conta ancora per mese. Non decide niente per i clienti e l'ho segnata nelle note del progetto. Ho preferito lasciarla così piuttosto che allargare la modifica.

Se volete vedere come è fatto Miraviso nel complesso, c'è la scheda del progetto. Se invece vendete abbonamenti o servizi in prova e volete controllare che le regole nel vostro software dicano quello che avete deciso, è un lavoro che possiamo fare insieme: si parte da una chiamata gratuita di 30 minuti.

← Tutti gli articoli