Gå til indhold

Freemium, gratis prøveperiode eller betaling fra dag 1?

Freemium vs gratis prøveperiode eller betaling fra dag 1: hvad hver model kræver teknisk, og hvad der typisk passer til en dansk B2B-SaaS.

Af

Freelance full-stack udvikler

Udgivet
Læsetid
11 min.
Indhold i indlægget8

Valget mellem freemium og gratis prøveperiode handler om hvad brugeren får gratis, og hvor længe. Til en ny dansk B2B-SaaS anbefaler jeg betaling fra dag 1 til de første kunder og en tidsbegrænset prøveperiode uden krav om betalingskort, når produktet skal kunne sælge sig selv. Freemium kræver mange brugere og lave omkostninger pr. gratis bruger, og det har de færreste nye produkter på et lille marked.

Jeg er udvikler, ikke prisrådgiver. Vinklen her er derfor hvad hver model kræver at bygge og drive, og hvordan det passer til den måde danske virksomheder køber software på.

Den korte version: tre modeller side om side

Freemium, gratis prøveperiode og betaling fra dag 1 sammenlignet
FreemiumGratis prøveperiodeBetaling fra dag 1
Hvad er gratisEn begrænset plan uden tidsgrænseHele eller det meste af produktet i en periode, typisk 14-30 dageIntet, eller en demo eller en pengene-tilbage-garanti
Hvornår kunden betalerNår en grænse rammes, eller behovet vokserNår perioden udløberFør eller ved første login
Det du skal byggePlaner, grænser i backenden, forbrugsmåling og opgraderingsflowUdløbslogik, påmindelser og låsning eller nedgradering af kontoenBetaling eller fakturering, ofte manuel oprettelse af kunder
Krav til forretningenMange brugere og lav driftspris pr. gratis brugerAt brugeren kan se værdien inden for periodenAt kunden stoler på dig, typisk efter en demo
Største risikoGratis brugere der aldrig betaler, men koster drift og supportPerioden udløber før brugeren er kommet i gangFærre tilmeldinger og længere salgsforløb
Passer typisk tilVærktøjer der deles med kolleger og kunder og dermed spredesDe fleste selvbetjente B2B-produkterFå, store kunder og produkter der kræver opsætning

Min tommelfingerregel: Kan en ny bruger selv komme i gang og se værdien inden for en uge eller to, så brug en prøveperiode. Kræver produktet opsætning, dataimport eller en chefs godkendelse, så tag betaling fra dag 1 og giv en demo i stedet. Freemium overvejer jeg først når produktet har bevist at folk bruger det og inviterer andre.

Modellen er kun én af beslutningerne før lancering. Står du tidligere i processen, så start med min guide til at bygge en SaaS fra idé til betalende kunder. Skal du først vælge selve prisstrukturen, fx pr. bruger eller efter forbrug, så læs gennemgangen af de 9 SaaS-prismodeller.

Hvad hver model kræver teknisk

De tre modeller ligner hinanden på en prisside, men de er meget forskellige at bygge.

Freemium: grænser overalt i produktet

En gratis plan uden tidsgrænse betyder at produktet hele tiden skal vide hvad den enkelte konto må. Det kræver:

  • En oversigt over hvad hver plan giver adgang til: antal brugere, projekter, lagerplads, eksport og integrationer.
  • Grænser der håndhæves i backenden, ikke kun ved at skjule en knap. Ellers kan alle med lidt teknisk snilde omgå dem.
  • Måling af forbrug, hvis grænsen fx er 100 fakturaer om måneden eller et antal AI-kald.
  • Et opgraderingsflow der hvor brugeren rammer en grænse, så det er let at betale i præcis det øjeblik behovet opstår.
  • Værn mod misbrug, fx et firma der opretter fem gratis konti for at slippe for at betale.
  • Oprydning i inaktive gratis konti. Oplysninger om brugerne er persondata, og efter GDPR må du ikke gemme dem længere end nødvendigt.

Dertil kommer driften. Hver gratis bruger koster hosting, mails, support og måske betaling pr. kald til en AI-tjeneste, og så bliver en gratis plan hurtigt dyr.

Gratis prøveperiode: logik omkring en udløbsdato

En prøveperiode er teknisk overskuelig, fordi den grundlæggende er én dato pr. konto. Det svære er det der sker omkring datoen:

  • Hvad sker der ved udløb? Kontoen kan låses, blive skrivebeskyttet eller falde ned på en gratis plan. Skrivebeskyttet er ofte det venligste valg, fordi brugeren ikke mister sit arbejde.
  • Påmindelser før udløb og status inde i produktet, så brugeren kan se hvor mange dage der er tilbage.
  • Mulighed for at forlænge prøveperioden manuelt, når en kunde beder om mere tid. Det sker ofte i B2B.
  • Sletning af data fra prøvekonti der aldrig blev til kunder, efter en frist du har skrevet i din privatlivspolitik.

Bruger du Laravel, har Cashier-pakken til Stripe begge varianter indbygget: prøveperiode med betalingskort ved tilmelding og en generisk prøveperiode, hvor der blot gemmes en udløbsdato på brugeren. I Stripe vælger du hvad der sker, hvis en prøveperiode udløber uden kort: annullere abonnementet, sætte det på pause eller sende en faktura. Stripe kan også sende en besked til dit system nogle dage før udløb, som du kan bruge til din egen påmindelse. Det står i Stripes dokumentation om prøveperioder.

Betaling fra dag 1: mindst kode, mest salg

Her er der ingen prøvelogik at bygge. Kunden betaler, og kontoen åbnes. Til gengæld flytter arbejdet over i salg og administration:

  • En demo eller et demomiljø med eksempeldata, så kunden kan se produktet før købet.
  • Betaling via faktura med betalingsfrist, ikke kun kort. Offentlige kunder skal typisk have en elektronisk faktura med EAN-nummer.
  • Oprettelse af kunder fra din side i starten i stedet for selvbetjent tilmelding. Det er fint ved ti kunder og bliver tungt ved hundrede.
  • Eventuelt en pengene-tilbage-garanti, som kræver at du kan refundere og lukke en konto pænt.

Det er også den model hvor du lærer mest af færrest brugere, fordi folk der har betalt, giver mere ærlig feedback. Hvordan du sætter selve betalingen op, inklusive faktura og danske betalingsmetoder, gennemgår jeg i sammenligningen af Stripe, Paddle og danske betalingsløsninger.

Prøveperiode med eller uden betalingskort?

Med kort ved tilmelding får du færre tilmeldinger, men de er mere seriøse, og betalingen sker automatisk ved udløb. Uden kort får du flere tilmeldinger, men du skal selv arbejde for at gøre dem til kunder med påmindelser, opfølgning og et let sted at betale inde i produktet.

Til danske B2B-kunder hælder jeg mod prøveperioden uden kort, af to grunde. Den der prøver produktet, har ofte ikke firmaets betalingskort. Og mange virksomheder vil hellere betale via faktura end med kort. Et krav om kort stopper dem i døren, selv om de er reelle kunder.

Teknisk er forskellen lille ved tilmelding og stor ved udløb:

  • Med kort trækker Stripe automatisk. Du skal håndtere fejlede betalinger, sende påmindelser og gøre det let at opsige. Kortselskaberne har regler for prøveperioder der går over i betaling, og Stripe beskriver dem i sin guide til regler for prøveperioder. Stripes egne påmindelsesmails sendes 7 dage før udløb, hvis du slår dem til.
  • Uden kort skal du selv bygge vejen fra prøve til betaling, enten et betalingsflow i produktet eller en knap hvor kunden beder om faktura. Og du skal beslutte hvad der sker med kontoen, hvis ingen betaler.

Om prøveperioden konverterer, afhænger mest af om brugeren når frem til værdien. Det handler om onboarding af nye brugere, ikke om betalingskortet.

Hvad passer til B2B i Danmark?

Det meste der er skrevet om freemium og prøveperioder, kommer fra amerikanske virksomheder med mange millioner mulige brugere. Danske B2B-produkter har andre vilkår:

  • Markedet er lille. En dansk niche tæller ofte hundreder eller få tusinde mulige kunder. Freemium lever af at en lille andel af rigtig mange brugere betaler, og den regning går sjældent op med så få.
  • Brugeren er ikke altid køberen. Den der prøver produktet, skal ofte have en chef eller bogholderen til at godkende købet, så det skal være let at invitere kolleger.
  • Mange vil betale via faktura. Har du kun kortbetaling, mister du en del af dem der gerne vil købe.
  • Mange købere forventer at tale med et menneske. Når hver kunde er meget værd, er en personlig demo en billig investering.
  • Spørgsmål om data kommer tidligt. Også prøvekonti indeholder persondata, og danske virksomheder spørger ofte hvor data ligger.

Min anbefaling er derfor at starte med betaling fra dag 1 til de første kunder, gerne via faktura og efter en demo. Når produktet er modent nok til at nye brugere kan komme i gang uden din hjælp, tilføjer du en prøveperiode på 14-30 dage uden kort og følger personligt op på dem der tilmelder sig. Sælger du til større virksomheder med årlige aftaler, kan du springe prøveperioden helt over.

Hvornår hver model ikke passer

Her er de situationer hvor jeg ville vælge noget andet.

Når freemium er et dårligt valg

  • Hver bruger koster dig penge i drift, fx ved AI, sms eller store filer.
  • Der findes kun få hundrede eller få tusinde mulige kunder.
  • Produktet er først nyttigt når hele virksomheden bruger det, så en enkelt gratis bruger aldrig når frem til værdien.
  • Du har ikke tid eller kapital til at vente på at gratis brugere bliver til betalende.
  • Den gratis plan dækker hele behovet for de fleste. Så har du lavet et gratis produkt med en betalt udgave som ingen har brug for.

Når en prøveperiode er et dårligt valg

  • Opsætningen tager længere end perioden, fx en integration til økonomisystemet eller import af mange data.
  • Værdien viser sig først efter måneder, fx ved årsopgørelser eller sæsonarbejde.
  • Kunderne køber via udbud eller en indkøbsafdeling, hvor en prøveperiode ikke ændrer beslutningen.

Når betaling fra dag 1 er et dårligt valg

  • Ingen kender dig endnu, og prisen er lav. Så er et salgsmøde for dyrt i forhold til hvad kunden betaler, og brugeren vil hellere prøve selv.
  • Alle dine konkurrenter tilbyder prøveperiode, og dit produkt er ikke tydeligt bedre.
  • Du er stadig ved at finde ud af hvad produktet skal være og har brug for mange brugere at lære af. Så kan en lukket gratis beta være bedre.

Mellemveje der ofte virker bedre

Du er ikke låst til én af de tre rene modeller. De her kombinationer fungerer ofte bedre i praksis:

  • Omvendt prøveperiode: nye brugere får fuld adgang i en periode og falder derefter ned på en gratis plan i stedet for at blive låst ude. De mister ikke deres arbejde, men savner de betalte funktioner. Det kræver både prøvelogik og planer med grænser, så det er den dyreste variant at bygge.
  • Betalt pilotforløb: kunden betaler en reduceret pris i en til tre måneder med opsætning inkluderet. Det passer til større kunder, og Stripe understøtter i dag også betalte prøveperioder med en lav introduktionspris.
  • Pengene-tilbage-garanti: betaling fra dag 1, men kunden kan fortryde inden for fx 30 dage. Det fjerner kundens risiko uden at du skal bygge prøvelogik.
  • Prøveperiode med demo: selvbetjent tilmelding med et tilbud om en personlig gennemgang i den første uge.

En fuld freemium-motor med grænser og forbrugsmåling hører sjældent til i første version, ligesom mange af de funktioner din SaaS ikke har brug for ved lancering.

Næste skridt: byg så du kan skifte model senere

Det vigtigste tekniske råd jeg kan give, er at prismodellen ikke må være spredt ud over koden. Hvis knapper, sider og API-kald spørger direkte om brugeren er på prøve, bliver det dyrt at skifte model. Saml i stedet reglerne ét sted:

  1. Én oversigt over planer og hvad hver plan giver adgang til.
  2. Én funktion som resten af koden spørger: må denne konto gøre det her?
  3. Prøveperioden som en status på kontoen, ikke som undtagelser rundt omkring i koden.
  4. Hændelser du kan måle på: tilmelding, første brug af kernefunktionen, ramt grænse, opgradering og udløb.

Så kan du starte med betaling fra dag 1, tilføje en prøveperiode senere og måske en gratis plan efter det, uden at skrive produktet om. Husk de eksisterende kunder når du skifter. Dem der har betalt en bestemt pris, skal typisk beholde den, og det skal systemet kunne håndtere.

Vil du have hjælp til at bygge betaling, prøveperiode og planer ind fra start, kan du se hvordan jeg arbejder med udvikling af SaaS-produkter. Ved større projekter starter jeg med et betalt forprojekt til fast pris, hvor model og omfang bliver afklaret før der skrives kode. Har du endnu ikke talt med mulige kunder, så vent med at bygge, og test idéen manuelt først. Det er billigere end alle tre modeller.

Ofte stillede spørgsmål

Hvor lang skal en gratis prøveperiode være?

Så lang som det tager en typisk bruger at se værdien, plus lidt luft. Til enkle værktøjer er 14 dage ofte nok, mens produkter med opsætning eller dataimport kan have brug for 30 dage. Længere hjælper sjældent, fordi brugerne så udskyder at komme i gang. Mål hvornår dine brugere tager det første vigtige skridt, og sæt perioden efter det.

Hvad skal der ske med data, når en prøveperiode udløber uden køb?

Behold data en kort periode, så brugeren kan vende tilbage og fortsætte, og slet dem derefter automatisk. Fristen, fx 30 eller 90 dage, skal stå i din privatlivspolitik og passe til GDPR's krav om ikke at gemme persondata længere end nødvendigt. Byg sletningen som et planlagt job fra start, så den ikke afhænger af at nogen husker det. Det her er ikke juridisk rådgivning, så få en rådgiver til at se på dine vilkår.

Kan jeg bruge samme model over for private forbrugere?

Ikke uden videre. Over for forbrugere gælder strengere regler for markedsføring af gratis prøveperioder og abonnementer der fortsætter automatisk, blandt andet om tydelig information om pris, binding og opsigelse. Kortselskabernes krav til påmindelser gælder også. Sælger du til både virksomheder og forbrugere, så få en jurist til at gennemgå tilmelding, vilkår og påmindelser før du lancerer.

Hvad koster det at bygge en prøveperiode eller freemium ind?

En simpel prøveperiode med udløbsdato, påmindelser og låsning er en af de mindre opgaver i en SaaS, især med færdige pakker som Laravel Cashier. Freemium er væsentligt større, fordi grænser og forbrugsmåling skal ind i alle dele af produktet og testes, og fordi gratis konti skal ryddes op. Prisen afhænger mest af hvor mange steder i produktet grænserne skal håndhæves.