15 SaaS-forretningsmodeller, og hvordan de tjener penge

En SaaS-forretningsmodel beskriver hvem der betaler, hvad de betaler for, og hvordan pengene finder vej til dig: abonnement, gebyr på transaktioner, provision, licenser eller en blanding. Her får du 15 forretningsmodeller, fra klassisk B2B-abonnement til markedspladser og open source, og hvad hver af dem kræver af fakturering, brugerroller og data, når produktet skal bygges.

Forretningsmodellen er ikke det samme som prismodellen. Prismodellen er den enhed kunden betaler for, fx brugere, lokationer eller forbrug, og den har jeg gennemgået i oversigten over prismodeller til SaaS. Jeg skriver som udvikler, så vægten ligger på hvad hver model betyder for koden og budgettet.

Den korte version

Tabellen viser de 15 modeller, hvordan de tjener penge, og hvad der typisk er det tunge at bygge.

Min tommelfingerregel er at jo flere parter der indgår i pengestrømmen, jo dyrere bliver produktet at bygge og drive. Forretningsmodellen er første skridt i min komplette guide til at bygge en SaaS, og den bør være på plads før du vælger teknologi.

Modeller hvor abonnementet er hele forretningen

De fire første modeller tjener pengene på abonnementer. Forskellen ligger i hvem kunden er, og hvordan salget foregår.

1. Horisontal B2B-SaaS

Et værktøj til en opgave som mange slags virksomheder har, fx projektstyring, CRM, tidsregistrering eller intern kommunikation. Kunden betaler et månedligt eller årligt abonnement, typisk pr. bruger eller pr. pakke.

Teknisk er fundamentet en kundekonto (virksomheden) med flere brugere, invitationer, enkle roller som administrator og medarbejder og et abonnement koblet til kontoen. Det lyder banalt, men en typisk fejl er at abonnementet ligger på den person der oprettede kontoen. Så går det galt den dag personen stopper i firmaet.

Min vurdering: den mest gennemprøvede model, men også den med flest konkurrenter. Uden en skarp vinkel kæmper du mod produkter med langt større budgetter.

2. Vertikal SaaS

Software til én branche, fx frisører, fysioterapeuter, vognmænd eller boligforeninger. Kunden betaler abonnement, og mange vertikale produkter tjener ekstra på tillæg som SMS-påmindelser eller betalinger.

Det tunge er branchens arbejdsgange: vagtplaner, journaler eller kørselslister. Datamodellen skal afspejle hvordan branchen faktisk arbejder, og der er næsten altid integrationer til systemer som kun den branche bruger.

Min vurdering: den model jeg typisk anbefaler en dansk iværksætter at kigge på først. En lille branche kan være nok til en sund forretning, og konkurrenterne er ofte ældre systemer. Det kræver dog at du eller en partner kender branchen indefra.

3. B2C-SaaS

Abonnementer solgt til privatpersoner, fx apps til træning, budget, sprog eller billedredigering. Prisen er lav, så forretningen hviler på mange kunder og lav churn (andelen der opsiger hver måned).

Alt skal kunne klares uden menneskelig hjælp: oprettelse, betaling, ny adgangskode, skift af kort og opsigelse. Momsen er også mere kompliceret end ved B2B: når dit samlede salg til forbrugere i andre EU-lande passerer en fælles EU-grænse, skal du opkræve moms efter kundens lands regler. Sælger du også via App Store eller Google Play, gælder butikkernes egne regler for betaling i appen. Jeg har sammenlignet betalingsløsningerne i indlægget om abonnementsbetaling i SaaS.

Min vurdering: svær at tjene penge på uden et stort marketingbudget. Kunderne er prisfølsomme, og supporthenvendelserne er de samme uanset om kunden betaler 49 eller 499 kr. om måneden.

4. Salgsdrevet enterprise-SaaS

Få, store kunder på årsaftaler, ofte forhandlet individuelt. Salget tager måneder og involverer indkøb, IT-sikkerhed og jura, men hver kunde er meget værd.

Store kunder stiller krav som små kunder aldrig nævner: log ind via deres eget system (single sign-on, fx Microsoft Entra ID), en revisionslog over hvem der har gjort hvad, detaljerede roller, databehandleraftale og ofte et sikkerhedsspørgeskema på mange sider. Betalingen sker typisk via faktura med særlige vilkår pr. kunde.

Min vurdering: kun realistisk hvis du har adgang til køberne i forvejen. Byg ikke SSO og revisionslog på forhånd, men tænk roller og hændelser ind, så de kan tilføjes når den første store kunde kræver det.

Modeller med flere slags kunder i samme system

De næste tre modeller har mere end én type kunde. Her bliver en model ofte dyrere end forventet, fordi datamodellen skal kende forskel fra starten.

5. B2B2C

Virksomheden betaler, men dens egne kunder bruger også systemet. Et bookingsystem til klinikker er det klassiske eksempel: klinikken betaler abonnementet, og patienterne booker tider. Indtægten kommer fra virksomheden, ofte suppleret med betaling pr. SMS eller pr. booking.

Du får to helt forskellige brugergrupper med hver deres brugerflade. Slutkunderne skal kunne bruge systemet uden besvær, ofte uden at oprette en adgangskode, og virksomheden vil se sit eget logo og sine egne farver. I GDPR-sammenhæng er virksomheden typisk dataansvarlig for sine kunders oplysninger, og du er databehandler. Hvordan hver virksomheds data holdes adskilt, har jeg forklaret i indlægget om multi-tenant-arkitektur.

Min vurdering: en stærk model, fordi slutkunderne gør systemet svært at skifte ud. Men du får to produkter at designe og supportere i stedet for ét.

6. Markedsplads

Du forbinder købere og sælgere og tager en provision af hver handel, eventuelt suppleret med et abonnement for sælgerne. Det kan fx være håndværkere og husejere eller udlejere og lejere.

Markedspladsen er en af de tungeste modeller at bygge. Sælgerne skal oprettes og verificeres hos en betalingsudbyder, betalingen skal deles mellem sælgeren og dig, og du skal håndtere udbetalinger, refusioner, tvister og anmeldelser. Stripe Connect er bygget til netop det: ifølge Stripes dokumentation kan du modtage betaling fra kunden og automatisk udbetale en del til sælgeren. Resten har jeg samlet i guiden til at udvikle en markedsplads.

Min vurdering: det svære er sjældent koden, men at få både købere og sælgere på samme tid. Test efterspørgslen manuelt før du bygger automatiske udbetalinger.

7. White-label og forhandlere

Partnere, typisk bureauer eller konsulenter, betaler for at sælge dit produkt under deres eget navn til deres egne kunder. Du tjener på en licens pr. partner, pr. slutkunde eller en kombination, og partnerne står for salget.

White-label kræver et ekstra niveau i datamodellen: partneren, partnerens kunder og deres brugere. Hertil kommer egne domæner, temaer, e-mails fra partnerens domæne, et partnerpanel og fakturering til partneren. Hele listen står i indlægget om white-label SaaS.

Min vurdering: en god måde at få distribution uden egen salgsstyrke, men vent til produktet er stabilt. Hver fejl rammer nu partnerens kunder og partnerens omdømme.

Modeller der tjener på transaktioner og forbrug

I de næste to modeller vokser indtægten med det kunderne laver i systemet, ikke med antallet af brugere. Derfor skal du kunne tælle og afregne præcist.

8. Indlejret betaling

Dine kunder modtager betalinger fra deres egne kunder via dit system, og du tager en lille andel oven i betalingsudbyderens gebyr. Et bookingsystem kan fx opkræve betaling for behandlingen ved booking. For nogle produkter bliver andelen af betalingerne en større indtægt end selve abonnementet.

Hver af dine kunder skal have en tilknyttet betalingskonto hos udbyderen, inklusive den identitetskontrol udbyderen kræver. Dertil kommer gebyrer, refusioner, udbetalinger og en afstemning som kunden kan bruge i sit regnskab. Selve betalingen klarer udbyderen, men koden omkring den skal være helt præcis.

Min vurdering: en oplagt ekstra indtægt i vertikal SaaS, hvor betaling alligevel er en del af arbejdsgangen. Tilføj den når kunderne beder om det, ikke i første version.

9. API-først

Produktet er et API (en grænseflade som andre programmer kan kalde) frem for en brugerflade. Kunderne er udviklere, der betaler pr. kald, pr. volumen eller for en pakke med en grænse. Det kan fx være tjenester til SMS, e-mail eller adresseopslag.

Du skal have API-nøgler pr. kunde, begrænsning af antal kald, måling af forbrug, dokumentation, et testmiljø og stabile versioner. En ændring der bryder kundernes integration, kan koste dig kunden, så versionering skal være planlagt fra start.

Min vurdering: virker når du løser et afgrænset teknisk problem bedre end andre. Regn med at drift og support fylder mere end i et almindeligt webprodukt, fordi kunderne stiller høje krav til oppetid.

Modeller bygget på et økosystem

De næste tre modeller lever af andres platforme, andres apps eller et fællesskab omkring koden.

10. App på en andens platform

Du bygger en app til et system dine kunder allerede bruger, fx Shopify, HubSpot eller et regnskabsprogram, og sælger den i platformens app-butik. Kunderne finder dig dér, og betalingen går ofte gennem platformens fakturering. Ifølge Shopifys regler for app-udviklere tager Shopify ingen andel af de første 1 mio. dollar i samlet app-omsætning og 15 % derover, plus et betalingsgebyr på 2,9 %.

Du skal bygge installation via platformens login (OAuth), modtage hændelser (webhooks), bruge platformens fakturering og følge med når API'et ændres. Appen skal ofte godkendes før den kommer i butikken.

Min vurdering: den hurtigste vej til de første kunder, fordi platformen giver dig distribution. Prisen er afhængigheden. Ændrer platformen regler eller API, eller bygger den selv din funktion, står du svagt.

11. Egen app-markedsplads

Når dit produkt er stort nok, kan andre bygge apps og integrationer til det. Du tjener på en andel af deres salg, men den største gevinst er ofte at kunderne bliver, fordi resten af deres værktøjer er koblet på dit system.

Teknisk kræver det et offentligt API, OAuth så tredjeparter kan få adgang på kundens vegne, afgrænsede rettigheder, webhooks, dokumentation og en godkendelsesproces for nye apps.

Min vurdering: ikke en model til en ny SaaS. Start med et godt API og webhooks til dine egne kunder. En app-markedsplads kræver mange kunder før nogen gider bygge til den.

12. Open core

Kernen i produktet er open source og gratis at hoste selv, og du tjener penge på en hostet udgave eller på funktioner der kun findes i den betalte version. Analyseværktøjet Plausible er et eksempel: ifølge Plausibles side om selvhosting er Community Edition gratis under AGPL-licensen, mens blandt andet tragtanalyser, e-handelsomsætning og SSO kun findes i den betalte cloud-udgave.

Du vedligeholder to udgaver: en der kan installeres af andre, typisk som Docker-image, og en hostet. Opdateringer skal virke for dem der springer versioner over, og betalte funktioner skal kunne slås til og fra med en licens.

Min vurdering: passer bedst når kunderne selv er tekniske. Valget af licens er en juridisk beslutning, som skal være på plads før koden bliver offentlig.

Modeller hvor softwaren kun er en del af produktet

De sidste tre modeller sælger mere end software: menneskeligt arbejde, en fysisk enhed eller indsigt fra data.

13. Service-drevet SaaS

Kunden betaler en fast månedlig pris for software plus arbejde udført af mennesker, fx bogføring, lønadministration eller rapporter. Softwaren gør dit eget team hurtigere og giver kunden overblik.

Reelt bygger du to produkter: det kunden ser, og et internt værktøj til dine medarbejdere med opgavekøer, deadlines og adgang på tværs af kunder. Den adgang skal styres og logges, fordi medarbejderne ser data fra mange kunder.

Min vurdering: lavere avance end ren software, men langt lettere at sælge i starten. Har du allerede en serviceforretning, er det ofte den mest realistiske vej.

14. Hardware plus SaaS

En fysisk enhed som en sensor, en GPS-tracker, en betalingsterminal eller en måler, kombineret med et abonnement på software og data. Enheden sælges eller lejes, og abonnementet giver den løbende indtægt.

Systemet skal modtage data fra mange enheder, tåle at de mister forbindelsen, vide hvilken enhed der hører til hvilken kunde og helst kunne opdatere firmware (softwaren på selve enheden) på afstand. Logistik, returneringer og garanti er en forretning i sig selv.

Min vurdering: stærk når enheden skaber data som ikke kan fås på anden måde. Jeg bygger platformen, API'et og brugerfladen, men elektronik og firmware kræver andre specialister.

15. Data og benchmarks

Du samler data på tværs af kunderne og sælger indsigten, fx hvordan en butiks omsætning pr. kvadratmeter ligger i forhold til lignende butikker. Det sælges typisk som en dyrere pakke eller et tillæg.

Teknisk kræver det en datamodel der kan samle og sammenligne på tværs af kunder, og regler for anonymisering, så ingen enkelt kunde kan genkendes. Den største udfordring er juridisk. Indgår der personoplysninger, og er du databehandler, må du kun bruge dem som aftalt med kunden og ikke til egne formål, som Datatilsynet forklarer i sin vejledning om rollefordeling. Ellers er det dine vilkår der afgør hvad du må.

Min vurdering: en god ekstra indtægt i vertikal SaaS med mange kunder, men aldrig en model at starte med. Skal du bruge data på tværs senere, så tal med en rådgiver, og få det ind i vilkår og databehandleraftale fra begyndelsen.

Sådan vælger og kombinerer du modeller

De fleste SaaS-produkter ender med at kombinere to eller tre modeller. Et vertikalt bookingsystem kan fx tjene på abonnement, indlejret betaling og SMS-tillæg på samme tid. Det er fint, så længe én model bærer forretningen, og de andre kommer til når kunderne beder om dem.

Disse fem spørgsmål afslører hvor teknisk tung din model er:

1. Er den der betaler, også den der bruger systemet? Hvis ikke, har du flere brugergrupper og sandsynligvis B2B2C eller white-label.
2. Går der penge gennem systemet til andre end dig? Så skal du bruge en betalingsudbyder med tilknyttede konti, og afstemning bliver en del af produktet.
3. Hvem sælger produktet? Svaret afgør om du skal bygge selvbetjening, et partnerpanel eller betaling via faktura.
4. Ejer du kundeforholdet, eller gør en platform? Sælger du via en andens app-butik, låner du reelt deres kunder.
5. Hvilke data skal du bruge på tværs af kunder? Svaret påvirker både datamodellen og dine vilkår.

Svarene på spørgsmål 1 og 2 er de dyreste at ændre senere, fordi de bestemmer datamodellen. Prisen, pakkerne og tillæggene kan du justere hen ad vejen.

Næste skridt: fra forretningsmodel til teknisk plan

Skriv din forretningsmodel i én sætning: hvem betaler hvem, for hvad, og hvor pengene løber hen. Fx: "Klinikker betaler et månedligt abonnement, patienterne booker gratis, og systemet tager en lille andel af betalingerne ved booking." Den sætning fortæller en udvikler mere om datamodellen end en lang liste med funktioner.

Tag den med til den første samtale sammen med dine svar på de fem spørgsmål ovenfor. Før større projekter laver jeg et betalt forprojekt til fast pris, hvor du og jeg omsætter modellen til kundekonti, roller, betalingsflow og en afgrænset første version. Du kan se hvordan forløbet ser ud på siden om udvikling af SaaS-produkter.

Ofte stillede spørgsmål

Kan jeg skifte forretningsmodel efter lanceringen?+

Ja, men prisen afhænger af hvad der ændres. At tilføje pakker, tillæg eller årlig betaling er som regel en mindre opgave. At gå fra abonnement til markedsplads eller white-label kræver typisk ændringer i datamodellen. Tænk derfor de to eller tre mest sandsynlige modeller igennem før første version, også selvom du kun bygger den ene.

Hvilken forretningsmodel passer bedst til en lille SaaS med få ressourcer?+

Et enkelt B2B-abonnement til en afgrænset branche er som regel det mest realistiske. Erhvervskunder betaler mere end forbrugere, en niche er lettere at nå med et lille budget, og der er kun én kundetype og én pengestrøm at bygge. Vent med markedspladser, hardware og egne app-økosystemer indtil du har betalende kunder.

Skal jeg have en tilladelse for at modtage betalinger på vegne af mine kunder?+

Som regel ikke, hvis en betalingsudbyder med tilladelse står for at modtage og udbetale pengene, fx via Stripe Connect. Modtager du selv pengene på din konto og sender dem videre, kan det derimod være en betalingstjeneste der kræver tilladelse fra Finanstilsynet. Reglerne har mange undtagelser, så få din model vurderet af en advokat før du bygger betalingsflowet.

Påvirker forretningsmodellen hvad det koster at udvikle en SaaS?+

Ja, ofte mere end antallet af funktioner. Et abonnement fra én kundetype er den billigste model at bygge. Hver ekstra brugergruppe, pengestrøm eller ekstern platform tilføjer arbejde i datamodellen, betalingsflowet og testen, og også i driften bagefter. Derfor afklarer jeg forretningsmodellen før jeg giver et estimat på en SaaS.