Churn i SaaS: 10 tekniske årsager til at kunderne opsiger

Churn i en SaaS skyldes oftere teknik end de fleste artikler om fastholdelse giver indtryk af: kort der bliver afvist, mails der lander i spam, sider der er langsomme, og fejl der kommer igen efter hver opdatering. Nogle af de kunder står i statistikken som opsagte, selvom de aldrig besluttede at stoppe. Herunder får du 10 tekniske årsager til churn, hvordan du genkender dem, og hvad du gør ved hver af dem.

Churn er den andel af dine kunder der stopper i en given periode. Jeg bygger og vedligeholder SaaS-produkter som freelanceudvikler, så jeg har en interesse i at du ser problemerne som tekniske. Derfor slutter indlægget også med et afsnit om hvornår det ikke er teknikken der er problemet.

Den korte version

De 10 årsager falder i fire grupper: penge og adgang, hastighed og stabilitet, data og tillid, og om produktet passer ind i kundens hverdag. Tabellen viser de typiske tegn på hver årsag, og hvad det første tiltag er.

Rækkefølgen er ikke tilfældig. De to første årsager rammer kunder der gerne ville blive, så de er som regel de billigste at rette op på. Er du ved at bygge din første SaaS, får du hele forløbet i min guide til at bygge en SaaS fra idé til betalende kunder.

Penge og adgang: når kunden ikke kan betale eller logge ind

De to første årsager er de mest frustrerende, fordi kunden ikke har valgt at gå. Det kaldes ufrivillig churn: abonnementet stopper af tekniske eller praktiske grunde, ikke fordi nogen har trykket på "Opsig".

1. Fejlede betalinger og udløbne kort

Et kort udløber, banken afviser en betaling, eller kunden skal godkende betalingen i sin bankapp og ser aldrig beskeden. Lukker dit system så bare abonnementet, har du mistet en kunde der var tilfreds. I Recurlys opgørelse af churn på tværs af brancher er den samlede churn for SaaS-virksomheder 3,22 %, og heraf er 1,06 procentpoint ufrivillig churn (tal fra juli 2026). Det er omkring en tredjedel.

I EU kræver reglerne om stærk kundegodkendelse (SCA) som udgangspunkt at kunden godkender betalinger online. Gentagne træk på et abonnement er normalt undtaget efter den første godkendelse, men Stripes gennemgang af SCA understreger at banken selv kan kræve en ny. Dit system skal kunne sende kunden videre til den godkendelse i stedet for at fejle i stilhed.

Det første tiltag er automatiske genforsøg. Stripe anbefaler i dokumentationen til Smart Retries som standard 8 forsøg inden for 2 uger. Dertil kommer påmindelser på mail (det kaldes dunning), en tydelig besked i appen til den der betaler, og en side hvor kortet kan opdateres uden at kontakte dig. Lad abonnementet stå som forfaldent i en periode, før du lukker adgangen. Og opfang betalingshændelserne via webhooks (automatiske beskeder fra betalingsudbyderen), så din app altid kender kundens status.

Betaler dine erhvervskunder via faktura, ser problemet anderledes ud: fakturaen havner hos den forkerte, eller bogholderiet ved ikke hvad den dækker. Lad kunden selv vælge fakturaadressen, og skriv tydeligt hvad abonnementet er. Valget af betalingsløsning betyder meget her, og jeg sammenligner mulighederne i indlægget om abonnementsbetaling med Stripe, Paddle eller en dansk løsning.

2. Login, invitationer og mails der ikke kommer frem

En ny kunde inviterer sine kolleger, men invitationen lander i spam. En anden glemmer sin adgangskode, og nulstillingsmailen kommer aldrig. For brugeren ser det ud som om produktet ikke virker, og mange giver op uden at skrive til dig.

Siden februar 2024 har Gmail krævet at alle afsendere har SPF eller DKIM sat op, og at afsendere med store mængder også har DMARC, ifølge Googles retningslinjer for afsendere. Det er indstillinger på dit domæne der beviser at mailen faktisk kommer fra dig. Andre mailudbydere bevæger sig i samme retning.

Det jeg typisk anbefaler:

• Send systemmails (login, invitationer, kvitteringer) via en dedikeret mailtjeneste, adskilt fra nyhedsbreve.
• Opsæt SPF, DKIM og DMARC på det domæne mailen sendes fra.
• Log hvilke mails der er sendt, og om de blev afvist, så du kan se det når en kunde skriver.
• Giv brugeren en knap til at sende mailen igen, og mulighed for at logge ind med Google eller Microsoft, hvis dine kunder bruger dem.

Hastighed og stabilitet

Ingen opsiger efter én langsom side. Men et system der føles tungt, eller som jævnligt fejler, gør det lettere at sige ja når en konkurrent ringer. Den her gruppe handler om oplevelsen hver eneste dag.

3. En app der bliver langsommere med tiden

Mange SaaS-produkter er hurtige ved lanceringen og bliver langsomme efterhånden som datamængden vokser. Lister uden sidedeling, databaseforespørgsler uden indeks og kode der henter de samme data hundredvis af gange (såkaldte N+1-forespørgsler) mærkes først når kunderne har et par års data. Det rammer typisk dine største og mest værdifulde kunder først, fordi de har mest data.

Mål før du gætter. Find de sider og handlinger der er langsomst for rigtige brugere, og kig på de langsomste svartider frem for gennemsnittet. Tunge opgaver som rapporter, eksport og import bør køre i baggrunden, så brugeren ikke sidder og venter. Jeg har skrevet en særskilt gennemgang af hvorfor en webapp bliver langsom, og hvad du kan gøre ved det.

4. Fejl der kommer igen efter hver opdatering

Få ting slider så hårdt på tilliden som en fejl der er rettet, og som dukker op igen to måneder senere. Det kaldes en regression. Den opstår typisk når en ændring ét sted ødelægger noget et andet sted, uden at nogen opdager det før udgivelsen.

Løsningen er automatiske tests af de arbejdsgange kunderne betaler for: login, oprettelse af det centrale i dit system, betaling og de vigtigste beregninger. Du behøver ikke teste alt. Start med de 5-10 forløb der ville koste kunder hvis de gik i stykker, og lad testene køre automatisk hver gang der udgives ny kode. Når en fejl bliver rettet, skriver du en test der fanger den, så den ikke kommer igen.

Tænk også over hvordan ændringer når ud. Store ændringer i brugerfladen kan slås til for nogle kunder først (det kaldes feature flags), og et offentligt API bør have versioner, så kundernes egne integrationer ikke går i stykker natten over.

5. Nedetid uden forklaring

Nedetid i sig selv er sjældent det der får en kunde til at gå. Det er nedetid som kunden opdager før dig, og som ingen forklarer. Skal din kunde skrive til dig for at høre om systemet er nede, har du allerede tabt lidt tillid.

Opsæt oppetidsmåling der tjekker dit system hvert minut udefra og giver dig besked på telefonen, fx med Oh Dear eller Better Stack. Hav en statusside kunderne kan tjekke, og skriv kort og ærligt bagefter hvad der skete, og hvad du har ændret. Sørg også for at nye versioner kan udgives uden at systemet går ned, og at det er aftalt hvem der reagerer hvis noget går galt uden for arbejdstid. I en lille SaaS er det ofte dig selv, og det er fint, bare det er aftalt.

Data og tillid

Den tredje gruppe er sjældnere, men dyrere. Her handler det om hvorvidt kunden tør lægge sine data i dit system og stole på det der kommer ud.

6. Fejl som ingen opdager

De farligste fejl er dem der ikke giver en fejlside. En natlig synkronisering der stopper, en import der springer rækker over, eller en påmindelse der aldrig bliver sendt. Kunden opdager det uger senere når tallene ikke stemmer, og begynder så at dobbelttjekke alt i dit system. Når en kunde fører et regneark ved siden af dit produkt for en sikkerheds skyld, er kunden halvvejs ude ad døren.

Brug et værktøj til fejlovervågning, fx Sentry eller Flare, som fanger fejl i både appen og baggrundsjob og giver besked med det samme. Sæt alarmer på job der fejler eller slet ikke kører. Og vis kunden status på importer og synkroniseringer direkte i appen: hvornår kørte den sidst, og gik det godt?

7. Datatab, datalæk og sikkerhedsbrud

Et enkelt sikkerhedsbrud kan koste flere kunder end et års langsomme sider. I en SaaS hvor mange kunder deler samme system, er den alvorligste fejl at én kunde kan se en anden kundes data. Hvordan du forhindrer det, afhænger af din multi-tenant-arkitektur, altså hvordan kundernes data holdes adskilt, og den er svær at lave om bagefter.

Mindstekravet er en backup du har prøvet at gendanne fra, adgangskontrol der testes automatisk, og frameworks og pakker der holdes opdaterede. Har du erhvervskunder, er du typisk databehandler for deres persondata. Sker der et brud, skal den dataansvarlige ifølge Datatilsynets side om anmeldelse af sikkerhedsbrud anmelde det til Datatilsynet uden unødig forsinkelse og om muligt inden for 72 timer. Som databehandler skal du efter GDPR artikel 33 give din kunde besked uden unødig forsinkelse, så kunden kan nå fristen. Begge dele kræver logning, så du kan se hvad der er sket. Spørg en jurist hvis du er i tvivl om din rolle.

Større kunder sender også spørgeskemaer om sikkerhed før de forlænger en aftale. Kan du ikke svare på dem, mister du kunden ved fornyelsen, selvom intet er gået galt.

Når produktet ikke passer ind i kundens hverdag

Den sidste gruppe bliver ofte kaldt et produktproblem. Men årsagen er tit teknisk: produktet kan ikke tale sammen med de systemer kunden allerede bruger, eller det er svært at komme i gang med.

8. Manglende integrationer

Skal kunden taste de samme oplysninger ind i dit system og i deres regnskabsprogram, CRM eller kalender, bliver dit produkt det ekstra arbejde der står for skud når budgettet skal skæres. Et produkt der er koblet til kundens andre systemer, er både mere værd og sværere at opsige.

Du behøver ikke bygge 20 integrationer. Start med webhooks (dit system sender en besked når noget sker) og en kobling til Zapier eller Make, så kunderne selv kan forbinde det de har brug for. Byg derefter rigtige integrationer til de 2-3 systemer flest kunder spørger efter. For danske B2B-produkter er det ofte regnskabsprogrammer som e-conomic og Dinero eller Microsoft 365. Skriv det ned hver gang en kunde nævner en integration, så du prioriterer efter mønstre og ikke efter den seneste mail.

Integrationer skal også vedligeholdes. Når den anden part ændrer sit API, stopper din integration, og så har du en stille fejl som i punkt 6.

9. Teknisk friktion når kunden skal i gang

De første uger er der hvor en kunde lettest fortryder, og en del af de opsigelser har en teknisk årsag: kunden kan ikke få sine eksisterende data ind. Et tomt system viser ikke sin værdi.

Byg import fra regneark tidligt, med forhåndsvisning og tydelige fejlbeskeder pr. række. Tilbyd at importere data for dine første kunder selv, hvis det er det der skal til. Og sørg for at kunden hurtigt når det første rigtige resultat, fx en rapport, en vagtplan eller en faktura. De ikke-tekniske greb til at få nye brugere godt i gang gennemgår jeg i indlægget om onboarding i SaaS.

10. En dårlig oplevelse på mobil

Mange B2B-produkter bliver designet på en stor skærm på kontoret og brugt på en telefon i marken. Håndværkere, trænere, teknikere og sælgere åbner systemet mellem to opgaver. Er knapperne for små, kan tabellerne ikke læses, eller er siden langsom på mobilnettet, bliver produktet brugt mindre. Og faldende brug er det første skridt mod en opsigelse.

Test de 3-5 vigtigste arbejdsgange på en almindelig telefon før hver større udgivelse, og se i dine data hvor stor en del af brugerne der kommer fra mobilen. Du har sjældent brug for en native app. En webapp der virker godt på telefonen, rækker langt for de fleste B2B-produkter.

Sådan finder du ud af om din churn er teknisk

Før du begynder at rette, skal du vide hvilke af de 10 årsager der rammer netop dig. Det kræver ikke et stort analyseprojekt. Jeg ville gøre sådan her:

1. Del churn op i frivillig og ufrivillig. Din betalingsudbyder kan vise hvor mange abonnementer der stoppede på grund af fejlede betalinger. Hvordan du beregner churn korrekt, står i min gennemgang af SaaS-nøgletal som MRR, churn og LTV.
2. Spørg når kunden opsiger. Et kort spørgsmål med faste svarmuligheder, hvor "fejl eller ustabilitet", "for langsomt" og "mangler integration" er tre af dem, giver svar du kan tælle.
3. Kig på de sidste 60 dage før opsigelsen. Sammenhold opsagte konti med supporthenvendelser, fejl i din fejlovervågning og hvor ofte brugerne loggede ind.
4. Find de kunder der er på vej ud. Et fald i aktivitet er ofte et tidligere signal end selve opsigelsen. Lav en simpel liste over konti hvor brugen er faldet markant, og ræk ud til dem.
5. Mål hastigheden for rigtige brugere, særligt hos dine største kunder, hvor datamængderne er størst.

Hvornår churn ikke er et teknisk problem

Jeg er udvikler, så det er fristende for mig at se alle problemer som tekniske. Men meget churn handler om noget andet: kunderne var aldrig de rigtige, produktet løser et problem de ikke har ofte nok, prisen passer ikke til værdien, eller en konkurrent gør det bedre. Det retter ingen mængde kode.

Tegn på at problemet ikke er teknisk:

• Kunderne opsiger selvom de sjældent har oplevet fejl.
• De fleste går efter at have brugt produktet meget lidt, også når alt virker.
• Opsigelserne følger budgetår eller sæson mere end dine udgivelser.
• Kunderne siger at de "ikke fik det brugt".

Ser du de mønstre, så brug pengene på at tale med kunder og justere målgruppe eller pris, før du hyrer en udvikler. Det gælder også en udvikler som mig.

Næste skridt

Start med de to årsager der er billigst at rette: tjek at fejlede betalinger bliver forsøgt igen og fulgt op, og at dine systemmails faktisk når frem. Sæt derefter fejlovervågning og oppetidsmåling op, hvis du ikke har det i forvejen. Med de data kan du se hvilke af de resterende årsager der er værd at bruge udviklingstid på.

Har du brug for en udvikler der kan gennemgå koden, rette de tekniske årsager og bygge de integrationer kunderne efterspørger, kan du læse om hvordan jeg arbejder med udvikling af SaaS-produkter. Større opgaver starter typisk med et forprojekt til fast pris, hvor du og jeg bliver enige om hvad der skal rettes først.

Ofte stillede spørgsmål

Kan jeg reducere churn uden at ændre i koden?+

Ja, en del af den. Genforsøg og påmindelser ved fejlede betalinger kan ofte slås til i betalingsudbyderens indstillinger, og SPF, DKIM og DMARC sættes op i dit domænes DNS. Oppetidsmåling og et spørgsmål ved opsigelse kræver heller ikke meget udvikling. Rettelser af langsomme sider, fejl og manglende integrationer kræver derimod en udvikler.

Hvor lang tid tager det at rette de tekniske årsager?+

Det afhænger af kodebasen, men der er stor forskel på årsagerne. Betalingsopfølgning, mailopsætning og overvågning tager typisk dage. Automatiske tests, hastighedsforbedringer og nye integrationer tager oftere uger, fordi de kræver at nogen sætter sig ind i koden. Start derfor med en gennemgang der prioriterer, så du ikke bruger uger på det der koster færrest kunder.

Kan en gammel kodebase i sig selv give mere churn?+

Ikke direkte, men den gør de fleste af de 10 årsager mere sandsynlige. Forældede frameworks og pakker giver sikkerhedshuller, kode uden tests giver flere fejl efter opdateringer, og rodet kode gør det langsomt at bygge de integrationer kunderne beder om. Kunden mærker det som et produkt der står stille, og det er en klassisk grund til at kigge efter alternativer.

Hvem holder øje med overvågningen, hvis en freelancer har bygget systemet?+

Det skal aftales skriftligt, ellers gør ingen det. Alarmer om fejl, nedetid og fejlede betalinger skal gå til en person der kan handle på dem, og det skal være klart hvad der sker uden for arbejdstid. En almindelig løsning er en serviceaftale med udvikleren, hvor overvågning, opdateringer og et fast antal timer er beskrevet, så ansvaret ikke falder mellem to stole.