Beslutningsguide
En kundeportal lyder enkelt: et login hvor kunderne kan se ordrer, dokumenter, status og måske bestille noget. I praksis er det et af de mest misforståede produkter i B2B — fordi ordet dækker over alt fra en SharePoint-mappe med adgangskode til et fuldt multi-tenant produkt med roller, SSO og integration til ERP.
Vi bygger kundeportaler når det er det rigtige svar. Vi siger også nej når det ikke er. Det her er den ramme vi selv bruger, inden nogen tegner skærme.
TL;DR
De vigtigste pointer
- En kundeportal er værd at bygge når den flytter gentaget manuelt arbejde væk fra jeres team — ikke når den bare ser moderne ud.
- Hvis behovet er "deling af filer" eller "statusopdateringer", så er SharePoint, HubSpot eller et ticket-system ofte nok.
- Tærsklen rammes når kunderne skal handle i jeres data: ordrer, rettigheder, dokumenter pr. kontrakt, godkendelser.
- Auth, roller og dataisolation er kernen — UI'et er den billige del. Planlæg dem først.
- Start smalt: ét flow der sparer reel tid. Udvid når brugen er dokumenteret, ikke når backlog'en er lang.
Hvad en kundeportal egentlig er
Strip ordet ned til funktionen: en autentificeret overflade hvor eksterne brugere — kunder, partnere, forhandlere — ser og handler på data der er deres. Det kan være ordrer, fakturaer, support-sager, kontrakter, lagerstatus, bookingslot eller en blanding.
Det der adskiller en portal fra "et login på jeres website" er ejerskabet af dataene og reglerne omkring dem. Hver bruger må kun se det der tilhører deres organisation. Handlinger skal logges. Rettigheder skal kunne trækkes tilbage. Det er derfor portaler ofte vokser ud af et CRM- eller ERP-behov — ikke ud af et designønske.
Hvis I kan beskrive behovet uden ordet "organisation", "rolle" eller "rettighed", har I sandsynligvis ikke brug for en portal endnu. I har brug for en bedre side, et bedre email-flow eller et standardværktøj.
Standardværktøj vs. egen kundeportal
Standardværktøj
HubSpot, Zendesk, SharePoint, Shopify customer accounts, portal-apps i jeres ERP.
- Hurtigt i drift — konfiguration, ikke udvikling
- Support, opdateringer og sikkerhedspakker følger med
- Fungerer godt til support, filer og simple statusflows
- I tilpasser jer værktøjets datamodel
- Dybe integrationer og egne flows bliver hurtigt dyre workarounds
Egen kundeportal
Et login bygget til jeres forretning — typisk Next.js med jeres data som source of truth.
- Flows der matcher hvordan I faktisk arbejder
- Rollemodel og dataisolation I ejer
- Integrationer til ERP/CRM uden at presse data ind i en fremmed model
- Kan vokse til et produkt (white-label, multi-tenant) senere
- Kræver ejerskab: drift, auth, ændringer over tid
Hvornår er hvad det rigtige?
Venstre kolonne er jeres situation — højre er det vi typisk anbefaler.
Jeres situation
Kunder spørger mest om status på sager og vil have et sted at skrive ind
Vores anbefaling
Zendesk, HubSpot Service eller lignende. En portal løser ikke et support-procesproblem.
Jeres situation
I deler kontrakter og filer, og adgangskontrol er "send et link"
Vores anbefaling
SharePoint, Drive eller et DMS med rigtige mapperettigheder. Byg ikke fil-deling selv.
Jeres situation
Kunder skal se ordrer, fakturaer eller lagerstatus fra jeres ERP
Vores anbefaling
Kundeportal med ERP som source of truth — eller ERP-leverandørens egen portal hvis den dækker behovet.
Jeres situation
Partnere eller forhandlere skal bestille, godkende eller se egne priser
Vores anbefaling
Egen portal. Standard B2B-apps dækker sjældent jeres pris- og godkendelseslogik rent.
Jeres situation
I vil have "en app til kunderne" uden et konkret flow der sparer tid
Vores anbefaling
Vent. Definér ét manuelt flow I vil fjerne først — så byg kun det.
Jeres situation
I er i tvivl mellem no-code portal og custom
Vores anbefaling
Prototype det kritiske flow i no-code i få uger. Hvis datamodel og rettigheder knækker, er custom det ærlige næste skridt.
“En kundeportal der ikke fjerner arbejde fra jeres team, er bare et ekstra login I skal vedligeholde.”
Det der typisk undervurderes
Auth er ikke "et login-skærm". Det er invitationer, password-reset, SSO for enterprise-kunder, 2FA, session-timeout og hvad der sker når en medarbejder skifter job hos kunden. Hvis I ikke har en plan for det, har I ikke en portal — I har en demo.
Dataisolation er det andet. "Vis kun mine ordrer" lyder trivielt indtil I har tre organisationer, underafdelinger, eksterne konsulenter med midlertidig adgang og en admin der må se alt. Row Level Security i Postgres (eller tilsvarende i jeres database) er næsten altid det rigtige sted at lægge garantien — ikke kun i UI'et.
Det tredje er ejerskab efter lancering. Portaler ændrer sig med forretningen: nye felter i ERP'et, nye roller, nye flows. Hvis ingen hos jer (eller hos en leverandør med en aftale) ejer det, ruster den stille hen — og kunderne falder tilbage til email.
Tjekliste før I beslutter at bygge
Hvis I ikke kan sætte flueben ved de fleste, er I sandsynligvis ikke klar til en egen portal endnu.
- Vi kan pege på ét konkret manuelt flow portalen skal fjerne (ikke "bedre oplevelse" i det abstrakte).
- Vi ved hvilken kilde der er source of truth for ordrer/dokumenter/status (ERP, CRM, eget system).
- Vi kan beskrive roller: kunde-admin, kunde-bruger, intern support, evt. partner.
- Vi har afklaret om kunderne kræver SSO (Microsoft/Google/Okta) i første version eller senere.
- Vi har en plan for hvem der drifter og ændrer portalen efter go-live.
- Vi har overvejet om leverandørens egen portal eller et standardværktøj allerede dækker 80%.
Spørgsmål vi får igen og igen
Kan vi ikke bare bruge Shopify customer accounts eller HubSpot?
Jo — hvis jeres behov matcher det værktøjet er bygget til. Shopify customer accounts er stærke til ordrer og re-order i e-handel. HubSpot er stærkt til support og indhold. Når I skal blande ERP-data, egne godkendelser og partnerroller, begynder standardværktøjerne at kræve workarounds der over tid koster mere end en målrettet portal.
Hvor lang tid tager det at bygge en kundeportal?
Et smalt første flow — login, ét datasæt, ét handlingsflow — ligger typisk i samme størrelsesorden som et mindre produkt-MVP: uger til et par måneder afhængigt af integrationerne. Det der forlænger forløbet er næsten altid uklar source of truth og uafklarede roller, ikke selve UI'et.
Skal vi have mobil-app?
Sjældent i v1. En responsiv webportal med ordentlig login og "add to home screen" dækker de fleste B2B-behov. Native apps giver mening når I har push-kritiske flows, offline-krav eller et meget højt dagligt brugsvolumen — ikke fordi det står på ønskelisten.
Hvad med sikkerhed og GDPR?
En portal der viser kundedata er et behandlingssystem. I skal have styr på databehandleraftaler, adgangslog, sletning/eksport og mindst-privilegium i roller. Teknisk lægger vi isolationen i databasen og auth-laget — ikke kun i frontend — og dokumenterer det så det kan stå i en due diligence.
Kan portalen senere blive et produkt vi sælger?
Ja, hvis I designer multi-tenant og branding ind fra starten — eller bevidst venter med det. Mange "interne portaler" bliver senere white-label. Det er billigere at forberede organisationsmodellen tidligt end at skære den ind senere. Men byg ikke marketplace-ambitioner ind i v1 hvis I kun har brug for self-service til egne kunder.
Overvejer I en portal?
Tag en uforpligtende snak om det rigtige omfang.
Vi hjælper med at afgøre om svaret er et standardværktøj, et smalt første flow — eller en portal der skal bygges rigtigt fra starten.