Fra service til SaaS: sådan produktiserer du din viden

Vejen fra service til SaaS går sjældent direkte fra konsulentarbejde til et færdigt produkt. Den går i trin: Først standardiserer du ydelsen, så samler du den i skabeloner og regneark, så bygger du et internt værktøj til dig selv, og først til sidst åbner du for kunder der betaler uden at du er involveret. Hvert trin kan bære en forretning i sig selv, så du kan stoppe dér hvor regnestykket holder.

Jeg skriver som udvikler, der bygger software for virksomheder. Jeg tjener penge på de sidste trin, men det er de første trin, der afgør, om de sidste overhovedet bliver relevante.

Den korte version

Tænk på vejen som en trappe. Du sælger det samme resultat hele vejen, men din egen tid pr. kunde fylder mindre for hvert trin.

Min tommelfingerregel: Gå først videre til næste trin, når det nuværende trin knager under efterspørgslen. Ikke fordi næste trin lyder mere spændende. Mange serviceforretninger får mest ud af at stoppe ved trin 3 eller 4, og det er en helt fornuftig slutstation.

Hele vejen fra idé til betalende kunder har jeg beskrevet i min guide til at bygge en SaaS. Her handler det om det der er særligt, når du starter med en ydelse og ikke med en idé.

Kan din viden blive et produkt?

Ikke al viden kan blive til software. Den viden der kan, har typisk fem kendetegn:

• Du leverer det samme resultat igen og igen. Kunderne stiller de samme spørgsmål, og du går gennem de samme trin hver gang.
• Kunden betaler for resultatet, ikke for din vurdering af netop deres situation.
• De tunge dele af arbejdet kan beskrives som regler: Har kunden X, gør du Y.
• Mange virksomheder har problemet, og de ligner hinanden nok til at én løsning passer de fleste.
• Kunderne ville gerne gøre arbejdet selv, hvis de havde det rigtige værktøj.

Det sidste punkt bliver oftest overset. Mange køber en service netop fordi de ikke vil gøre arbejdet selv. Et værktøj der lader dem gøre det selv, er reelt et nyt produkt til en ny køber, og du kan ikke regne med at dine nuværende kunder skifter over.

Eksempler der ofte passer: en bogholder der laver de samme månedsrapporter for mange små virksomheder, et marketingbureau der kører det samme tekniske SEO-tjek igen og igen, eller en HR-konsulent med de samme medarbejderundersøgelser til kunde efter kunde. Eksempler der sjældent passer: strategirådgivning, design og juridisk rådgivning i komplicerede sager, hvor værdien netop ligger i din vurdering af det enkelte tilfælde.

Trin 1-3: gør ydelsen til en fast proces, før du bygger software

De første tre trin kræver næsten ingen kode. Til gengæld giver de dig det vigtigste grundlag for et produkt: viden om hvad kunderne faktisk betaler for.

1. Standardisér ydelsen, og sæt en fast pris. Lav ydelsen om til en fast pakke med fast indhold, fast pris og fast leveringstid. Det kaldes en produktiseret ydelse, og den er den billigste test af om et produkt kan sælges. Kan du ikke sælge en fast pakke manuelt, løser software det ikke. En manuel leverance er også en af de stærkeste måder at validere en SaaS-idé på, fordi kunden betaler for resultatet i stedet for bare at sige at det lyder interessant.
2. Skriv processen ned, og mål den. Beskriv hvert trin i leverancen: hvad du får ind, hvilken beslutning du træffer, og hvad der kommer ud. Notér i et regneark hvor lang tid hvert trin tager over en række leverancer, og brug formularer og skabeloner så input altid kommer i samme form. Når du har tallene, kan du se hvilke 2-3 trin der både tager mest tid og følger faste regler. Det er dem software skal overtage først.
3. Byg et internt værktøj til dig selv. Den første software er kun til dig og dit hold. Den må gerne være rå: ingen betaling, ingen introduktion for nye brugere og ingen flotte skærmbilleder. Den skal bare fjerne de tunge trin du fandt i trin 2, og den betaler sig i sparede timer, også selv om den aldrig bliver en SaaS. Et råd fra udviklersiden: Knyt alle data til en kunde fra første dag, selv om det kun er dig der logger ind. Det koster næsten ingenting nu og sparer en stor ombygning, hvis kunderne senere skal have adgang.

Trin 4-6: fra internt værktøj til produkt

Her bliver det dyrere, fordi kunderne begynder at bruge softwaren selv. Til gengæld bygger du nu oven på en proces der er afprøvet på rigtige kunder.

4. Giv kunderne adgang. Lad kunderne logge ind og se resultater, uploade data eller godkende leverancer, mens du stadig leverer selve ydelsen. Det er en kundeportal, ikke en SaaS endnu. Hver kunde skal nu kun kunne se sine egne data. Rummer værktøjet persondata om kundens medarbejdere eller kunder, er du typisk databehandler og skal have en databehandleraftale med hver kunde, som Datatilsynet forklarer i sin vejledning om dataansvarlige og databehandlere. Hold øje med hvilke skærmbilleder kunderne bruger mellem dine leverancer. Det er kimen til produktet.
5. Skær en selvbetjent første version ud. Find den del af værktøjet som kunderne bruger uden dig, og gør den til en version hvor en ny kunde kan oprette sig, komme i gang og få et resultat uden at tale med dig. Det sværeste er ikke koden. Det er at flytte din viden ind i produktet som standardindstillinger, skabeloner, eksempler og advarsler. Hvad der skal med i første omgang, har jeg gennemgået i indlægget om at afgrænse en SaaS-MVP.
6. Prissæt produktet, og planlæg overgangen. Sæt ikke prisen ud fra de timer du sparer kunden for. Sæt den ud fra værdien og gerne efter noget der vokser med kundens brug, fx antal brugere eller sager. Modellerne står i min gennemgang af prismodeller til SaaS. Dine nuværende kunder er oplagte første brugere, men vær ærlig om at det er en tidlig version. Mange ender med en blanding: et billigere abonnement hvor kunden selv gør arbejdet, og en dyrere pakke hvor du stadig gør det for dem.

Hvad koster springet fra service til SaaS?

De første trin koster mest din egen tid. Det dyre spring ligger mellem det interne værktøj og den selvbetjente version, fordi softwaren nu skal klare alt det du hidtil har klaret for kunderne.

Tallene er regnet med 1.000 kr. i timen og er kun et pejlemærke. Prisniveauer og driftsudgifter står mere udførligt i min artikel om hvad det koster at udvikle en SaaS. Husk også at software skal vedligeholdes: Regn med at afsætte 10-20 % af byggeprisen om året.

Fordelen ved at gå trinvis er at du ikke betaler for at gætte. Når du når trin 5, er kernelogikken afprøvet, og er det interne værktøj bygget ordentligt, kan meget af koden genbruges. Det du primært betaler for, er de dele der ikke har noget med din viden at gøre: login, betaling, e-mails og administration.

Trin 1-2 klarer du selv, og en første udgave af det interne værktøj kan ofte bygges med no-code-værktøjer. Fra trin 4, hvor kunders data og adgang kommer i spil, er det tid til en udvikler eller en teknisk medstifter. Mit råd: Kan du ikke finansiere både første version og et års vedligehold af din nuværende indtjening, så bliv ved trin 3 eller 4 lidt længere.

Typiske fejl når en serviceforretning bygger software

De fleste fejl skyldes at virksomheden tænker som en serviceforretning, også efter at den er begyndt at sælge software.

• Hver kunde får sin egen variant. Siger du ja til alle tilpasninger, har du ikke et produkt, men en konsulentforretning med et ekstra system at vedligeholde. Byg indstillinger som kunderne selv kan slå til og fra, i stedet for særlig kode til hver kunde.
• Softwaren bliver gratis tilbehør. Giver du kundeportalen med gratis for at gøre ydelsen mere attraktiv, er det svært at tage betaling for den senere. Beslut fra start om den er en del af prisen eller et tilvalg.
• Målingen springes over. Uden tal på hvor tiden går, automatiserer du det der irriterer dig mest, ikke det der koster mest.
• Serviceindtægten lukkes for tidligt. Et abonnement vokser langsomt, mens din ydelse betaler regningerne i dag. Behold den, indtil produktet kan bære sig selv.
• Driften bliver glemt. Opdateringer, sikkerhed, backup og support fortsætter efter lanceringen, også i de måneder hvor du har travlt med kundeopgaver.
• Personen bag forsvinder. Nogle kunder betaler for dig, ikke for metoden. Fjerner du dig selv helt fra leverancen, fjerner du det de købte.

Hvornår du ikke skal lave din service om til SaaS

Det er ikke et nederlag at stoppe før trin 5. Vælg en anden vej, hvis et eller flere af disse punkter passer:

• Værdien ligger i din vurdering af hver enkelt sag, og den kan ikke skrives ned som regler.
• Du har få, store kunder med vidt forskellige behov. Så får du mere ud af et internt værktøj og flere timer til de kunder du har.
• Markedet er stort nok til en god servicevirksomhed, men for lille til at mange hundrede kunder vil betale et abonnement.
• Du har ikke lyst til at drive et softwareprodukt med support, opdateringer, salg og markedsføring, år efter år.
• Du skal bruge indtægten fra produktet inden for et halvt år.

Vil du alligevel have et lille produkt du kan drive alene ved siden af din ydelse, har jeg skrevet om hvordan du holder det småt i guiden til micro-SaaS. Og et ærligt punkt om mig selv: Løser en god skabelon og et regneark dit problem, har du ikke brug for en udvikler endnu.

Næste skridt

Gå tjeklisten igennem, før du betaler for den første linje kode. De punkter du ikke kan krydse af, viser hvilket trin du reelt står på.

Når du er klar til at få bygget det interne værktøj eller den første selvbetjente version, kan du se mine priser og hvordan jeg arbejder med forprojekt og fast pris. Så ved du hvad et overslag koster, før du forpligter dig til mere.

Ofte stillede spørgsmål

Hvad er forskellen på en produktiseret ydelse og en SaaS?+

En produktiseret ydelse er en service solgt som en fast pakke med fast indhold, pris og leveringstid, men det er stadig dig der udfører arbejdet. En SaaS er software som kunden selv bruger og betaler abonnement for, uden at du er involveret i den enkelte leverance. Den produktiserede ydelse er ofte det bedste første skridt, fordi den viser om kunderne vil betale for et standardiseret resultat.

Hvor lang tid tager det at gå fra service til SaaS?+

Der er ingen fast tidsramme, og det tager typisk længere end koden alene. At standardisere ydelsen og måle processen kan klares ved siden af den daglige drift. Et lille internt værktøj tager ofte 1-3 måneder at få bygget, og en selvbetjent første version flere måneder mere. Det der tager længst tid, er sjældent udviklingen, men at finde de kunder der vil betale for at gøre arbejdet selv.

Kan jeg bygge det interne værktøj med no-code?+

Ja, til de første trin er no-code-værktøjer og regneark ofte det rigtige valg, fordi du stadig lærer hvordan processen skal se ud. Grænsen kommer typisk når kunderne skal logge ind, når deres data skal holdes adskilt, eller når prisen pr. bruger begynder at løbe op. Så er det tid til at bygge rigtig software, og så er det en fordel at du allerede ved præcis hvad den skal kunne.

Må jeg bruge mine kunders data til at udvikle produktet?+

Ikke uden videre. Data du behandler for en kunde, må som udgangspunkt kun bruges til det formål I har aftalt, og det gælder især persondata. Vil du bruge kundedata til at udvikle eller teste produktet, så aftal det skriftligt, anonymisér hvor det er muligt, og brug helst opdigtede testdata. Det her er ikke juridisk rådgivning, så tal med en advokat, hvis data er en central del af produktet.