Klantportaal laten ontwikkelen: zo pak je het aan

Een klantportaal laten ontwikkelen is zelden een technisch vraagstuk. De moeilijke beslissingen zijn welk systeem leidend is, wie wat mag zien en wie het portaal na de oplevering bijhoudt. De schermen komen daarna.

Dit artikel gaat over hoe zo'n traject met een ontwikkelpartner verloopt: welke keuzes je vooraf maakt, welke koppelingen je serieus moet nemen en waar projecten vastlopen. Wat een klantportaal kost, staat in wat een klantportaal kost in 2026. De voorbeelden komen uit portalen en koppelingen die wij zelf hebben gebouwd, en de feiten erover staan op onze portfoliopagina's.

Soms is bouwen niet nodig. Moeten klanten alleen facturen en openstaande posten zien, en draait je boekhouding in een pakket met een eigen klantenomgeving, dan is dat portaal bijna altijd de snelste en goedkoopste route. Hetzelfde geldt voor het portaal in je CRM of helpdesk als klanten vooral tickets indienen en hun dossier bekijken. Je betaalt een abonnement, de leverancier onderhoudt het en jij hoeft niets te beheren.

Maatwerk gaat lonen als een of meer van deze dingen waar zijn.

• Het portaal is onderdeel van je dienst. Bij Stichting Oud Geleerd Jong Gedaan draaien lidmaatschap, live colleges en een bibliotheek met opgenomen colleges in een eigen platform, met Mijn OGJG als ingang voor leden. Dat is geen extra kanaal naast het product, het is het product.
• Je gegevens komen uit meerdere systemen. Het goederenportaal van OCS (Overseas Courier Service) werkt samen met hun Orbitrax-transportsysteem. Een standaardportaal kijkt meestal maar in een van je systemen.
• Je proces wijkt af van wat een standaardportaal aanneemt. Denk aan configureerbare producten, goedkeuringsstappen of meerdere gebruikers per klantorganisatie met elk andere rechten.

Twijfel je? Een tussenvorm is vaak het verstandigst. Neem het standaardportaal voor het eenvoudige deel en bouw alleen wat afwijkt, gekoppeld via een API. Over het bouwen zelf lees je meer op onze pagina over een webapplicatie laten bouwen.

Dit is de beslissing die later de meeste ellende voorkomt. Een portaal bewaart zelden alles zelf. Klanten bekijken en wijzigen meestal gegevens die in je ERP, boekhouding of planningssysteem leven. Leg per soort gegeven vast waar het vandaan komt en waar het naartoe mag.

Je ziet het in de praktijk terug. Het portaal dat wij voor OCS bouwden dient als single source of truth voor zendingsinformatie en koppelt direct met Orbitrax voor transportplanning en routeoptimalisatie. Medewerkers zien de status van alle zendingen in een dashboard. Voor Bloemenwinkel.nl bouwden wij een webshop waarin bestellingen, facturen en creditnota's automatisch met Exact Online synchroniseren. En in het inkoopportaal van Bloominess worden prijzen en beschikbaarheid bij externe leveranciers bijgewerkt. Drie keer een andere koppeling, steeds dezelfde vraag aan het begin.

Neem deze afspraken mee in het ontwerp.

• Een bron per gegeven. Wijzigt een klant zijn adres, schrijft het portaal dan direct naar het ERP, of ontstaat er een wijzigingsverzoek dat een medewerker goedkeurt? Allebei kan, maar kies bewust.
• Een plan voor als de koppeling uitvalt. De laatst bekende gegevens met het tijdstip van de laatste synchronisatie zijn beter dan een leeg scherm of een foutmelding.
• Zichtbare fouten. Een mislukte synchronisatie moet een melding naar je team sturen. Een portaal dat stilletjes achterloopt is erger dan een portaal dat zegt dat het achterloopt.
• Eerst lezen, dan schrijven. Gegevens tonen is eenvoudiger dan ze terugschrijven. Begin met tonen en voeg wijzigen toe als de koppeling stabiel draait.

Hoe koppelingen technisch in elkaar zitten, staat op onze pagina's over software koppelingen en API-koppelingen. In een offerte zijn ze meestal de grootste kostenpost na de kernfunctionaliteit, dus vage afspraken hierover zie je terug in het eindbedrag.

Een klantportaal heeft zelden maar een soort gebruiker. In B2B heb je per klant iemand die beheert, mensen die alleen mogen kijken en mensen die mogen bestellen of goedkeuren. Daarnaast hebben je eigen medewerkers rechten, en heb je een beheerder. Leg die matrix vast voordat een ontwerper een scherm tekent.

Dat is geen formaliteit. In de OWASP Top 10 van 2025 staat Broken Access Control opnieuw op de eerste plek. Bij alle geteste applicaties in de dataset vond OWASP een vorm van dit probleem, met een gemiddelde incidentiegraad van 3,74% (OWASP Top 10:2025, A01). Bij portalen ziet het er meestal zo uit dat een klant in de adresbalk een ander dossiernummer invult en dat dossier te zien krijgt. De remedie die OWASP noemt is toegang standaard weigeren en rechten koppelen aan de eigenaar van het record, niet aan het scherm waarop het verschijnt.

Ook de Autoriteit Persoonsgegevens vraagt hier iets van. Zij verwacht al bij een vrij laag risiconiveau een autorisatiematrix waarin staat wie bij welke gegevens mag. Logging staat niet expliciet als verplichting in de AVG, maar is volgens de AP in de meeste gevallen wel een noodzakelijke beveiligingsmaatregel. Het logboek is zelf ook een verwerking van persoonsgegevens, dus bepaal vooraf wat je vastlegt en hoe lang (Autoriteit Persoonsgegevens over toegang tot persoonsgegevens).

Over inloggen zelf is de AP ook duidelijk. Meerfactorauthenticatie is een combinatie van minimaal twee verschillende typen factoren, bijvoorbeeld een wachtwoord en een code uit een app. Twee wachtwoorden tellen dus niet (Autoriteit Persoonsgegevens over beveiliging van persoonsgegevens). Voor je eigen medewerkers en voor klanten die financiële of persoonlijke gegevens inzien is het een logische standaard. Kijk wel naar je doelgroep, want een te zware inlogstap jaagt gebruikers weg.

Dit zijn de modules waar klanten het meest mee doen, en waar ontwikkelaars het snelst te veel bouwen. Houd per module een scherpe vraag aan, en kijk naar de bijbehorende pagina als je dieper wilt.

• Documenten. Bepaal wie een document mag zien, of er versies zijn en hoe lang je het bewaart.
• Facturen. Het portaal toont wat in je boekhouding staat en maakt zelf geen tweede administratie.
• Meldingen. Stuur alleen berichten waar de ontvanger iets mee moet. Bij OCS krijgen medewerkers automatische meldingen bij statuswijzigingen en afwijkingen in zendingen.
• Betalen. Bij OGJG betalen leden via Mollie, met iDEAL en incasso.

Je hoeft niet alles in de eerste versie te hebben. Wat wel in de eerste versie moet zitten is de herhaalvraag die nu per mail of telefoon binnenkomt. Dat is je beste filter voor wat fase 1 wordt.

Een portaal dat niemand gebruikt is een dure website. Bepaal daarom vooraf wie je moeilijkste gebruiker is en ontwerp voor die persoon. Bij OGJG zijn dat senioren. Mijn OGJG is daarom gemaakt voor 65-plussers, met grote typografie en weinig stappen. Je hoeft geen seniorenplatform te bouwen, maar de gedachte klopt overal. Een inkoper die tien keer per dag bestelt wil iets anders dan een klant die een keer per kwartaal een factuur downloadt.

Denk ook aan de uitrol. Bij Bloominess verliep het bestellen eerst via e-mail en telefoon, en het inkoopportaal vervangt die route. Dat is een keuze die je moet maken. Blijft de oude route naast het portaal bestaan, dan gebruiken klanten die ook. Bloominess werkte vier jaar met doorontwikkeling aan het portaal, met stabiele groei in gebruikersadoptie. Reken dus niet op volledig gebruik op dag een. Plan een uitnodigingsmoment, een eenvoudige wachtwoordherstelflow en een kanaal voor vragen in de eerste weken.

Elke partner werkt iets anders, maar de volgorde hieronder is wat je mag verwachten van een volwassen traject.

1. Een eerste workshop. Je loopt de checklist hieronder door met iemand die vragen durft te stellen. Het resultaat is een lijst met rollen, bronsystemen en een voorstel voor fase 1.
2. Een functioneel ontwerp. Hierin staan schermen, regels en acceptatiecriteria, zodat je vooraf kunt beoordelen wat je koopt. Onze functioneel ontwerp template laat zien hoe dat eruitziet.
3. Bouwen in iteraties. Je ziet tussentijds werkende software, liefst zo snel mogelijk met echte data uit je koppelingen, want daar zitten de verrassingen.
4. Acceptatie. Je test tegen de criteria uit het ontwerp, met mensen die het portaal straks echt gebruiken.
5. Gefaseerde livegang. Eerst een groep klanten, dan de rest. Zo vang je problemen op voordat iedereen ze ziet.
6. Doorontwikkeling. Je wensenlijst verandert zodra echte klanten het gebruiken. Reserveer er budget voor.

Wil je een eerste indruk van de omvang? Met de calculator krijg je een indicatie, en de uitleg bij die cijfers vind je in het artikel over de kosten.

Neem deze lijst mee naar een eerste gesprek, ook als je uiteindelijk met een andere partij bouwt. Kun je minder dan de helft beantwoorden, dan is een workshop meer waard dan een offerte.

• Gebruikersrollen. Welke soorten gebruikers zijn er, per klant en intern, en wat mag elke rol zien, wijzigen en goedkeuren?
• Bronsystemen. Welke systemen bevatten de gegevens (ERP, boekhouding, CRM, planning) en welk systeem is per gegeven leidend?
• Richting van de koppeling. Alleen tonen, of ook terugschrijven? Wat gebeurt er bij een storing?
• Inloggen. E-mail en wachtwoord, meerfactorauthenticatie, of aanmelden met een bestaand account? Wie nodigt gebruikers uit en wie reset wachtwoorden?
• Documenten. Welke soorten, wie ziet ze, wie levert ze aan en hoe lang bewaar je ze?
• Meldingen. Welke gebeurtenissen leiden tot een bericht, via welk kanaal en naar wie?
• Facturen en betalingen. Alleen inzien of ook betalen? Welke betaalmethoden en welk boekhoudpakket?
• Privacy en logging. Welke persoonsgegevens, welke verwerkers, welke bewaartermijnen en wat leg je vast in het logboek?
• Beheer. Wie voegt klanten toe en past teksten of regels aan, en kan dat zonder ontwikkelaar? Bij OGJG beheert het team colleges, leden en mails zelf in een backoffice.
• Acceptatiecriteria. Hoe weet je bij oplevering dat een onderdeel klaar is? Formuleer het als test, bijvoorbeeld dat klant A nooit gegevens van klant B ziet.
• Fase 1. Welke herhaalvraag moet het portaal als eerste wegnemen, en wat schuift bewust door?

De meeste problemen ontstaan niet bij de bouw, maar erna. Drie dingen kom je vaak tegen.

Het portaal heeft geen beheeromgeving, waardoor elke nieuwe klant of tekstwijziging een telefoontje naar de ontwikkelaar betekent. Plan een backoffice mee, ook een simpele. Dan lopen je medewerkers niet tegen een muur aan en kost een kleine wijziging geen offerte.

Koppelingen worden niet bewaakt. Leveranciers passen hun API's aan en tokens verlopen, dus een koppeling die vandaag werkt kan volgende maand stilvallen. Vraag hoe de partner dat opmerkt voordat jouw klant het meldt.

De afspraken over eigendom en onderhoud zijn vaag. Wie is eigenaar van de code, waar draait het en wat kost een wijziging na de oplevering? Vraag het voordat je tekent en niet pas als het misgaat. Heb je vragen over jouw situatie? Stuur ons via het contactformulier een bericht, dan kijken we of maatwerk zinvol is of dat een standaardportaal beter bij je past.

Een goed klantportaal staat of valt met de beslissingen die vooraf genomen worden: bouwen of kopen, welk systeem leidend is, wie wat mag zien en wie het beheert. De techniek is daarna het kleinste probleem. Begin dus met de checklist en bepaal pas daarna wie het bouwt.

Past een standaardportaal bij je situatie, kies dat dan gerust. Wil je zien wat bouwen betekent voor jouw proces, bekijk dan eerst onze projecten, bijvoorbeeld OGJG, Bloominess, OCS en Bloemenwinkel.nl, of neem contact met ons op.