SaaS-prissætning: 9 prismodeller, og hvordan du vælger

SaaS-prissætning handler om to beslutninger: hvad kunden betaler for, og hvordan prisen vokser når kunden får mere ud af dit produkt. Langt de fleste SaaS-produkter bruger en af 9 prismodeller eller en blanding af dem, fra én fast månedspris over pr. bruger og pr. lokation til ren betaling efter forbrug. Vælg den model der følger det kunden selv opfatter som værdi, og som du kan forklare på én linje.

Indlægget handler om prisen på dit eget produkt, ikke om hvad det koster at få det udviklet. Det har jeg skrevet om i prisguiden til udvikling af en SaaS. Som udvikler ser jeg også hvad hver prismodel kræver af koden, så det får du med undervejs.

Den korte version

Det vigtigste begreb i prissætning er værdimåleren: den enhed prisen følger, fx brugere, lokationer eller transaktioner. Tabellen viser de 9 modeller, hvad kunden betaler for, og hvor tung modellen er at bygge.

Min tommelfingerregel er at starte med fast pris eller 2-3 pakker. Undtagelsen er når dine egne omkostninger stiger direkte med kundens forbrug, fx ved SMS, betalinger eller AI-kald. Så skal forbruget med i prisen fra første dag. Prisen er kun ét af de valg du skal træffe tidligt, og hele forløbet fra idé til betalende kunder står i min guide til at bygge en SaaS.

De enkle modeller: én pris eller faste pakker

De to første modeller er de letteste at forklare, sælge og bygge.

1. Fast pris

Én pris giver adgang til hele produktet, fx 299 kr. om måneden eller 2.990 kr. om året. Der er ingen pakker at sammenligne, så kunden ved præcis hvad det koster.

Modellen passer når dine kunder ligner hinanden og får nogenlunde samme værdi ud af produktet. Problemet opstår når de ikke gør. Den lille kunde synes prisen er for høj, den store betaler for lidt, og du har ingen naturlig måde at tjene mere på kunder der vokser.

Teknisk er fast pris det enkleste du kan vælge. Ét abonnement i Stripe eller Paddle er nok, og de første kunder kan sagtens betale via et betalingslink.

2. Pakker

Kunden vælger mellem to til fire niveauer, typisk med navne som Basis, Pro og Business, hvor hvert niveau har flere funktioner eller højere grænser. Det er en af de mest udbredte modeller i B2B-SaaS, fordi små og store kunder kan betale forskelligt uden at prisen bliver svær at forstå.

Faldgruben er for mange pakker, adskilt på ting kunden ikke tænker over. Jeg anbefaler højst tre pakker, adskilt på én eller to ting kunden faktisk mærker, fx antal projekter eller adgang til integrationer.

Teknisk skal koden vide hvad hver pakke giver adgang til. Læg grænser og adgang i databasen eller i én samlet konfiguration i stedet for at sprede tjek af pakkenavne rundt i koden. Ellers bliver hver prisændring en udviklingsopgave.

Modeller der vokser med kundens størrelse

De næste tre modeller lader prisen stige når kunden bliver større. Forskellen ligger i hvad der tælles.

3. Pr. bruger

Kunden betaler for hver bruger med login, typisk pr. måned. Det er standarden i samarbejdsværktøjer. Intercom tager fx i skrivende stund mellem 29 og 132 dollar pr. bruger om måneden afhængigt af pakken, ifølge Intercoms prisside.

Modellen passer når alle brugere får værdi af produktet, og antallet af brugere følger kundens størrelse.

Bagsiden er at du straffer kunden for at udbrede produktet internt. Kunderne begynder at dele logins, og produkter hvor kun en eller to personer arbejder i systemet, ender med en lav pris uanset hvor meget de bruges.

Teknisk skal du tælle brugere, håndtere invitationer og afregne forholdsmæssigt når en bruger tilføjes midt i en periode. Stripe og Paddle kan håndtere antal på et abonnement, men det er din kode der holder tallet opdateret.

4. Pr. aktiv bruger

Kunden betaler kun for brugere der faktisk har brugt produktet i perioden. Slack er det kendte eksempel: ifølge deres politik for fair afregning regnes et medlem som inaktivt efter 28 dage uden brug, og kunden får en forholdsmæssig kredit for resten af perioden.

Modellen passer når brugen svinger, fx med sæsonansatte eller vikarer, og når kunder holder igen med at invitere kolleger af frygt for regningen.

Til gengæld bliver prisen mindre forudsigelig for begge parter, og "aktiv" skal defineres præcist. Tæller et login, eller skal brugeren have lavet noget? Teknisk skal du registrere aktivitet pr. bruger, beregne forbruget pr. periode og give kreditter eller justere fakturaen. Det er tydeligt tungere at bygge end betaling pr. bruger.

5. Pr. lokation eller enhed

Kunden betaler pr. fysisk enhed: butik, klinik, lager, køretøj, maskine eller lejemål. Et bookingsystem til fysioterapeuter kunne fx koste 600 kr. pr. klinik om måneden uanset antal behandlere, og et system til flådestyring kunne tage betaling pr. køretøj.

Modellen passer når værdien følger de fysiske enheder, og kunderne selv tænker i dem. En ejer med fire butikker ved præcis hvor mange butikker hun har, men næppe hvor mange brugerkonti hun har brug for. Det gør heller ikke noget at personalet deler en skærm ved disken.

Faldgruben er at en lille og en stor lokation betaler det samme. Det kan du løse med størrelsesintervaller, fx op til 5 behandlere og over 5 behandlere. Definér også hvad en lokation er, før nogen spørger om pop-up-butikken tæller med.

Teknisk er modellen enkel hvis lokationer findes i datamodellen fra start, så en kundekonto kan have flere lokationer med hver sine brugere og data. Tilføjer du det senere, er det en større ombygning. Jeg har beskrevet de valg i indlægget om multi-tenant-arkitektur.

Modeller der følger forbruget

De sidste fire modeller kobler prisen til hvad kunden bruger eller opnår. De ligger tættest på dine omkostninger, men er de sværeste at bygge.

6. Forbrugsbaseret

Kunden betaler for det der bliver brugt: transaktioner, sendte SMS'er, gigabyte eller API-kald. Stripe tager ingen månedlig betaling, kun et gebyr pr. betaling: 1,5 % plus 1,80 kr. for standardkort fra EØS, ifølge Stripes danske prisside.

Modellen passer når dine egne omkostninger følger forbruget, og kunderne bruger meget forskellige mængder. Kunden kommer let i gang, fordi der ingen fast udgift er.

Bagsiden er at kunden ikke kan forudsige regningen. Økonomiafdelinger vil ofte have et fast beløb at budgettere med, og et produkt hvor hvert klik koster, kan få medarbejderne til at bruge det mindre.

Teknisk er det den tungeste model. Du skal registrere hver hændelse, lægge forbruget sammen uden at tælle dobbelt, vise forbruget i produktet og sende advarsler ved grænser. Stripe har værktøjer til forbrugsbaseret betaling, men det er stadig din kode der skal levere tallene, og de skal være rigtige hver gang.

7. Grundpris plus forbrug

Kunden betaler et fast månedligt beløb med et forbrug inkluderet og betaler ekstra over grænsen. Det kunne fx være 499 kr. om måneden med 1.000 SMS inkluderet og derefter 0,30 kr. pr. SMS.

For mange B2B-produkter med reelle variable omkostninger er det det bedste kompromis. Kunden får et forudsigeligt budget i en normal måned, og du er dækket ind hvis en kunde bruger ti gange så meget som forventet.

Faldgruben er overraskende regninger. Advar kunden når fx 80 % af det inkluderede forbrug er brugt, så ekstraregningen ikke kommer som et chok. Teknisk kræver modellen den samme måling som ren forbrugsbetaling plus kvoter der nulstilles hver periode og beskeder til kunden.

8. Kreditter

Kunden køber en pulje kreditter på forhånd, og forskellige handlinger bruger forskellige mængder. Modellen er blevet udbredt i AI-produkter. Lovable sælger fx sine pakker efter hvor mange kreditter de indeholder, ikke efter antal brugere, og en enkel opgave koster færre kreditter end en kompleks, ifølge Lovables prisside.

Kreditter passer når hver handling koster dig penge, og omkostningen svinger, som ved kald til AI-modeller. Du får betalingen før du har udgiften og kan ændre hvad en handling koster, uden at ændre selve prisen.

Bagsiden er at kunden har svært ved at vide hvad en kredit er værd, og kreditter der udløber, kan føles som en fælde. Teknisk bygger du i praksis et lille regnskab: en saldo pr. kunde, en log over hver bevægelse, priser pr. handling, udløb og køb af ekstra kreditter. Det skal stemme til sidste øre.

9. Resultatbaseret

Kunden betaler for et målbart resultat, fx en løst supportsag, et booket møde eller en gennemført bestilling. Intercoms AI-agent Fin koster 0,99 dollar pr. såkaldt outcome, og Intercom beskriver præcist hvad der tæller som et, fx at kunden bekræfter at problemet er løst.

Modellen passer når resultatet kan måles entydigt, og kunden ellers ville tøve med at betale for noget nyt og uprøvet. Den er nem at sælge, fordi kunden kun betaler når det virker.

Til gengæld opstår der uenighed om hvad der tæller som et resultat, og din indtægt afhænger af ting du ikke selv styrer. Teknisk skal definitionen kodes præcist, hvert resultat registreres, og du skal kunne dokumentere hver afregning hvis kunden spørger. Det er sjældent det rigtige valg til en første version.

Freemium og prøveperiode er ikke prismodeller

Freemium og gratis prøveperiode bliver ofte nævnt sammen med prismodellerne, men de handler om hvordan kunden kommer ind, ikke om hvad kunden betaler for. Du kan kombinere dem med alle 9 modeller. En gratis pakke med begrænset forbrug er freemium oven på pakker, og 14 dages gratis adgang er en prøveperiode oven på fast pris.

Valget har stor betydning for både omsætning og support, så jeg har gennemgået det for sig i freemium, prøveperiode eller betaling fra dag ét.

Sådan vælger du prismodel

Prismodellen er en forretningsbeslutning. Gå disse seks trin igennem før du bygger noget:

1. Find værdimåleren. Spørg fem kunder eller potentielle kunder hvad der vokser hos dem når dit produkt hjælper mere: medarbejdere, lokationer, ordrer eller sager. Det tal er din bedste kandidat til at bære prisen.
2. Regn dine variable omkostninger igennem. Koster hver kundehandling dig penge, fx SMS, AI-kald eller lagring, skal prisen følge forbruget. Ellers kan én stor kunde koste dig mere end den betaler.
3. Tænk på hvem der godkender regningen. Sælger du til virksomheder med en indkøbsproces, vil de have et fast beløb at godkende. Ren forbrugsbetaling kan stoppe et salg der ellers var på plads.
4. Vælg den enkleste model der dækker trin 1-3. Test den ved at skrive prisen på én linje. Kan du ikke det, er modellen for kompliceret til din første version.
5. Sælg før du bygger. De første kunder kan betale via et betalingslink eller en manuel faktura, mens du lærer hvad de vil betale for. Flere planer og rabatkoder hører til de funktioner du kan udskyde ved lancering.
6. Sæt en dato for at kigge på prisen igen. Den første pris er et kvalificeret gæt. Se på den igen efter 3-6 måneder eller når du har 20-30 betalende kunder, alt efter hvad der kommer først.

Byg prisen så den kan ændres

Din første pris er næsten aldrig din endelige. Det koster lidt ekstra at forberede koden på det, og det sparer dig for en ombygning senere. Det er de fire ting jeg anbefaler at have med fra start:

• Planer, grænser og adgang ligger i databasen eller i én konfiguration, så en prisændring ikke kræver en ny udgivelse af koden.
• Hvad kunden har adgang til, er adskilt fra hvordan der betales. Så kan du skifte betalingsudbyder eller give en kunde en særaftale uden at ændre produktet.
• Datamodellen kan have flere prisversioner samtidig, så eksisterende kunder kan beholde deres gamle pris når du hæver den for nye.
• Forbruget bliver målt fra første dag, også det du ikke tager betaling for endnu. Så har du tal at træffe beslutningen på, den dag du vil ændre modellen.

Moms er den sidste brik. Sælger du til kunder i andre EU-lande, betyder det meget om betalingsudbyderen også håndterer momsen for dig. Jeg har sammenlignet mulighederne i indlægget om abonnementsbetaling i SaaS.

Næste skridt: fra prismodel til betaling i produktet

Skriv din pris på én linje, og tjek den mod de seks trin ovenfor. Er svaret fast pris eller 2-3 pakker, kan du komme i gang med en færdig betalingsløsning og meget lidt kode. Kræver modellen lokationer, forbrugsmåling eller kreditter, så tag det med i planlægningen fra start, fordi det påvirker datamodellen.

Før større projekter laver jeg et betalt forprojekt til fast pris, hvor du og jeg blandt andet afklarer hvordan prisen skal fungere i produktet. Du kan se hvordan et forløb ser ud på siden om SaaS-udvikling.

Ofte stillede spørgsmål

Hvordan finder jeg det rigtige prisniveau til min SaaS?+

Tag udgangspunkt i hvad produktet er værd for kunden, ikke i hvad det koster dig at drive. Sammenlign med kundens alternativ: timer brugt på manuelt arbejde, et regneark eller en konkurrent. Spørg potentielle kunder direkte hvad løsningen koster dem i dag. Er du i tvivl, så start hellere for højt end for lavt. Det er lettere at give rabat end at hæve prisen for kunder der allerede betaler.

Skal jeg give rabat for årlig betaling?+

Ja, det er som regel en god idé. Jeg foreslår typisk en rabat der svarer til en eller to gratis måneder. Du får pengene på forhånd, og en kunde der har betalt for et helt år, har en grund mindre til at opsige undervejs. Vil du tilbyde både månedlig og årlig betaling, skal betalingen kunne håndtere skift mellem dem midt i en periode.

Skal priserne på en SaaS vises med eller uden moms?+

Sælger du kun til virksomheder, er det almindeligt at vise priser ekskl. moms og skrive det tydeligt. Sælger du til forbrugere, skal prisen de ser, typisk være den samlede pris inkl. moms. Har du begge typer kunder, kan du vise begge dele eller lade kunden vælge. Reglerne for prisoplysning og moms ved salg til andre EU-lande er detaljerede, så få dem bekræftet af din revisor.

Kan jeg kombinere flere prismodeller?+

Ja. Intercom kombinerer fx betaling pr. bruger med betaling pr. outcome for AI-agenten Fin, og pakker med pris pr. bruger er udbredt. Hver ekstra dimension gør dog prisen sværere at forstå for kunden og dyrere at bygge og supportere. Start med én værdimåler, og tilføj den næste når kunderne selv viser behovet.

Hvordan skifter jeg prismodel når jeg allerede har kunder?+

Indfør den nye model for nye kunder først, så du kan se effekten uden at sætte de nuværende kunder på spil. Giv eksisterende kunder god tid og en klar begrundelse, og overvej at lade dem beholde den gamle pris en periode. Tjek også dine abonnementsvilkår for hvor lang varsel du har lovet, før du ændrer noget.