Egen platformSammenligning
enRead in EnglishKundeportal: custom-udviklet eller white-label? Sådan vælger du
Kundeportal custom eller white-label? En uafhængig sammenligning af integrationer, branding, data og totalpris, og hvornår hver løsning ikke passer.

Freelance full-stack udvikler
- Udgivet
- Læsetid
- 11 min.
Indhold i indlægget9
Om din kundeportal skal være custom eller white-label, afgøres sjældent af abonnementsprisen, men af fire ting: integrationer, branding, data og totalpris over fem år. Deler du primært dokumenter, fakturaer og opgaver med dine kunder, er en white-label-portal næsten altid det rigtige valg. En custom-udviklet portal betaler sig når den skal følge dine egne processer, skrive data tilbage i dit ERP-system eller være en del af det du sælger.
Søger du på emnet, er det meste du finder skrevet af portalleverandører, og de anbefaler naturligt nok deres eget produkt. Jeg bygger selv portaler og er altså heller ikke neutral, men jeg skriver lige så tydeligt hvornår du ikke skal få en udviklet.
Den korte version
| White-label-portal | White-label + egne integrationer | Custom-udviklet portal | |
|---|---|---|---|
| Bedst til | Servicevirksomheder der deler filer, fakturaer, opgaver og beskeder | Standardbehov, men data der bor i et ERP- eller økonomisystem | Særlige processer, mange kundebrugere eller portalen som en del af produktet |
| Integrationer | Dem leverandøren tilbyder, ofte import eller Zapier | Bygges via portalens API hvis det kan skrive data | Bygges præcis til dine systemer |
| Branding | Logo, farver og ofte eget domæne | Som white-label | Alt, også login, mails og flows |
| Roller og rettigheder | Leverandørens model | Leverandørens model | Dine regler, fx flere brugere pr. kundevirksomhed |
| Data | Hos leverandøren, eksport varierer | Hos leverandøren, med en kopi hos dig | Hos dig, på den hosting du vælger |
| Tid til lancering | Dage til uger | Uger | Typisk måneder |
| Totalpris over fem år | Lavest ved standardbehov og få brugere | Abonnement plus integration og vedligehold | Højest at starte på, men stiger ikke med antal kundebrugere |
| Største risiko | Du tilpasser processen til værktøjet | Leverandøren ændrer API eller priser | Høj startpris og et system du selv skal holde ved lige |
Min beslutningsregel: Kan en færdig portal klare det dine kunder oftest ringer og skriver om, og kan den få data fra dine systemer uden at nogen skal taste dem ind igen, så lej. Skal portalen ændre data i dit ERP-system, følge regler der kun findes hos dig, eller sælges videre som en del af dit produkt, så regn på en udviklet portal. Er du ikke sikker på at en kundeportal overhovedet er den rigtige platformtype, starter min guide til at lave din egen platform et skridt tidligere.
Tre slags white-label og to mellemveje
Når jeg skriver white-label, mener jeg færdig portalsoftware som du lejer og sætter dit eget navn på. Den findes i tre varianter:
- Selvstændig portalsoftware som fx SuiteDash, der ifølge prissiden koster 19-99 dollar om måneden med et ubegrænset antal kunder og medarbejdere og white-label på alle planer.
- Portalen i dit CRM- eller helpdesksystem. HubSpots kundeportal følger med Service Hub Professional og Enterprise og lader kunderne følge og svare på deres supportsager. Den er stærk hvis dine kundedata allerede ligger i HubSpot.
- No-code-portalbyggere som Softr, der bygger en portal oven på data i fx Airtable, Google Sheets eller værktøjets egen database. De er fleksible, men du bygger selv, og før eller siden rammer du værktøjets grænser.
Mellem de to yderpunkter findes to mellemveje, som ofte er det bedste svar:
- Du lejer portalen og får kun bygget integrationen. En lille udviklet tjeneste henter fakturaer fra dit økonomisystem og skriver bestillinger tilbage i dit ERP-system. Det kræver at portalen har et API (en indgang som andre programmer kan hente og sende data gennem) der også kan skrive data.
- Du får bygget en portal på færdige byggesten. Brugerfladen og forretningsreglerne bygges til dig, men login, betaling, filopbevaring og mails kommer fra gennemprøvede tjenester som fx Stripe. Sådan ville jeg selv gribe en portal an: du betaler kun for at udvikle det der er dit eget.
Hvordan du tjekker om et API er godt nok at bygge videre på, gennemgår jeg i sammenligningen af eget bookingsystem og standardløsning.
Integrationer: det kriterium der vejer tungest
En kundeportal er kun nyttig hvis den viser de rigtige data, og de data bor sjældent i portalen. Ordrer ligger i dit ERP-system (virksomhedens centrale forretningssystem), fakturaer i økonomisystemet og kontakter i CRM'et. Spørgsmålet er derfor ikke om portalen kan vise en faktura, men hvordan fakturaen kommer derind.
Integrationer findes i tre niveauer:
- Manuelt eller via import, hvor medarbejderne uploader filer, eller en eksport køres hver nat. Det klarer de fleste white-label-portaler, og det er fint så længe data må være et døgn gamle.
- Læsning i realtid, hvor portalen henter opdaterede data direkte fra dine systemer. Det kræver en færdig kobling eller udvikling.
- Skrivning tilbage, hvor kunden bestiller, godkender eller ændrer noget i portalen, og det skal ende i dit ERP-system uden at nogen taster det ind igen. Her skal fejl, dubletter og konflikter håndteres i begge ender.
Den vigtigste pointe er at integrationen koster stort set det samme uanset om portalen er lejet eller bygget. Skal en white-label-portal skrive ordrer tilbage i dit ERP-system, og findes der ingen færdig kobling, så er det udviklingstimer. Abonnementet sparer dig for selve portalen, ikke for integrationen. Er integrationen derimod en simpel import, er white-label svær at slå. Hvor mange timer de forskellige typer integrationer typisk tager, har jeg gennemgået i prisguiden til kundeportaler.
Branding og brugeroplevelse: dit udseende eller dit produkt?
White-label lover at portalen ligner din egen, og det holder for det visuelle. HubSpot skriver fx at portalen automatisk overtager dine farver, dit logo, din skrifttype og dit favicon, og SuiteDash har white-label og en mobilapp med dit brand på alle planer. Men branding har flere niveauer, og de øverste skiller løsningerne:
- Logo og farver, som stort set alle klarer.
- Eget domæne og mails fra din egen afsender. Det klarer de fleste, men på nogle produkter først på en dyrere plan, så tjek prissiden før du sammenligner priser.
- Login, fx at dine erhvervskunder kan logge ind med deres egen Microsoft-konto, eller at portalen deler login med dit eksisterende produkt. Her begynder white-label at stramme.
- Flows, altså de skridt kunden går igennem for at bestille, godkende eller reklamere. I en lejet portal er de leverandørens, og du kan typisk kun slå trin til og fra.
For en rådgiver der deler dokumenter med sine kunder, er niveau 1 og 2 nok. Er portalen derimod det dine kunder betaler for, fx selvbetjening i en B2B-forretning eller adgangen til et produkt, er det niveau 3 og 4 kunderne mærker. Så bliver white-label et kompromis netop der hvor du skal skille dig ud.
Roller og rettigheder hører med her. I B2B har én kundevirksomhed ofte flere brugere: indkøberen må bestille, bogholderen må se fakturaer, og en administrator styrer resten. Nogle færdige portaler har kun få faste roller. Er dine regler mere detaljerede, så test dem i prøveperioden med et rigtigt eksempel og ikke med demodata.
Data, ejerskab og GDPR
Med en white-label-portal ligger dine kunders data hos leverandøren. Det er ikke et problem i sig selv, men tre ting skal være i orden.
For det første skal du have en databehandleraftale, fordi leverandøren behandler persondata på dine vegne. Spørg samtidig hvor data hostes, og om underleverandører uden for EU har adgang.
For det andet skal du vide hvad du kan få med ud. EU's Data Act har gældt siden 12. september 2025 og skal ifølge Europa-Kommissionens gennemgang gøre det lettere at skifte cloudtjeneste. SaaS-leverandører skal kunne eksportere data i et almindeligt, maskinlæsbart format, og fra 12. januar 2027 må de slet ikke tage gebyrer for at du skifter. Hvordan reglerne rammer netop din leverandør, er et juridisk spørgsmål, så spørg en rådgiver hvis meget står på spil.
For det tredje, og det overser mange: data er ikke det samme som opsætning. Du kan få kunder, dokumenter og sager med ud, men roller, automatiseringer, skabeloner og flows du har bygget i leverandørens værktøj, skal laves forfra et andet sted. Jo mere du har tilpasset, jo dyrere bliver et skifte.
Med en custom-udviklet portal er billedet vendt. Du ejer koden og data og vælger selv hosting, fx i EU. Til gengæld er du også ansvarlig for sikkerhedsopdateringer, backup og for at kunde A aldrig kan se kunde B's data.
Totalpris over fem år
Her går de fleste sammenligninger galt, fordi et abonnement til et par hundrede kroner om måneden bliver holdt op mod et tilbud på et sekscifret beløb. Efter mit skøn koster en enkel udviklet kundeportal typisk 80.000-240.000 kr. ekskl. moms og 160.000-540.000 kr. når den skal integreres med dine kernesystemer. Hvad der flytter de tal, står i prisguiden jeg linkede til ovenfor.
Regner du fem år frem med opsætning, integrationer, vedligehold og abonnement, vinder den færdige portal som regel ved standardbehov og få medarbejdere i systemet. Billedet vender i tre situationer:
- Prisen følger antallet af kunder. Tager leverandøren fx 75 kr. pr. aktiv kundebruger om måneden, koster 500 brugere 37.500 kr. om måneden eller 2,25 mio. kr. over fem år. Så er en udviklet portal ofte billigere længe før.
- Integrationen skal bygges alligevel. Er koblingen til dit ERP-system den største post, betaler du den på begge veje.
- Omvejene koster arbejdstid. Kan portalen ikke det flow kunderne bruger mest, klarer dine medarbejdere det manuelt. Det står ikke på nogen faktura, men det koster hver uge. Signalerne kender du måske fra mine tegn på at virksomheden er vokset ud af Excel.
Hertil kommer leverandørrisikoen: prisstigninger, funktioner der forsvinder, eller et opkøb der ændrer produktet.
Hvornår hver løsning ikke passer
White-label passer ikke når
- portalen skal skrive data tilbage i et system som leverandøren hverken har en kobling til eller et API der kan skrive
- dine roller og rettigheder er mere detaljerede end portalens model, og kunderne ender med at dele login internt
- portalen er en del af det du sælger, og kunderne skal opleve dit produkt og ikke en leverandørs
- prisen er pr. kundebruger, og du forventer hundredvis af aktive brugere
En custom-udviklet portal passer ikke når
- behovet er at dele filer, fakturaer og beskeder. Det løser en færdig portal bedre og billigere end jeg kan
- du ikke ved om kunderne vil logge ind. Test med en lejet portal først, også selvom den knirker
- processen stadig ændrer sig hver måned. Et lejet værktøj er billigere at smide ud end et system du har betalt for at få bygget
- der ikke er budget til drift og videreudvikling efter lanceringen
Mellemvejen passer ikke når
- portalen mangler et API, eller API'et kun kan læse data
- problemet ligger i portalens egne flows. En integration kan ikke ændre hvordan kunden bestiller
Vil du lave samme afvejning for andre systemer, har jeg samlet de afgørende spørgsmål i skræddersyet software vs standardsoftware.
Næste skridt: sådan træffer du valget
- Find de tre ting kunderne oftest kontakter dig om. Det er dem portalen skal løse fra første dag.
- Placer dig selv på kriterierne: Skal portalen kun læse data eller også skrive? Hvilket niveau af branding har du brug for? Hvor detaljerede er dine roller? Hvilke krav har du til hosting og eksport?
- Test to-tre færdige portaler, også den i dit CRM- eller helpdesksystem, med dit sværeste rigtige eksempel. Spørg leverandøren direkte hvad der ikke kan lade sig gøre.
- Regn fem år for hver vej, inklusive integrationer, vedligehold og den tid dine medarbejdere bruger på omveje.
- Afgræns en første version uanset hvilken vej du vælger. En portal med én funktion kunderne bruger, slår en med ti de ikke åbner.
Lander du på en færdig portal, er du færdig. Lander du på en mellemvej eller en udviklet portal, starter jeg større projekter med et betalt forprojekt til fast pris, hvor integrationerne bliver afprøvet og første version afgrænset før der skrives kode. På siden om udvikling af webapps og platforme kan du se hvordan et forløb ser ud. Du taler direkte med mig som udvikler, og du ejer koden fra første dag.
Ofte stillede spørgsmål
Hvad sker der med mine data hvis white-label-leverandøren lukker?
Det afhænger af aftalen, så læs vilkårene om opsigelse og udlevering af data før du skriver under. Mange aftaler giver en periode til at eksportere data ved opsigelse eller lukning, men det er ikke en selvfølge. Tag under alle omstændigheder en fuld eksport med jævne mellemrum, og sørg for at vigtige dokumenter også ligger i dine egne systemer. Så bliver en lukning et irriterende projekt og ikke en krise.
Hvem har ansvaret for sikkerheden i en custom-udviklet kundeportal?
Det har du som ejer, også selvom en udvikler bygger og vedligeholder portalen. I praksis skal nogen holde framework og pakker opdateret, overvåge portalen, tage backup og teste at kunder kun kan se deres egne data. Aftal det i en serviceaftale fra start, så sikkerheden ikke afhænger af at nogen husker det.
Kan jeg sælge en custom-udviklet portal videre til andre som white-label?
Ja, men det skal planlægges fra start. Portalen skal kunne holde flere virksomheders data adskilt i samme system, og design, domæne og mails skal kunne skiftes pr. virksomhed. Det er markant mere arbejde end en portal til én virksomhed. Er videresalg kun en mulighed langt ude i fremtiden, så byg til dig selv først, men bed udvikleren om ikke at lukke døren for det.
Hvordan får jeg kunderne til at bruge portalen?
Start med det kunderne oftest henvender sig om, og gør portalen til det nemmeste sted at få svar. Send links til portalen i stedet for vedhæftede filer, gør login enkelt, fx med et link på mail, og lad kundeservice henvise til portalen. Mål hvor mange der logger ind de første måneder før du bygger mere.