Arriviamo al succo della questione. Se avviate un side project che:
- non fate per beneficenza;
- non è open-source;
- magari è un Saas;
… prima o poi vorrete vedere anche un po’ di $oldi. Sì ma… come fare? Ovviamente non ho una formula magica, però posso raccontarvi come ho fatto io con la mia app.
Gratuito è bello (all’inizio)
Al momento del lancio, ho deciso di rilasciare la prima versione dell’app… gratuitamente! Soprattutto in un primo momento, una volta fissato un budget mensile da spendere (oltre il quale non si deve andare) ai soldi non bisogna neanche pensarci.
In ogni caso, non fate gli stronzi: se pensate di metterla a pagamento, prima o poi, evitate di dire “free forever” o cose del genere. Gli utenti non scordano mai nulla.
Un’app gratuita attira più utenti molto più facilmente. Inoltre, nel mio caso specifico mi sono preso un paio di giorni in più del previsto per perfezionare la pagina sull’app store e tutti i dettagli per la review. La cosa mi ha permesso di beccarmi una feature (nella sezione delle app appena lanciate) in home page, dal giorno del lancio per circa 10/12 giorni.
Questo mi ha permesso di arrivare ad avere circa 70/100 installazioni al giorno.
La domanda sorge spontanea: se sono utenti gratuiti, a cosa ci serve averne così tanti?
Semplice: mi serve per avere più dati possibile. Dieci utenti che usano la vostra applicazione sono già una discreta fonte di feedback, ma cento utenti lo sono ancora di più. Mille utenti, magari in industry diverse, con abitudini diverse in paesi diversi, ancora meglio: diventano praticamente statistica.
Mettere l’applicazione gratuita per un primo periodo consente di avere più dati a disposizione per capire quali sono davvero i problemi che un utente vuole vedere risolti. Permette di comprendere le abitudini e le necessità. Senza contare che il pricing model perfetto per la propria app lo trovate solo studiandone i dati.
Ed ecco un bell’articolo che all’epoca mi aiutò con i pricing model.
Ah, stavo quasi per scordarmi… soprattutto all’inizio del suo ciclo di vita, un’app sarà piena di bug. Fidatevi, piena. Non importa quanti test avete scritto: ci sarà sempre quell’utente che riuscirà a sorprendervi. Sistemare un’app gratuita, soprattutto se è un side project e non potete dedicarci un’infinità di tempo, richiede una minore pressione psicologica.
Prima di andare avanti, ecco cosa uso per monitorare e studiare l’app ed i miei utenti:
- Prometheus / Grafana per statistiche sull’andamento dell’infrastruttura;
- Amplitude per le metriche di prodotto (quanti utenti attivi questa settimana? quanti cambi prezzi fatti questo mese? quanti trial passano a pagamento?)
- Fullstory per studiare come gli utenti usano l’app (ai limiti del creepy, qui vi consiglio di evitare di dire agli utenti che potete VEDERE come usano l’app… limitatevi ad un “dai nostri log risulta che…”);
Se ve lo state chiedendo: Prometheus e Grafana sono open-source, Amplitude e Fullstory hanno dei piani free più che soddisfacenti. Non avete scuse… misurate!
Comunica in modo MOLTO chiaro la messa a pagamento
Ho messo l’app a pagamento circa un anno dopo il lancio. Avrei voluto farlo prima ma la pandemia ha rallentato le cose. Ed in tutta onestà, far passare un’app da gratuita a pagamento mentre un sacco di altri servizi prevedevano piani gratuiti in pandemia mi è sembrata un po’ una bastardata.
Se la comunicazione viene fatta per bene, convertire un utente da free a paid è la cosa più semplice e meno costosa. Si tratta di un utente che già conosce i benefici a cui va incontro. Se il prezzo è equo, probabilmente non avrà problemi a pagare il costo di un’iscrizione.
Qui mi limito a qualche consiglio sparso:
- comunicate tanto ed in modo chiaro: ho messo l’app a pagamento nel gennaio 2021 ma ho iniziato a comunicare del cambio da Ottobre 2020. L’ho fatto sia tramite notifiche in-app che via mail. Nelle mail mandate, sia prima che dopo il lancio, ho incluso dei codici per riscattare degli sconti, per premiare “chi c’era da prima”;
- non comunicate con i vostri utenti solo per chiedere dei soldi! Raccontate ai vostri utenti della nuova feature che avete rilasciato, oppure chiedete un loro parere su cosa si può migliorare! C’è stato qualche disservizio pesante? Chiedete scusa, fate sapere loro che state facendo di tutto per sistemarlo e che per loro ci siete;
- fissate un prezzo che sembra giusto per l’utente ma soprattutto giusto per voi: voi sapete che costi avete, così come sapete che programmi sono in ballo per il vostro side project. Con Ahia ho volutamente proposto un prezzo più alto della concorrenza. In primis perché ho provato tutte le altre app e non mi hanno convinto come performance, e poi perché… beh, è sempre più popolare abbassare un prezzo troppo alto che alzarne uno troppo basso. Per la cronaca, non ho avuto bisogno di abbassarlo ed è stata una bella conferma del valore del progetto;
- non puntate alla quantità a tutti i costi: preferireste 100 utenti che vi portano 2000 euro al mese in tutto, o 2000 utenti che vi portano la stessa cifra? 2000 utenti aprono molti più ticket all’assistenza rispetto a 100, richiedono più infrastruttura… ci siamo capiti, no? 😉
Qualche numero
Dato che in tanti me l’hanno chiesto, ecco qualche numero sulla gestione dell’app:
- nel momento in cui scrivo ho circa 150 clienti paganti, ogni abbonamento costa $14.99/mese mentre l’annuale costa $149.99/anno (il classicone di dodici mesi al prezzo di dieci se fai l’annuale);
- al momento della messa a pagamento ero arrivato a circa 2000 installazioni attive. Partendo dai dati d’uso dell’applicazione (quelli di prodotto su Amplitude) avevo preventivato un passaggio del 10%. Sono comunque soddisfatto calcolando che per il marketing non ho speso un euro fin quando l’app è stata gratuita, nonostante potesse andare meglio;
- il 90% degli utenti ha un piano mensile, il 10% un piano annuale;
- il tempo relativo alla gestione dei ticket è variabile, ma in media non supera la mezz’ora al giorno (dal lunedì al venerdì);
- a proposito di marketing, per ora evito le campagne pubblicitarie sull’app store di Shopify (costano davvero tanto, ne farò solo nei periodi più “caldi”, come quello del black friday). Al momento preferisco fare piccole partnership con microinfluencer del settore, che creano contenuti ad-hoc che nel corso del tempo aumentano “le strade che portano alla mia app”;
L’importanza del supporto utenti
Una delle cose che ho imparato durante la mia esperienza in AdEspresso è l’importanza fondamentale del supporto ai propri utenti. Non è solo questione di rispondere, è questione di esserci.
- è importante per chi fornisce supporto perché si impara tantissimo del rapportarsi con l’utente finale e si riesce a capire meglio quali sono i pain point su cui lavorare per migliorare l’app;
- è importante per chi il supporto lo riceve perché, fidatevi, è molto più frustrante essere ignorati che spendere 100€ di subscription per qualcosa. Le review negative che ho ottenuto (a parte da quei pochi che non avevano letto le mail di cambio del pricing model) sono arrivate da alcuni negozi a cui, purtroppo, in alcuni casi non sono riuscito a rispondere in tempo;
Il supporto deve essere il più efficiente possibile, nei limiti di quelle che ovviamente sono le nostre possibilità:
- quando l’app era ancora gratuita, ho cercato di rispondere ad ogni ticket del supporto entro uno/due giorni lavorativi;
- quando ho messo l’app a pagamento, ho iniziato a dare priorità ai ticket degli utenti paganti, cercando di garantire sempre la risposta entro le 8 ore lavorative;
- ho aperto un account su Zendesk per poter avere un servizio più efficiente per i ticket: migliora di molto il flusso rispetto alla classica mail ed il piano base (per un operatore) costa 60 euro all’anno. Praticamente niente;
Altro consiglio non richiesto: decidete un registro linguistico da tenere con i vostri clienti e rimanete su quella traccia costantemente. Non mentite mai ai vostri utenti, se avete un bug chiedete scusa e sistemateglielo il prima possibile (più di una volta questa cosa mi ha fruttato una review a 5 stelle).
Sotto questo punto di vista, un ringraziamento speciale va ad una delle mie migliori amiche, Ioanna, che si è offerta di darmi una mano nell’affrontare i clienti più incalzanti ed in alcuni momenti particolarmente pesanti. Senza di lei certe giornate sarebbero state molto più pesanti.
Se il bug non dipende da voi, spiegateglielo con pazienza e particolari ma senza scendere nel tecnico. Anche qui: i clienti non sono sviluppatori ma non sono degli stupidi, hanno un business e vogliono farlo funzionare. Oltre la reazione emotiva del momento, sono persone quasi sempre ragionevoli.
Poi, certo, c’è anche la maleducazione. Quella non perdonatela mai: non abbassate la testa, non state chiedendo l’elemosina.
Lesson(s) Learned:
- rilasciare il proprio prodotto gratuitamente permette di avere più dati a disposizione, anche e soprattutto per capire i propri utenti e quale pricing model usare al momento giusto. Un periodo di rodaggio “gratuito” non fa male, anche per i bug;
- comunicare nel modo più chiaro possibile il passaggio da free a paid è fondamentale, può portare dentro utenti già fidelizzati ad un costo praticamente nullo ed evita tante incomprensioni (oltre alle review negative);
- cercare di dare importanza al supporto utenti in ogni fase, dando la priorità ad una comunicazione chiara e sincera. Bonus per chi tratta il cliente come un essere senziente e non una mucca da mungere;
