SaaS-onboarding: 11 greb der får nye brugere til at blive

God SaaS-onboarding handler mindre om velkomstmails og mere om hvad en ny bruger møder i selve produktet de første ti minutter. Målet er at få brugeren hurtigst muligt frem til det øjeblik hvor produktet løser et reelt problem for dem første gang, og de greb der virker bedst, bygges direkte ind i koden: tomme tilstande der viser vejen, demo-data, import og en kort opsætningstjekliste.

Herunder får du 11 greb, hvad de løser, og hvad de kræver at bygge. Jeg udvikler software som freelancer, så vinklen er en udviklers: hvad der er billigt at bygge, og hvad der er spildt arbejde.

Den korte version

Tabellen viser de 11 greb, hvad de løser, og hvor meget arbejde de typisk kræver. Indsatsen er mit grove skøn for en almindelig B2B-webapp og afhænger af hvordan dit produkt er bygget.

Start med nummer 1 og 11, fordi de fortæller dig hvilke af de andre der betyder mest i netop dit produkt. Onboarding er ét trin i et længere forløb, og vil du se det i sammenhæng, så læs min guide til at bygge en SaaS fra idé til betalende kunder.

Fundamentet: mål, tilmelding og første spørgsmål

De tre første greb handler om hvad der sker før brugeren for alvor ser produktet. De er billige, og de afgør hvor mange der kommer ind ad døren.

1. Find det øjeblik hvor brugeren får gavn af produktet

Aktivering er første gang en ny bruger oplever at produktet løser deres problem. I et bookingsystem kan det være den første rigtige booking fra en kunde. I et faktureringsværktøj er det den første sendte faktura, og i et projektværktøj måske når to kolleger arbejder i samme projekt. Det er sjældent "har logget ind" eller "har udfyldt sin profil".

Skriv aktiveringen ned som en handling du kan tælle i databasen, fx "har oprettet mindst ét projekt og inviteret én kollega inden for syv dage". Så kan du vurdere alle de andre greb på ét spørgsmål: får det flere brugere derhen? Når du har data fra de første kunder, så sammenlign dem der blev, med dem der faldt fra, og justér definitionen. Aktiveringsraten hører til de SaaS-nøgletal du bør følge fra første kunde.

2. Gør tilmeldingen så kort som muligt

Hvert felt i tilmeldingen er en grund til at stoppe. Spørg kun om det du skal bruge for at oprette kontoen: e-mail og adgangskode, eller log ind med Google eller Microsoft hvis dine kunder bruger Google Workspace eller Microsoft 365. Firmanavn, CVR-nummer, telefon og antal ansatte kan vente til de skal bruges, fx ved første faktura.

Lås heller ikke hele produktet indtil brugeren har bekræftet sin e-mail. Lad dem komme ind med det samme, og kræv bekræftelse først ved handlinger hvor det betyder noget, som når de inviterer andre eller sender noget ud fra systemet. I Laravel kan du sætte kravet om bekræftet e-mail på de enkelte ruter i stedet for på hele appen.

Om du skal kræve betalingskort ved tilmelding, er et forretningsvalg: det sorterer de mindst seriøse fra, men giver færre tilmeldinger. Jeg gennemgår afvejningen i indlægget om freemium, gratis prøveperiode eller betaling fra dag 1.

3. Stil ét spørgsmål, og brug svaret

Et kort velkomstspørgsmål som "Hvad vil du primært bruge systemet til?" eller "Hvilken rolle har du?" kan gøre starten mere relevant. Men kun hvis svaret ændrer noget i produktet: hvilken skabelon der foreslås, hvilke trin der står i tjeklisten, eller hvilket eksempelprojekt brugeren får. Spørgsmål der kun ender i salgsafdelingens CRM, gør tilmeldingen længere uden at hjælpe brugeren.

Gem svaret på kontoen i din egen database, ikke kun i et analyseværktøj, så produktet kan bruge det. Hold det til ét eller to spørgsmål med faste svarmuligheder og et "andet". Fritekst er svær at bruge til noget automatisk.

De første minutter i produktet

Her taber mange SaaS-produkter nye brugere: de logger ind og møder et tomt dashboard. De næste fire greb handler om at fylde tomrummet med noget brugbart.

4. Byg tomme tilstande der viser næste skridt

En tom tilstand er det brugeren ser når en liste, en oversigt eller et dashboard endnu ikke har indhold. I mange produkter er det en tom tabel med teksten "Ingen data". Nielsen Norman Group anbefaler i deres retningslinjer for tomme tilstande i komplekse programmer at bruge pladsen til tre ting: fortælle hvorfor der er tomt, forklare hvad funktionen gør, og give en direkte vej til at komme i gang.

I praksis betyder det én kort forklaring og én tydelig knap: "Du har ingen projekter endnu. Et projekt samler opgaver, filer og timer for én kunde." Under teksten står knappen "Opret dit første projekt". Skeln mellem tre slags tomt: der er aldrig oprettet noget, et filter giver ingen resultater, og noget gik galt. De kræver hver sin tekst. En bruger der tror systemet er i stykker, kommer sjældent tilbage. Gode tomme tilstande er samtidig et af de billigste greb på listen.

5. Giv brugeren demo-data at lege med

Nogle produkter er svære at forstå før der er data i dem, fx dashboards, rapporter og planlægningsværktøjer. Her kan et eksempelprojekt eller demo-data vise hvordan produktet ser ud i brug, før brugeren selv har lagt noget ind.

Demo-data skal være let at genkende og let at slippe af med. Markér det tydeligt i brugerfladen, og giv en knap der fjerner det hele med ét klik. I databasen bør demo-rækker have et flag eller ligge i et separat eksempelprojekt. Så tæller de ikke med i fakturering, statistik eller eksport, og sletningen kan ikke ramme kundens rigtige data. Generér dem i baggrunden når kontoen oprettes, så tilmeldingen ikke bliver langsom.

Demo-data er ikke altid svaret. Er pointen med produktet at vise brugerens egne tal, kan opdigtede tal forvirre. Så er import eller en skabelon bedre.

6. Gør det let at flytte data ind

For mange erhvervskunder er den største forhindring ikke at forstå dit produkt, men at få deres data ind i det. Deres egne kunder ligger i et regneark, opgaverne i et gammelt system, og ingen gider taste 400 rækker i hånden.

En god import af CSV-filer (regneark gemt som tekst) har fire dele. Brugeren vælger selv hvilke kolonner der svarer til hvilke felter, ser en forhåndsvisning før noget gemmes, får en fejlliste pr. række i stedet for "Importen fejlede" og kan fortryde hele importen bagefter. Store filer bør køres i en kø i baggrunden. Og husk at dansk Excel ofte gemmer CSV med semikolon og decimalkomma, og at æ, ø og å kan blive til volapyk hvis filen ikke er gemt som UTF-8. Importen skal kunne håndtere begge dele.

Spørger flere efter import fra ét bestemt system, fx en konkurrent, kan en direkte import derfra betale sig. I de første måneder kan du også lave importen manuelt for kunden og samtidig lære hvordan deres data faktisk ser ud.

7. Start fra skabeloner, ikke en blank side

En blank formular eller et tomt lærred kræver at brugeren ved præcis hvad de vil. En skabelon giver dem noget at tilpasse frem for noget at opfinde. Det gælder alt fra tilbuds- og e-mailskabeloner til projektplaner og tjeklister.

Gem skabeloner som data i databasen, ikke som kode. Så kan du eller en kollega uden udviklerbaggrund tilføje og rette dem uden en ny udgivelse af systemet. Brug svaret fra velkomstspørgsmålet til at vise de mest relevante først. Tre gennemarbejdede skabeloner til din vigtigste målgruppe slår 30 halvfærdige.

Vejledning der ikke står i vejen

Når der er noget at se på, skal brugeren vide hvad de skal gøre nu. De næste tre greb handler om at guide uden at afbryde.

8. Vis en opsætningstjekliste med få, rigtige trin

En tjekliste i produktet, fx "Kom i gang: 2 af 4 trin", giver brugeren overblik og en lille trang til at gøre listen færdig. Hold den på 3-5 trin, og lad hvert trin være en handling der fører mod aktiveringen fra greb 1: opret første projekt, importér dine kunder, invitér en kollega.

Lad trinnene blive krydset af automatisk ud fra hvad brugeren faktisk har gjort, ikke ved at de klikker på et flueben. "Har oprettet et projekt" kan beregnes direkte fra databasen, og så passer listen altid. Lad brugeren skjule listen, og husk valget. Undgå fyldtrin som "Se vores velkomstvideo", der kun er der for at listen ser længere ud.

9. Giv hjælp i konteksten frem for en lang rundvisning

Den klassiske produkttur med ti bobler ved første login bliver ofte klikket væk. Nielsen Norman Group forklarer hvorfor introduktionsforløb ved opstart virker dårligere end hjælp i konteksten: de afbryder brugeren, og det man læser uden for sammenhæng, glemmer man. I en test af fire mobilapps klarede de testpersoner der sprang introduktionen over, opgaverne lige så godt som dem der læste den, og de oplevede endda opgaverne som lettere.

Byg i stedet små hjælpetekster der dukker op første gang brugeren åbner en bestemt funktion, korte forklaringer ved felter der kræver det, og links til en hjælpeartikel hvor det er relevant. Gem hvad den enkelte bruger har set, så den samme boble ikke kommer igen.

10. Lad brugeren invitere kolleger på det rigtige tidspunkt

I B2B-software bliver et produkt sjældent hængende hvis kun én person i virksomheden bruger det. Beder du om kollegers e-mails i tilmeldingen, før brugeren selv har set produktet, springer mange over. Spørg når der er noget at dele: når første projekt er oprettet, eller når en opgave skal tildeles en anden.

Den inviterede kollega skal have sin egen, kortere onboarding. De skal ikke oprette firma eller vælge abonnement, men lande direkte i det projekt de blev inviteret til, med den rolle de skal have. Det kræver at brugere fra start hører til en konto eller et team i datamodellen, og at invitationen bærer rollen med sig. Det er billigt at forberede tidligt og bøvlet at bygge om senere.

Sådan ved du om det virker

Det sidste greb binder de andre sammen. Uden det ved du ikke hvilke af de ti første der flytter noget i dit produkt.

11. Mål hvert trin, og tal med dem der stopper

Definér en hændelse for hvert trin frem mod aktiveringen, fx konto oprettet, første projekt oprettet, data importeret og kollega inviteret. Se så hvor mange der når fra det ene trin til det næste. Det største fald er det første du skal arbejde på.

Log de vigtigste hændelser fra serveren, ikke kun fra browseren. Hændelser fra browseren kan forsvinde hos brugere med annonceblokkere, mens det der står i din egen database, altid kan tælles. Valget af analyseværktøj påvirker både hvad du kan måle, og hvordan du håndterer samtykke. Jeg sammenligner tre udbredte muligheder i indlægget om GA4, Plausible og PostHog.

Tal viser hvor folk stopper, ikke hvorfor. Skriv til nogle af dem der faldt fra, og spørg hvad der skete. Svaret er ofte meget konkret, fx at importen ikke kunne læse deres fil. Brugere der aldrig kom ordentligt i gang, er en klassisk grund til opsigelser, og jeg har samlet flere i 10 tekniske årsager til at SaaS-kunder opsiger.

Hvad med e-mails, og hvornår er det for meget?

Onboarding-mails har deres plads, men de virker bedst når de reagerer på hvad brugeren har gjort, ikke bare på hvor mange dage der er gået. En mail der siger "Du har oprettet et projekt, men ikke inviteret nogen endnu" er mere nyttig end mail nummer tre i en fast serie. Byg produktet først, og lad mailene pege tilbage på det.

Kører du med prøveperiode, så vis status inde i produktet: hvor mange dage der er tilbage, og hvad der sker bagefter. En opgradering med få klik der hvor brugeren er, slår en mail de skal lede efter.

Ikke alle produkter har brug for alle 11 greb. Sælger du dyre licenser til få store kunder, der alligevel får et opstartsforløb med en konsulent, er automatiseret onboarding sjældent det sted pengene skal bruges. Har du endnu ingen brugere, så start med tomme tilstande og en kort tilmelding, og byg resten når du ved hvor de går i stå. Samme tankegang gælder resten af første version, som jeg gennemgår i indlægget om funktioner din SaaS kan undvære ved lancering.

Er dit egentlige problem at for få prøver produktet, ikke at de falder fra efter tilmelding, så er det markedsføring og positionering du skal arbejde med. I den situation er en udvikler som mig ikke det rigtige første køb.

Næste skridt

Opret en helt ny konto i dit eget produkt med en e-mail du aldrig har brugt, og gå de første ti minutter igennem som en ny kunde. Skriv ned hver gang du møder en tom skærm, et felt du ikke forstår, eller et sted hvor du ikke ved hvad du skal gøre nu. Sammenlign listen med de 11 greb, og start med det der koster mindst og rammer flest.

Vil du have hjælp til at bygge onboarding ind i et nyt eller eksisterende produkt, kan du læse om hvordan jeg arbejder med SaaS-udvikling. Større forløb starter med et betalt forprojekt til fast pris, hvor du og jeg bliver enige om hvad der skal bygges, før der skrives kode.

Ofte stillede spørgsmål

Hvor lang tid bør SaaS-onboarding tage?+

Så kort tid som muligt frem til brugerens første resultat, og hvor kort afhænger af produktet. Et simpelt værktøj bør kunne vise sin værdi i første session, mens et system der skal kobles til regnskabet eller have tusindvis af kunder importeret, kan tage dage. Mål tiden fra tilmelding til aktivering, og arbejd på at gøre den kortere i stedet for at sigte efter et bestemt tal.

Skal jeg bruge et færdigt onboarding-værktøj eller bygge selv?+

Tomme tilstande, tjeklister og demo-data er typisk bedst at bygge selv, fordi de hænger tæt sammen med dine data. Færdige værktøjer til produktture og hjælpebobler er hurtige at sætte op og lader folk uden udviklerbaggrund rette tekster. Prisen er et ekstra script, en løbende licens og endnu en databehandler. Byg det grundlæggende selv, og vurder værktøjer når du ved hvad du mangler.

Hvad koster det at bygge god onboarding?+

Det afhænger af hvor meget der mangler, og hvordan koden ser ud i forvejen. Tomme tilstande og en kortere tilmelding er ofte en overskuelig opgave, mens en import med kolonnevalg, forhåndsvisning og fortrydelse er et større stykke arbejde. Start med de billige greb, så du kan måle effekten før du bruger penge på resten.

Må jeg måle hvad nye brugere gør i produktet?+

Ja, men måling af brugeradfærd involverer ofte persondata, så du skal have et lovligt grundlag og beskrive det i din privatlivspolitik. Data du selv gemmer om brugerens handlinger for at levere tjenesten, er noget andet end sporing med cookies i tredjepartsværktøjer, som typisk kræver samtykke. Reglerne afhænger af hvordan du har sat det op, så tal med en juridisk rådgiver hvis du er i tvivl.