Klantportaal laten bouwen: kant-en-klaar, no-code of maatwerk?

'Een klantportaal laten bouwen' klinkt als één beslissing. Het zijn er minstens vijf, en de duurste fout maak je door met de bouw te beginnen voordat je ze genomen hebt. Wie eerst een tool kiest en daarna pas nadenkt over wie er inloggen, welke documenten ze zien en wat het portaal met je boekhouding moet delen, bouwt een mooie schil om een leeg proces. En betaalt daar jaren voor.

Deze gids is voor de ondernemer die overweegt klanten een eigen inlogomgeving te geven: een adviesbureau dat rapporten en facturen wil delen, een installatiebedrijf dat klanten de status van hun onderhoud laat volgen, een dienstverlener die het mailverkeer over 'waar staat mijn project' wil laten stoppen. Je leest hier niet welke tool 'de beste' is. Je leest hoe je de keuze maakt die bij jouw schaal, je proces en je databudget past, en wat elke aanpak echt kost.

Een klantportaal is een afgeschermde online omgeving waar je klanten inloggen om hun eigen gegevens, documenten en de status van hun opdracht in te zien, en om zelf standaardzaken te regelen: een document downloaden, een aanvraag indienen, een factuur betalen. Het verschil met een gedeelde map of een reeks mails is de toegangscontrole en de context: elke klant ziet alleen zijn eigen dossier, altijd actueel.

De vraag is zelden of klanten dit willen. In een overzicht van self-service-onderzoek kiest ongeveer 44 procent van de zakelijke klanten self-service als eerste route naar een antwoord, nog voordat ze een mens aanspreken. Een portaal dat klopt scheelt jou de herhaalvragen ('kun je die factuur nog eens sturen', 'hoe staat het ervoor') en geeft de klant het gevoel van grip. Een portaal dat niet klopt is een tweede plek waar informatie veroudert, naast de plek waar het al stond. Voor het proces ná de handtekening, waar dat portaal vaak op aansluit, kun je je klantonboarding van welkomstmail tot eerste levering automatiseren; deze gids gaat over de bouwbeslissing eronder.

Wat je nodig hebt: de functie-eisen die je keuze bepalen

Voordat je aanpakken vergelijkt, leg je vast wat het portaal moet doen. De functie-eisen bepalen je keuze, niet andersom. Vier eisen wegen het zwaarst, plus een paar randvoorwaarden die bijna iedereen vergeet tot het misgaat. Loop ze langs en schrijf per eis op hoe zwaar hij weegt: een must, een pre, of onnodig.

• Inloggen en toegang. Hoe komen klanten binnen (wachtwoord, magic link, of inloggen met hun Google- of Microsoft-account) en wie mag wat zien. Dit is de kern van een portaal en meteen het gevoeligste: een klant die per ongeluk het dossier van een ander ziet, is een datalek.
• Documenten delen. Uploaden en downloaden, versiebeheer, en de vraag welke documenten wel en niet zichtbaar zijn. Offertes, rapporten en facturen zijn standaard; interne notities horen er nooit in te lekken.
• Status en self-service. De orderstatus, de projectvoortgang, of de klant zelf een afspraak inplant of een aanvraag indient. Dit is waar een portaal echt werk uit je handen neemt in plaats van alleen documenten te tonen.
• Koppeling met je systemen. Toont het portaal live data uit je boekhouding, CRM of projecttool, of typ je het over? Zonder koppeling wordt je portaal een tweede waarheid die veroudert. Hoe soepel dat gaat hangt sterk af van hoe koppelbaar je boekhoudpakket is.
• Wie beheert het straks. Kun jij zelf een veld of een pagina aanpassen, of heb je daar elke keer een developer voor nodig? Dat verschil bepaalt of het portaal meebeweegt met je bedrijf of langzaam vastroest.
• Databudget en AVG. Welke klantdata komt in het portaal en waar mag die staan. Gevoelige documenten, een verwerkersovereenkomst en EU-verwerking zijn geen bijzaak; welke klantdata je waar mag laten staan is een aparte afweging met verwerkersovereenkomsten en data-residency.
• Groei. Hoeveel klanten krijgen toegang, nu en over twee jaar? Dit lijkt een detail, maar het prijsmodel van veel tools rekent per klant af, en dan wordt groei ineens duur.

De drie aanpakken: kant-en-klaar, no-code of maatwerk

Kort door de bocht: wil je standaard self-service en snel live, kies kant-en-klaar. Zit je klantdata al in losse tools en wil je een eigen look zonder developer, kies no-code op je eigen data. Heb je strikte datagrenzen, diepe koppelingen, of is het portaal zelf je product, dan is maatwerk het waard. Hieronder wat elk in de praktijk betekent, met echte prijzen (prijzen 2026, de meeste tools rekenen in dollars).

Kant-en-klaar: een SaaS-portaal dat je inricht

Je huurt een kant-en-klaar clientportaal en vult het met je eigen logo, documenten en klanten. Voor gerichte clientportalen loopt dat van SuperOkay (vanaf 9 dollar per maand voor drie klanten tot 112 dollar per maand onbeperkt) en SuiteDash (19 tot 99 dollar per maand, plat tarief, onbeperkt gebruikers) tot zwaardere platforms als Assembly, het vroegere Copilot (39 tot 399 dollar per maand). Gebruik je al een helpdesk of CRM, dan zit er vaak al een klantportaal in, zoals in HubSpot Service Hub of Zendesk. Je bent in dagen live en hebt geen techkennis nodig. De keerzijde: je zit vast aan wat de tool biedt, en je data er weer uit krijgen is beperkt. De sterkste keuze als je vooral documenten en status wilt delen op een standaardmanier.

No-code op je eigen data: Softr, Noloco of Glide

Hier bouw je zelf een portaal bovenop je eigen gegevens, bijvoorbeeld een tabel in Airtable, een database of je CRM. Softr loopt van gratis via 49 dollar (Basic) en 139 dollar (Professional) tot 269 dollar per maand (Business), waarbij het aantal app-gebruikers per tier oploopt van 20 naar 500. Noloco geeft je op zijn Business-abonnement 100 klant-accounts voor 213 dollar per maand, en elke extra klant kost 1 dollar. Dat prijsmodel is het echte verschil in deze categorie: Glide rekent 5 dollar per gebruiker, en dat telt bij honderden klanten hard aan. Je bouwt de logica en de schermen zelf, dus je grip is groter dan bij kant-en-klaar. Het risico verschuift alleen: bij no-code is de vraag niet of je iets kunt bouwen, maar of je je data en logica er later weer uit krijgt.

Maatwerk: je eigen portaal op je eigen stack

Bij maatwerk laat je het portaal bouwen op een eigen technische fundering: een frontend in bijvoorbeeld Next.js, een inlog- en databaselaag zoals Supabase of Clerk, en koppelingen naar precies jouw systemen. Je bezit de code en de data, en je kunt het volledig self-hosted en binnen de EU draaien. De draaikosten zijn laag: Supabase dekt op zijn Pro-abonnement 100.000 maandelijkse gebruikers voor 25 dollar per maand, plus wat hosting. De bouwsom is de investering. Een onafhankelijke kostenvergelijking rekent voor dat een maatwerkportaal bij een bureau al snel op 75.000 euro of meer aan bouwkosten uitkomt, met een team van twee tot drie developers over enkele maanden. Een afgebakend MKB-portaal ligt lager: reken op grofweg 7.000 tot 20.000 euro, op basis van vijftien tot dertig dagen werk tegen het dagtarief van 450 tot 650 euro dat diezelfde vergelijking noemt. Maatwerk loont pas als een van de eisen echt knelt: strikte datagrenzen, diepe koppelingen, of een portaal dat je onderscheidt van de concurrent.

Hoe die drie zich verhouden op de assen die er financieel toe doen:

Over vijf jaar en op schaal lopen die verschillen flink uiteen. Een onafhankelijke doorrekening voor honderd klanten en tien medewerkers komt uit op zo'n 15.000 euro voor een zuinig no-code portaal (Noloco) tot ruim 40.000 euro voor duurdere no-code en kant-en-klare platforms, en 131.000 tot 232.000 euro voor een volledig maatwerktraject bij een bureau. Een lean gebouwd maatwerkportaal landt daar ruim onder, maar de orde van grootte blijft: no-code is de goedkope middenweg, maatwerk een investering die je met een reden maakt.

Zo kies je: het beslis-kader

Het beslis-kader draait om vijf assen, niet om de featurelijst van een tool. Leg je functie-eisen op deze vijf en de aanpak volgt vrijwel vanzelf.

1. Aantal klanten en groei. Weinig en stabiel: alles kan. Veel en groeiend: het prijsmodel wordt beslissend, en een tarief per klant straft je succes af.
2. Hoe uniek je proces is. Standaard inloggen, documenten en status: kant-en-klaar dekt het. Eigen regels, eigen schermen, een eigen workflow: no-code of maatwerk.
3. Datagevoeligheid. Gewone documenten in de cloud: geen probleem. Bijzondere persoonsgegevens of een klant die self-hosting eist: dat duwt je richting maatwerk.
4. Wie het straks beheert. Moet jij het zelf kunnen aanpassen, dan is een no-code-vriendelijke of kant-en-klare aanpak logisch. Heb je een developer of vaste bouwpartner, dan is maatwerk beheersbaar.
5. Diepte van de koppelingen. Een paar losse widgets: elke aanpak kan het. Een portaal dat live meebeweegt met je boekhouding, CRM en projecttool: daar wint maatwerk, en no-code komt een eind mee.

Op die assen ontstaan drie heldere vuistregels. Standaard self-service voor een handvol tot enkele tientallen klanten: kant-en-klaar is bijna altijd het snelst en goedkoopst. Je data zit al gestructureerd in Airtable, Sheets of een CRM en je wilt een eigen uitstraling met een prijs die meegroeit: no-code op je eigen data. Strikte datagrenzen, diepe koppelingen of een portaal dat je onderscheidt: maatwerk, ook al is de bouwsom hoger. En twijfel je tussen no-code en maatwerk bij een uniek proces, begin dan no-code met een exit-plan. Je leert je echte eisen kennen zonder meteen tienduizenden euro's vast te leggen.

In vijf stappen van eis naar werkend portaal

Heb je een richting gekozen, dan is de bouw zelf een kwestie van in de juiste volgorde werken. Deze vijf stappen gelden voor elke aanpak; alleen de gereedschappen verschillen.

1. Zet je functie-eisen op papier en scoor ze

Neem de lijst uit 'wat je nodig hebt' en markeer per eis: must, pre, of onnodig. Dit is de saaie stap die iedereen overslaat en waar de meeste projecten alsnog op stranden. Een portaal dat 'ook wel documenten kan' terwijl documenten je kern zijn, is de verkeerde keuze die je pas na drie maanden merkt.

2. Bepaal je aantallen en reken het prijsmodel door

Tel hoeveel klanten nu toegang krijgen en schat het over twee jaar. Reken dan het tarief van je kandidaten uit op dat tweede getal, niet op vandaag. Vijf dollar per klant lijkt niets bij tien klanten en is 500 dollar per maand bij honderd. Een plat tarief of een dollar per extra klant houdt het voorspelbaar.

3. Kies de aanpak en toets hem tegen je databudget

Loop het beslis-kader of de keuzehulp door en leg de uitkomst naast je AVG-eisen. Komen er bijzondere persoonsgegevens in, of wil een klant EU-verwerking, dan valt een tool zonder EU-optie af, hoe mooi hij ook is. Regel de verwerkersovereenkomst voordat er data in gaat.

4. Bouw of richt in met echte data

Koppel eerst je bron (bijvoorbeeld Moneybird voor facturen of je CRM voor contacten), zet dan de toegang per klant op, en test met twee of drie echte klantdossiers. Controleer hier het gevoeligste punt: ziet elke klant alleen zijn eigen gegevens? Dit test je met echte data, nooit met een leeg voorbeeld.

5. Rol gefaseerd uit en regel het weggaan

Zet het portaal eerst live voor een kleine groep klanten, meet of ze het echt gebruiken, en breid dan uit. Regel meteen de offboarding: hoe trek je toegang in als een klant vertrekt? Een portaal waar oud-klanten blijven inloggen is net zo goed een lek als een verkeerd rechtenscherm.

De valkuilen die een portaal duur of nutteloos maken

De meeste portalen mislukken niet op de bouw, maar op een aanname die vooraf niet benoemd werd. Dit zijn de faalmodi die ik het vaakst zie, elk met de mitigatie.

• Een prijsmodel dat groei bestraft. Een tarief per klant voelt goedkoop bij de start en wordt je grootste maandpost bij succes. Mitigatie: reken door op je tweejaars-aantal en kies een plat tarief of een laag bedrag per extra klant.
• Alleen de happy path bouwen. Wat gebeurt er bij een klant die vertrekt, een document dat teruggetrokken moet, of een medewerker die per ongeluk het verkeerde dossier deelt? Mitigatie: test de toegangsrechten en de offboarding met echte data, niet met de mooie demo.
• Het portaal als tweede waarheid. Een portaal dat niet gekoppeld is, toont verouderde data zodra je systeem verandert, en dan vertrouwt niemand het meer. Mitigatie: koppel de bron en toon live data in plaats van overgetypte kopieen.
• AVG als sluitpost. Gevoelige documenten in een tool buiten de EU zonder verwerkersovereenkomst is een risico dat pas bij een incident zichtbaar wordt. Mitigatie: regel verwerking en bewaartermijnen voordat het portaal live gaat.
• Onderhoud vergeten, vooral bij maatwerk. Een gebouwd portaal is niet af; dezelfde kostenvergelijking rekent met vijftien tot twintig procent van de bouwsom per jaar aan onderhoud. Mitigatie: reserveer dat budget of leg een onderhoudsafspraak vast.
• Over-bouwen. Maatwerk laten maken voor wat een tool van 49 dollar per maand ook doet, is zonde van je geld en je tijd. Mitigatie: begin met de lichtste aanpak die je must-eisen dekt en stap pas op als het echt knelt.

Uitgewerkt voorbeeld: een installatiebedrijf kiest

Neem een installatiebedrijf met 120 zakelijke klanten. Het wil dat klanten inloggen om hun offertes, servicerapporten en facturen in te zien en de status van hun onderhoudscontract te volgen. De facturen staan in Moneybird, de projecten in een losse projecttool. Geen bijzondere persoonsgegevens, wel de wens om het zelf te kunnen aanpassen.

Langs het kader: het proces is grotendeels standaard (inloggen, documenten, status), de data zit al in losse tools, de datagevoeligheid is normaal, en de eigenaar wil zelf kunnen sleutelen. Dat wijst weg van maatwerk en richting no-code op de eigen data. Nu het volume: 120 klanten. Bij Glide met 5 dollar per gebruiker zou dat 600 dollar per maand worden, veel te duur. Noloco doet 100 klant-accounts voor 213 dollar plus 20 keer 1 dollar, dus zo'n 233 dollar per maand. SuiteDash zou als kant-en-klaar alternatief 49 dollar per maand plat kunnen, maar mist de directe koppeling met de projecttool.

De keuze wordt een no-code portaal in Noloco, gebouwd op de projectdata en gekoppeld aan Moneybird, met een eenmalige inrichting van rond de 3.000 euro en ongeveer 233 dollar per maand. Ter vergelijking: een maatwerkportaal met dezelfde functies zou hier grofweg 12.000 euro eenmalig kosten. Dat verschil is alleen te rechtvaardigen als het bedrijf later eigen, complexe logica wil of self-hosting gaat eisen. Zolang dat niet speelt, wint no-code op snelheid en kosten, en houdt het bedrijf de deur naar maatwerk open voor als het proces echt uniek wordt.

Tot slot

Een klantportaal is geen aankoop maar een keten van keuzes, en de volgorde is wat telt. Eerst weten wat je klanten echt moeten kunnen, dan pas kijken waarmee. Doe je het andersom, dan koop je een tool die je proces vormt in plaats van andersom, en dat is precies de vendor lock-in waar je later niet meer uit komt. De aanpak die bij je past is bijna nooit de duurste of de goedkoopste, maar de ene die meebeweegt met hoe jouw bedrijf groeit. Wie wil bundelen in plaats van een aparte inlog te geven, kijkt trouwens beter naar WhatsApp, mail en chat in één gedeelde inbox: een portaal is een dossier om in te loggen, geen kanaal om in te praten. Kies op je eisen, niet op de mooiste demo, en je portaal verdient zich terug in rust.