AL+

RO EN

Scrieți-ne

Cât să dureze perioada de probă gratuită pentru un SaaS B2B

14 sau 30 de zile? Pentru un produs vândut firmelor, perioada de probă trebuie să acopere timpul până la primul rezultat real. Măsurați-l înainte de a alege.

. De . Afaceri cu software

Read this article in English

O perioadă de probă gratuită de 14 zile se poate încheia înainte ca o firmă să fi avut timp să evalueze produsul. O firmă care cumpără software are adesea nevoie de câteva săptămâni ca să facă integrarea, să importe datele sau să obțină aprobarea pentru achiziție. Perioada de probă ar trebui să dureze până când clientul ajunge la primul rezultat real. Dacă produsul nu îl poate duce acolo în 14 zile pe un client care chiar vrea să-l încerce, de obicei e nevoie de mai multă muncă la onboarding, nu de un termen mai lung. Iar dacă întârzierea vine din calendarul clientului, nu din produs, un termen fix nu e unealta potrivită.

Ce a aflat Keygen în 2024

Pe 3 mai 2024, Zeke Gabrielse, fondatorul Keygen, un API pentru licențierea software-ului, a publicat o analiză a propriilor cifre (în engleză). Pornise cu un trial gratuit de 14 zile. Clienții nu reușeau să integreze un API de licențiere în aplicațiile lor în acest interval, așa că a început să ofere prelungiri. În următorii ani, scrie el, majoritatea clienților care au ajuns să plătească ceruseră o prelungire, iar rata de conversie era mai mare în cazul lor.

La început cerea un card înregistrat înainte să prelungească trialul, apoi a renunțat la acest pas pentru că schimbul de mesaje era obositor. După spusele lui, conversia nu a scăzut, deci cardul nu explica diferența.

Cifra care conta era ceea ce el numește „time-to-convert”: zilele de la înscriere până la prima plată. Mediana lui era de 41 de zile. Percentila 90 era de 130 de zile, percentila 95 de 198, iar percentila 99 de 290. Le dădea clienților 14 zile ca să ia o decizie la care clientul plătitor tipic ajungea după șase săptămâni. De fapt, spune el, le cerea să aștepte: până erau gata să citească documentația, până se planifica un proof of concept, până se elibera un programator. Mulți vedeau termenul apropiindu-se, hotărau că nu sunt pregătiți, plecau și nu mai reveneau.

Soluția lui a fost cea de care fondatorii fără finanțare sunt sfătuiți să se ferească: un trial nelimitat, adică un plan gratuit. Gabrielse a raportat o creștere a înscrierilor. Separând clienții care au rămas pe planul gratuit, a constatat că au crescut și înscrierile plătite, că rata de conversie a rămas aceeași și că a dispărut munca manuală cu prelungirile.

Articolul a pornit o discuție lungă pe Hacker News (în engleză) pe 6 mai 2024. Un participant descria o echipă de evaluare a cărei regulă e un minimum de 30 de zile, fără plată și fără funcții tăiate, și pentru care chiar și 30 de zile sunt puține ca să pună sistemul în funcțiune cu propriile date de test. Gabrielse a precizat în discuție că planul lui gratuit are limite, de exemplu 100 de utilizatori activi și 2.000 de cereri API pe zi, deci nu poate susține o aplicație în producție. Presiunea de a plăti apare după ce clientul a făcut efectiv integrarea, nu înainte.

La doi ani distanță, pagina de prețuri Keygen (în engleză) descrie în continuare planul Dev ca pe un plan gratuit limitat, gândit pentru „faza de integrare și dezvoltare”, cu limite stricte care întorc o eroare când sunt atinse, și oferă la cerere un trial de 30 de zile pentru varianta Enterprise găzduită de client. Soluția a rezistat.

Argumentul: termenul trebuie să măsoare rezultatul, nu calendarul

Dezbaterea obișnuită despre durata trialului compară rata de conversie medie pentru 14 și 30 de zile, pe multe firme la un loc. Comparația ascunde tocmai variabila care decide răspunsul: cât îi ia clientului firmei să ajungă în punctul în care poate răspunde la întrebarea „merită să plătesc pentru asta?”. Pentru o aplicație de notițe poate fi o după-amiază. Pentru un API care trebuie legat de procesul de livrare al aplicației sau pentru un program de back-office în care trebuie importate facturile pe un an, pot fi săptămâni.

Un trial care se termină înainte de acel punct nu testează produsul. Testează dacă cumpărătorul a avut, întâmplător, două săptămâni libere. Clienții pe care îi pierde nu sunt neapărat nepotriviți: mulți sunt firme ocupate, cu o nevoie reală și cu alte proiecte la rând.

Așadar durata perioadei de probă e un rezultat, nu un punct de plecare. Măsurați cât le ia clienților care reușesc să ajungă la primul rezultat real și stabiliți durata în funcție de asta. Apoi vedeți cu ce se umplu acele zile.

Timpul de lucru și timpul de așteptare

Aici teza cere atenție, pentru că soluția Keygen nu a fost un onboarding mai bun, ci renunțarea la termen. Ambele răspunsuri sunt corecte, pentru părți diferite ale întârzierii.

Timpul de lucru e cel pe care clientul îl petrece efectiv cu produsul: citește documentația, creează conturi, potrivește câmpurile, scrie prima integrare, importă datele. Aceasta e problema pe care trebuie să o rezolvați. Date de exemplu, un exemplu funcțional în limbajul de programare al clientului, un import care acceptă tabelul pe care îl are deja, o discuție de configurare pentru pasul la care se blochează toată lumea: fiecare scurtează drumul, iar un termen mai lung nu rezolvă niciuna dintre aceste probleme. Dacă un client care se apucă serios de treabă are nevoie de trei săptămâni de muncă până să vadă ceva util, un trial de 30 de zile îi dă doar mai mult timp să se împotmolească.

Timpul de așteptare e intervalul dintre înscriere și momentul în care clientul poate începe: programatorul e pe alt proiect, cel care aprobă bugetul e în concediu, cei de la securitate vor un chestionar completat. Nu îl puteți scurta prin onboarding. Un trial cu termen fix îl penalizează, exact cum a descris Gabrielse. Un plan gratuit cu limite de utilizare sau un trial care începe să curgă de la prima utilizare reală se potrivesc mai bine.

Cele mai multe produse le au pe amândouă. Întrebarea practică e care dintre ele cântărește mai mult la clienții firmei.

Cum îl măsurați într-un produs mic

Nu aveți nevoie de o platformă de analiză. Articolul lui Gabrielse include o interogare Stripe Sigma pentru timpul până la plată. Mai util în completare e timpul până la primul rezultat real, care cere o singură decizie: ce eveniment arată că clientul a obținut ceva concret. Pentru un API de licențiere poate fi prima licență validată din aplicația clientului; pentru un program de facturare, prima factură trimisă unui client adevărat.

Dacă înregistrați evenimentele în PostgreSQL, o interogare de acest fel vă dă distribuția (numele tabelelor și al evenimentului sunt doar exemple):

SELECT
  percentile_cont(0.5) WITHIN GROUP (ORDER BY days) AS p50_days,
  percentile_cont(0.9) WITHIN GROUP (ORDER BY days) AS p90_days
FROM (
  SELECT a.id,
         EXTRACT(EPOCH FROM MIN(e.created_at) - a.created_at) / 86400 AS days
  FROM accounts a
  JOIN events e ON e.account_id = a.id
  WHERE e.name = 'first_production_use'
    AND a.created_at > now() - interval '1 year'
  GROUP BY a.id, a.created_at
) t;

Două precauții. Interogarea numără doar conturile care au ajuns la eveniment, deci descrie clienții care au reușit, nu pe cei pierduți din cauza termenului. Înregistrați și prima acțiune semnificativă după înscriere. Intervalul până la acea acțiune și cel de la acțiune la primul rezultat sunt indicii despre așteptare și evaluare, măsurate în timp calendaristic. Ambele pot include pauze, weekenduri și alte așteptări. Pentru a măsura munca efectivă aveți nevoie de date despre sesiuni sau activitate ori de discuții cu clienții; momentele înregistrate nu o separă singure.

Contraargumentul cel mai puternic

Trialurile scurte au motivele lor. Kyle Poyar descrie compromisul în ghidul său despre reverse trials (în engleză), publicat în Growth Unhinged: produsele cu trial gratuit au adesea o conversie de la gratuit la plătit de două sau trei ori mai mare decât cele freemium, pentru că termenul forțează o decizie, și convertesc mai repede, cu un timp median până la cumpărare care „poate fi de 14 zile”, față de 60 sau 90 la un produs freemium. Pentru o firmă mică ce plătește pentru achiziția de clienți, momentul în care intră banii contează.

Există și obiecția din partea vânzărilor, ridicată în discuția de pe Hacker News: clienții care cer la nesfârșit prelungiri adesea doar se uită prin vitrină, iar trialurile lungi îi lasă să consume suport fără intenția de a cumpăra. Un alt participant a observat un efect de selecție în prima constatare a lui Gabrielse: cei care cer o prelungire sunt deja cei interesați. El a răspuns că afirmația se referea la creșterea conversiei totale atunci când a oferit prelungiri, ceea ce e corect, dar rămâne relatarea unei singure firme, nu un experiment controlat.

Ambele obiecții sunt reale. Niciuna nu justifică însă un termen arbitrar de 14 zile. Un termen creează urgență doar dacă clientul putea lua o decizie înainte de el. Chiar trialul invers descris de Poyar, cu toate funcțiile pentru o perioadă limitată și apoi trecerea pe un plan gratuit, e o metodă de a păstra urgența fără a-l pierde pe cumpărătorul mai lent.

Unde concluzia nu se aplică

Dacă produsul aduce valoare clientului încă din prima sesiune, un trial scurt e în regulă, iar un plan gratuit poate însemna doar venit pierdut. Dacă utilizarea gratuită vă costă bani reali, de exemplu putere de calcul sau suport oferit de oameni, un plan nelimitat are nevoie de limite ferme, altfel devine o subvenție. Iar pentru software vândut câtorva firme mai mari, trialul în regim self-service poate fi cu totul nepotrivit. Un pilot asistat, cu funcționalitățile agreate, o persoană de contact de fiecare parte, criterii de reușită scrise înainte de început și o dată de încheiere legată de aceste criterii, e adesea mai bun pentru ambele părți decât orice termen fix. Asta e valabil mai ales când configurarea implică datele clientului sau un alt sistem, genul de muncă pe care îl presupune de obicei dezvoltarea de software la comandă. Dacă încă decideți ce ar trebui să conțină prima versiune, articolul MVP vs prototype (în engleză) tratează această alegere anterioară.

Concluzia

Nu alegeți 14 sau 30 de zile pentru că așa spune un studiu comparativ. Măsurați cât le ia clienților plătitori să ajungă la primul rezultat real, scurtați partea de lucru printr-un onboarding mai bun și nu lăsați termenul să penalizeze partea de așteptare. Perioada de probă e destul de lungă atunci când un client care chiar vrea produsul poate lua o decizie reală înainte să se termine.

Surse (în engleză)